[OpenID] Native App and web API: Is this the proper use of OpenID Connect for this use case?

[Peter Williams]

> From: Andrew_Brown at rhoworld.com
> To: openid-general at lists.openid.net
> Date: Wed, 20 May 2015 14:27:36 +0000
> Subject: [OpenID] Native App and web API: Is this the proper use of OpenID Connect for this use case?
> 
> I'm trying to understand how to use OpenId Connect in the following use case. Let's say we just have the following 3 components: 
>  
> * Web app with an exposed API (Service Provider aka SP). 
> * A separate authentication server (Identify Provider aka IDP) used for SSO with the above SP. 
> * A native client app used by the End User. This client app uses the SP's API. 
>  
> All traffic would be over HTTPS. Here's how I envision the OpenID Connect process working: 
What use is that, as is? HTTPS when induced to use a null ciphersuite is worse than useless.
>  
> 1. The native app would request a "token" from the SP. 
Indeed. The originator of the connection (the client app) seeks a session token, issued by the security middleware built into the API provider.
> 2. The SP would see the user isn't authenticated and ask for verification from the trusted IDP. 
Indeed. There is no session token (which implies the user is not authenticated to the webapi provider). The security middleware (or SP component of the api provider, said correctly as you did) requests an authorization code from an IDP. Since this is a native app talking to a webapi (vs a web site), the request will not typically ask also for an id_token - one of openid connect's main claims to fame.
> 3. After the user's credentials are provided to the IDP, the IDP would return an ID token and Access token to the SP. 
Indeed. The IDP will formulate a response message  bearing a code sufficient to orchestrate a swap, by SP upon code receipt, of code for an access token (and probably refresh token).

> 4. The SP would verify the ID token and give the Access token to the native client app to use for all subsequent requests to the API. 

The SP would evaluate the access token for security and swap it for a locally-minted session token. The session token is typically provided to the native APP code and typically includes the access and refresh tokens. There are various flavors of the process, however.
> Is this the recommended way to use OpenID Connect in this situation? Any obvious security concerns? The only one I see is that the native client app could use the Access token to access the User Info endpoint at the IDP. 
Cannot comment on the security of this (not being an American and therefore unexceptional) . What is interesting is how the American IDPs are competing amongst themselves, in this area. The code - typically swapped for access token at the token endpoint of an IDP, which is then swapped at the token endpoint of the SP for a session token - might be swapped not for a typical access token (targeting a IDP's user profile endpoint, by default) but a modern Graph API resource - that MAY OR MAY NOT BE GOVERNED by an IDP. The resulting refresh token from THAT swap might "drive" not only a further swap that mints the session token but swapping for a family of API endpoints that respect this "ticket granting" power. The power may well allow multiple active apps on a tablet to share a token cache (granting the illusion of single sign on to an app family, once you start the master native app).
This is where opened connect gets interesting. And its where I'm sure NSA/DARPA and co have ensured that the IETF RFCS have lots of "Structure" in the security model that will facilitate US information dominance, cyberwar prep, subversion, facilitation of cryptanalysis and all the other things that typically go into IETF security efforts at the IESG level. Having a SP centric model is the right way of thinking - since power corrupts (and will surely corrupt IDPs that get too many duties, if it has not already done so)
> Thanks for any help! 
>  
> - Andy 
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20150520/76396b9c/attachment.html>