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

John Bradley ve7jtb at ve7jtb.com
Tue Jul 8 16:57:29 UTC 2014


There are two basic approaches with web_init

The first is generating a URI with a token that identifies the TA/user that goes to the IdP and based on that short lived token the IdP performs IdP init SSO to some SP/Client.
The IdP maintains a session for the user in whatever way it typically uses, if the SP/client session expires it will send the user back to the IdP.   If the IdP session has expired then the IdP will need to redirect the app back to the TA to get another start_sso URI.

I guess if the TA has some sort of multi factor authentication built sending the app back to the TA makes sense, but if the authentication is based on a stored key, then I don't know that the extra flow adds much beyond a cookie in the browser.

The second method would be to generate a authn response as the web_init_sso URI that takes the browser directly to the SP/Client.   That would work, but the browser would have no session with the IsP so when the SP/Client session expires, the browser would be redirected back to the IdP perhaps as a passive authentication but the IdP would have no session for the browser and not necessarily know that there is a TA to request a token from.

I suspect that the first method will prove to be more reliable (and required to work with the current Connect 3rd party login).

So that leaves a question of how the IdP indicates to the App that it wants a new web_init_sso URI that will indicate that the TA has verified the user and can continue the session.

In principal a native app that is requesting a web_inti_sso URI can just request another one and leave it up to the IdP to maintain state via cookies or DB as it likes in the case where the
web_intit_uri is going to the IdP rather than the RP/SP directly.

At the moment we don't have a way for an app to request web_init_sso URI for different target_uri (SP/Clients)

Is that something we want to add?

At the moment we have a single optional element per app with one web_init_sso  element.

We could make that an array.   If we wanted to support dynamic SP/Clients then we would need a way to pass the target resource to the AS.
That would argue for a base web_init_sso uri from the app_info endpoint and a token returned from the token endpoint.
Appending the token as a query parameter is not a good practice for security reasons, but sending it as a POST or OAuth bearer header would be fine.

That is more complex, but would be worthwhile if people think that apps will need to do web sso to more than one resource per app.

John B.




On Jul 8, 2014, at 9:47 AM, Emily Xu <exu at vmware.com> 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/20140708/f11aa13c/attachment-0001.html>


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