[Openid-specs-ab] Guidance on native apps with helper Web services

John Bradley ve7jtb at ve7jtb.com
Fri Sep 12 17:01:24 UTC 2014


One step someplace around 4 is the client authenticating to it's backing Web API.

For that NAAPS is proposing standardizing a way for the app to request a id_token scoped to it's Backing WebAPI.
People can then use that in a JWT assertion flow to get a id_token from the AS for the Backing Web API, or directly use the id_token as a access token.
In that case azp is the client of the app requesting the id_token. (not the NAAPS TA if one is in the flow). 

It sounds like in Caleb's case what he needs is a id_token that the service backing the Web API can use to get a AT for the user_info endpoint. 

A interesting question.  

For security it would be good if the assertion flow also authenticated the backing Web API service to prevent tokens leaking.

Google currently has a way to ask for this by overloading scopes.

NAAPS is looking at re using the "aud" parameter on the token_endpoint that the PoP specs define to try and make it clear what the requested "aud" of the id_token should be.

John B.
On Sep 12, 2014, at 12:28 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:

> Hi all,
>  
> Caleb Baker sent me the following request about how to support native apps with helper Web services.  What guidance can we give him and others wanting to implement this scenario?  I know that at least Google uses the “azp” claim in ID Tokens as part of supporting this.  How exactly is it used in this scenario?  How does the OP know when to include an “azp” claim and what value to use?
>  
> I’m looking for guidance on the use of OpenID Connect by mobile applications that are backed by a Web API.  As an example, take a game app that stores the user’s profile, including game state on a back end web service.
>  
> 1.            The user starts the game app on a new device.
> 2.            In a web view hosted by the app, they authenticate at their OP and grant permission for the app accessing their profile.
> 3.            The response is returned to the app
> 4.            The app accesses the backing Web API to get the user profile info
> 5.            The service backing the Web API is granted access to call the UserInfo endpoint and get additional information about the user
> 6.            The app makes additional calls to the Web API to save and retrieve game state each time the app opens and closes.
>  
> I’ve considered using the hybrid flow, with ‘response_ type=code id_token’. Then pass the authorization code to the Web API, so it can access the UserInfo endpoint.
> Using that flow I’m not sure how Web API authorized the app to access the user profile in step 4 and step 6.
>  
> Is there a recommended approach for accomplishing this scenario with OpenID Connect?
>  
>                                                             -- Mike
>  
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140912/8d356422/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4326 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140912/8d356422/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list