[Openid-specs-native-apps] Asymmetry between native & web apps?

[John Bradley]

OK I will do a draft with it being a OAuth protected IdP hosted sso_init endpoint to look at for the call today.  

I agree it is better but more prescriptive on the IdP.

John B.
On Jul 8, 2014, at 1:36 PM, Paul Madsen <paul.madsen at gmail.com> wrote:

> is not the question *how* the TA asks for a fresh web_init_url?
> 
> 1) by using its access token against the AppInfo endpoint
> 2) by using its refresh token against the token endpoint
> 
> #1 seems wasteful, as the AS would generate new web_init_url's for all web apps, not just the one in question
> 
> paul
> 
> On 7/8/14, 9:47 AM, Emily Xu wrote:
>> Is it possible to do a hybrid approach?
>> 
>> The web_init_sso URI returned from app_info endpoint contains short lived session at the IdP. Since this uri contains short lived session token, a new URI needs to be generated again later when the session is expired.
>> 
>> We should also provide a way for a client app to request a new web_init_sso URI with a fresh one time use token. For example, a client app could request a new web_init _sso URI from AS through TA:
>> 
>> Client app -> TA: scope=clientApp1&webinituri=<WebApplaunchUri>&customUrl=<clientapp1CustomUrl>&bundleId=<clientApp1Bundleid>
>> TA->AS: scope=clientApp1&webinituri=<WebApplaunchUri>&customUrl=<clientapp1CustomUrl>&bundleId=<clientApp1Bundleid>
>> AS: validates client App1, and generate onetime token
>> AS->TA: webiniturl=<WebAppLaunchUri?onetimetoken=jdfkdjkfdj>&customUrl=<clientapp1CustomUrl>
>> TA->client app's customUrl: webiniturl=<WebAppLaunchUri?onetimetoken=jdfkdjkfdj>
>> Client app1: launch web app using the url with onetime token
>> IdP will generate session token using the one time token.
>> 
>> By using this approach, it is more secure since only the one time token is added as uri parameter. A client app could use this approach to launch web app using NAPPS session instead of asking IdP to authenticate user again.
>> 
>> Thanks,
>> Emily
>> 
>> 
>> From: John Bradley <ve7jtb at ve7jtb.com>
>> Date: Monday, July 7, 2014 5:57 AM
>> To: Paul Madsen <paul.madsen at gmail.com>
>> Cc: "openid-specs-native-apps at lists.openid.net" <openid-specs-native-apps at lists.openid.net>
>> Subject: Re: [Openid-specs-native-apps] Asymmetry between native & web apps?
>> 
>> The app_info endpoint needs to generate fresh web_init_sso URI each time it is called.   I expect that they have limited lifetimes at the IdP.
>> 
>> I am assuming that these are short lived URI to call an endpoint at the IdP that will establish a session and do IdP intit SSO from there.  
>> If that session expires the client/SP/RP will send the user back to the IdP and the IdP would deal with it as a normal flow.  
>> I suppose it could somehow the user back to the TA and start again with a new web_init_sso uri but that seems more complicated that it is worth.
>> 
>> The problem with making them symmetrical is that one is a URI and the other is a token.
>> 
>> To do that we would need to define a web_init_sso_base_uri that is delivered in discovery or from the app_info response.   
>> Then we would get a access token for web sso from the token endpoint and invoke a browser to call the endpoint with the access token to start the IdP init SSO.
>> 
>> That would remove the need to generate fresh URI from the app_info endpoint and be more secure as we would not be passing the secret value in a query parameter.
>> 
>> On the other hand having a single uri to pass to the browser is going to be simpler for most implementers, and most start_sso endpoints are not OAuth protected.
>> 
>> So there are plusses and minuses to using a access token for both.
>> 
>> John B
>> 
>> 
>> On Jul 7, 2014, at 8:19 AM, Paul Madsen <paul.madsen at gmail.com> wrote:
>> 
>>> The current model is that the TA uses its refresh token to obtain access tokens for native apps, but obtains the web_init_sso URL for a web application in the AppInfo returned JSON
>>> 
>>> Is there value in making the model symmetrical for the two application types, ie the TA uses its refresh token to obtain a web_init_sso 'token'
>>> 
>>> Without this sort of explicit request to enable web apps, what would the TA do when the web session expired?
>>> 
>>> paul
>>> _______________________________________________
>>> 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/20140709/c4636f99/attachment-0001.html>