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

Emily Xu exu at vmware.com
Tue Jul 8 13:47:56 UTC 2014


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/f8714ae3/attachment.html>


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