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

[John Bradley]

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