[Openid-specs-ab] Your help needed clarifying Google's "azp" claim usage
John Bradley
ve7jtb at ve7jtb.com
Fri Aug 21 15:47:45 UTC 2015
Thanks Pedro,
Slides 78-82 also cover another use case Google addresses outside of Connect where the requestor/client wants a code for another client.
This use case may also want to be formalized in token exchange.
What they have works but in both cases Google has a lot of admin policy around the flows around registration of the two clients that may be hard to generalize.
That is why we only documented the security warning that tokens with a azp containing a value that is not one you recognize, should not be trusted.
We were attempting to document the security consideration, not how to use it in the way Google is.
I would prefer to think about what is required to identify the parties of these transactions first, and only the re use azp if it happens to fit.
The other thing that has changed is now we are talking about pop tokens, then we only had bearer. If we had had a way to identify the presenter to the recipient at the time via a POP
mechanism, we might have defined it as presenter, but given bearer tokens only allowed the identification of the requester in OAuth that was the term we agreed to use, as for the most part in Googles case it is the same party if you ignore the token agent.
Breno also had some other use cases for azp at the time that involved four parties, that was a part of the discussion.
John B.
> On Aug 21, 2015, at 9:40 AM, Pedro Felix <pmhsfelix at gmail.com> wrote:
>
> I've some slides on this subject, based exclusively on using the Google public documentation and the Play Services SDK: https://speakerdeck.com/pmhsfelix/single-sign-on-for-mobile-native-applications?slide=71 <https://speakerdeck.com/pmhsfelix/single-sign-on-for-mobile-native-applications?slide=71>
>
> HTH
> Cheers
> Pedro
>
> On Thu, Aug 20, 2015 at 11:16 PM, Mike Jones <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>> wrote:
> Thanks, Mengcheng!
> From: Mengcheng Duan <mailto:mengcheng at google.com>
> Sent: 8/20/2015 3:07 PM
> To: Adam Dawes <mailto:adawes at google.com>
> Cc: Mike Jones <mailto:Michael.Jones at microsoft.com>; William Denniss <mailto:wdenniss at google.com>; Breno de Medeiros <mailto:breno at google.com>; Naveen Agarwal <mailto:naa at google.com>; openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>; John Bradley <mailto:jbradley at pingidentity.com>
> Subject: Re: [Openid-specs-ab] Your help needed clarifying Google's "azp" claim usage
>
> the client ID is the android app is used in the request. An audience field which contains the home server client ID provided by the app is added in the request. An ID token whose azp is the android app and aud is the home server will be issued if the two client IDs are in the same parent project, .
>
>
> - Mengcheng
>
> On Thu, Aug 20, 2015 at 2:52 PM, Adam Dawes <adawes at google.com <mailto:adawes at google.com>> wrote:
> +mengcheng
>
> On Thu, Aug 20, 2015 at 9:03 AM, Mike Jones <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>> wrote:
> Thanks guys. A few follow-up questions…
>
>
>
> Which Client ID is used in the Authentication Request to the OP – the Client ID of the Android App or the Client ID of the app’s home server? Also, what information are you adding to the Authentication Request to tell the OP to issue a token with the audience being the app’s home server and the “azp” being the Android application?
>
>
>
> -- Mike
>
>
>
> From: William Denniss [mailto:wdenniss at google.com <mailto:wdenniss at google.com>]
> Sent: Wednesday, August 19, 2015 11:39 PM
> To: Adam Dawes
> Cc: Mike Jones; Breno de Medeiros; Naveen Agarwal; openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>; John Bradley
> Subject: Re: [Openid-specs-ab] Your help needed clarifying Google's "azp" claim usage
>
>
>
> So our interpretation is that 'azp' is the party who the token was issued to, 'aud' is the party who the token was intended for. The expectation being that the 'azp' client is presenting the token to their server (the 'aud'). For our Android API, both client-ids must be registered under the same parent project (i.e. you can't request an id token for an arbitrary client id that you don't also own, and isn't a member of the same project).
>
>
>
> Of the two names, I think I prefer "Authorized Presenter" over "Authorized Party", as azp refers to the client authorized to present the token to the server.
>
>
>
> The server could always choose to accept an ID Token issued with an 'aud' of its client app directly, this just makes the semantic a little more explicit I guess.
>
>
>
> It is curious that we have documented the claim semantic, without actually having a standards-compliant way to request such a token. I wonder if that's something we should address. It could be relevant for the NAPPS effort.
>
>
>
> On Wed, Aug 19, 2015 at 10:57 PM, Adam Dawes <adawes at google.com <mailto:adawes at google.com>> wrote:
>
> From one of our engineers:
>
>
>
> AFAIU, the only case where "azp" is different from "aud" is Android cross-client ID token.
>
> In that case, the azp is the ID token requestor, which is the Android app, and the audience is the app's home server, for which the ID token is intended.
>
> Unfortunately, this underlying protocol is not standard OAuth2 or OIDC. I'm not sure we want to publicly document the protocol traces.
>
>
>
> On Wed, Aug 19, 2015 at 12:16 PM, Mike Jones <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>> wrote:
>
> Hi Googlers,
>
>
>
> It would be hugely useful if you could capture protocol traces that demonstrate how Google actually uses the “azp” claim in cases where the “azp” and “aud” values differ. Ideally, I'd like to see actual protocol traces, including the Authentication Request, the Authentication Response, and both directions of any the communication between the Client that made the request to the OP and any other Clients that it also sends the resulting token(s) to. Among other things, that would also answer OAuth-y questions like which Client ID is being used for client authentication to the OP when more than one client is involved.
>
>
>
> The Connect text about “azp” is currently both ambiguous and contradictory. This data would be of a huge help to us for sorting this out during the current errata round.
>
>
>
> Thanks a bunch,
>
> -- Mike
>
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.openid.net%2fmailman%2flistinfo%2fopenid-specs-ab&data=01%7c01%7cMichael.Jones%40microsoft.com%7c836d72deda5d482c47e908d2a92a1d41%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7uvAkt5fiquNc%2bOVCQir5UvBmFs%2bpyCE0LiqSs14d%2bY%3d>
>
>
>
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net <mailto:Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab <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/20150821/f07a7247/attachment.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/20150821/f07a7247/attachment.p7s>
More information about the Openid-specs-ab
mailing list