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

Thu Jul 10 16:26:38 UTC 2014

What you are describing is a native app that invokes a web view.

I think it is consistent with what I have added.

You have some additional details in your description.  
I would say the way the web part of the app is loaded and determining if there is a session  is part of the app and implementation specific. 
What you have is a reasonable way to do it, but there may be other ways depending on  the design of the web app.  

Once the native app decides it needs a a session passing the request to the TA and getting the access token and base URI back is what I was thinking.  
The binding spec needs to be changed to pass a target URI as part of the request to the TA (assuming that an app could have multiple targets,  and the response needs to include the base 
init_sso URI as well as the token.    That still needs to be added.

The native app is allowed to pass the access token on a query parameter, though that is not recommended for security reasons.   If the web view is using Java scrypt then sending it as a POSt or header should be no big deal.  That is how node.js and other apps make OAuth calls now.    Some thought needs to be put in to cross domain communications, but that can be dealt with by the web app.

So I think we are largely agreeing.

John B.

On Jul 10, 2014, at 12:04 PM, Emily Xu <exu at vmware.com> wrote:

> 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?
> User click on a web clip installed on his device (https://idp.com/launch/webapp1)
> A web view is opened by a client app, and redirect the browser to https://idp.com/launch/webapp1
> IdP received the request and sees no user session. IdP returns 401
> 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
> TA sends request to AS: refresh_token=primaryrefreshtoken&scope=clientapp urn:oauth:web-sso&webinituri=https://idp.com/launch/webapp1
> AS validates client app and issue one time access token and append it to webinituri https://idp.com/launch/webapp1?ota=something
> TA pass the webinituri+ota token to client app's customUrl
> Client app redirects the browser to https://idp.com/launch/webapp1?ota=something
> 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>
> Date: Wednesday, July 9, 2014 7:17 AM
> To: Paul Madsen <paul.madsen at gmail.com>
> Cc: Emily Xu <exu at vmware.com>, "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?
> 
> 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/20140710/ab9f87e2/attachment-0001.html>