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

Paul Madsen paul.madsen at gmail.com
Tue Jul 8 17:36:19 UTC 2014


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 <mailto:ve7jtb at ve7jtb.com>>
> Date: Monday, July 7, 2014 5:57 AM
> To: Paul Madsen <paul.madsen at gmail.com <mailto:paul.madsen at gmail.com>>
> Cc: "openid-specs-native-apps at lists.openid.net 
> <mailto:openid-specs-native-apps at lists.openid.net>" 
> <openid-specs-native-apps at lists.openid.net 
> <mailto: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 
> <mailto: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 
>> <mailto: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/20140708/a873ff7f/attachment.html>


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