[Openid-specs-native-apps] 3rd party API integration models

John Bradley ve7jtb at ve7jtb.com
Fri Apr 4 18:21:43 UTC 2014


Yes I think I just said the same thing on the other thread.

The TA can always try 2 first then if it doesn't have sufficient privileges try 1a then go back to 2 again to get the AT.

I think that is the most logical.(at least to me)

John B.
On Apr 4, 2014, at 2:17 PM, Paul Madsen <paul.madsen at gmail.com> wrote:

> thanks for summarizing John, 
> 
> perhaps the TA chooses between options 1a & 2 - picking (1a) when consent gathering is necessary (e.g. on first authz & any upscoping) and picking (2) when consent has already been obtained or is not relevant.
> 
> Separately, (1a)  could be used by the TA to facilitate web SSO into an arbitrary browser app, and not just a remote AS's authz endpoint
> 
> paul
> 
> On 4/1/14, 9:58 AM, John Bradley wrote:
>> In cases where the token agent and the RS have a relationship as is the common case in OAuth life is relatively simple.
>> 
>> When the RS is a separate organization or security domain life gets more complicated.
>> 
>> One way of looking at it is authorization based on federated authentication or authorization.
>> 
>> 1- The common way to do this now is that the 3rd party API provider provides a OAuth Authorization endpoint that the user is redirected to and they then perform whatever federated login is required via Connect/OpenID 2/SAML and perform consent returning a access/refresh token.
>> 
>> The advantage of this is that user consent can be gathered.
>> The disadvantage to this is that the browser typically won't have access to existing session info and the user will have to authenticate to the authentication server. (basically loosing the advantage of the TA)
>> 
>> 1a -  One twist on 1 may be to have the home IdP generate a URI to trigger IdP initiated login to the Authorization server.
>> 
>> 
>> 2 The client could request a id_token with a audience of the AS.
>> 		a- The client can directly use that as it's access token.  (requires potentially special logic in the RS)
>> 		b- The client can trade the id_token for an access token using the assertion flow.
>>     If the client is specific to the RS then it can would know if a or b is appropriate, otherwise there would need to be some discovery.
>> 
>>     The downside to this is that if consent needs to be collected then it would need to be done by the AS the Token Agent is configured for, requiring that AS to know a lot more about downstream apps.
>> 
>> 3  The token agent could register with the 3rd party AS and get the access token via 1a or 2.  
>>         This pushes more logic into the TA and perhaps raises the question of meta-data for apps.   The App could push it's meta-data to the TA or the TA could discover it from a trusted source.
>>         
>>          One advantage to this is that the browser would be part of the TA so it may be able to do more for security like setting cookies.
>> 
>> John B.
>> 
>>         
>> 
>> 
>> 
>> _______________________________________________
>> Openid-specs-native-apps mailing list
>> Openid-specs-native-apps at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-native-apps
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-native-apps/attachments/20140404/3a5b9f05/attachment.html>


More information about the Openid-specs-native-apps mailing list