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

Emily Xu exu at vmware.com
Thu Jul 10 16:04:43 UTC 2014


Hi John,

Thank you for updating draft with web init sso flow. In the working draft, TA or client app needs to add "access_token" to authorization header or as HTTP form post parameter.

Is it possible for us to short circuit this step to simplify the work needed by TA, client app, and IdP? What about this hybrid flow?

  1.  User click on a web clip installed on his device (https://idp.com/launch/webapp1)
  2.  A web view is opened by a client app, and redirect the browser to https://idp.com/launch/webapp1
  3.  IdP received the request and sees no user session. IdP returns 401
  4.  Client app processes 401, then sends a request to TA for web init url: scope=clientapp urn:oauth:web-sso&webinituri=https://idp.com/launch/webapp1
  5.  TA sends request to AS: refresh_token=primaryrefreshtoken&scope=clientapp urn:oauth:web-sso&webinituri=https://idp.com/launch/webapp1
  6.  AS validates client app and issue one time access token and append it to webinituri https://idp.com/launch/webapp1?ota=something
  7.  TA pass the webinituri+ota token to client app's customUrl
  8.  Client app redirects the browser to https://idp.com/launch/webapp1?ota=something
  9.  IdP receives the request, process the one time token, set IdP session cookie, generates SAML response and post it to webapp1

Since AS knows how IdP accept this SSO token, the token can be added by AS directly. This approach would simplify TA or client app quite a bit. Since one time token is used, this is relatively  secure.

What do you think about this flow?

Thanks,
Emily
From: John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>>
Date: Wednesday, July 9, 2014 7:17 AM
To: Paul Madsen <paul.madsen at gmail.com<mailto:paul.madsen at gmail.com>>
Cc: Emily Xu <exu at vmware.com<mailto:exu at vmware.com>>, "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?

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<mailto: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<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<https://urldefense.proofpoint.com/v1/url?u=http://lists.openid.net/mailman/listinfo/openid-specs-native-apps&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=R6O1w3X3Nn9BCk0KoIS9VWb9KuFPS%2FGilBQ7QJc0YYI%3D%0A&s=cbdf71cec0cbeb8a05e05f0ae574af5091047eccb8c17c1f25ef8bdf99ffe712>



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


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