[Openid-specs-ab] aud & azp

Brian Campbell bcampbell at pingidentity.com
Mon Aug 10 22:10:37 UTC 2015


It's not totally clear what the spec allows or prescribes, which is where the
issue for errata <https://bitbucket.org/openid/connect/issues/973/>
originates. And there seems, from the last call anyway
<http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20150803/005637.html>,
to be a lack of agreement about what the intent actually was.

It's my belief that the client id of the RP/client that made the
authentication request should always be represented in the aud of the
returned ID Token.



On Mon, Aug 10, 2015 at 12:51 PM, Preibisch, Sascha H <
Sascha.Preibisch at ca.com> wrote:

> Just to make sure that I got it right:
>
>    - it is possible that a JWT does not include the client_id (neither in
>    “aud" nor in “azp") of the client who has sent the request, correct?
>
> If I am wrong I may misunderstood your text Brian and would be happy for
> some clarification.
>
> Thanks, Sascha
>
> From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> on
> behalf of Brian Campbell <bcampbell at pingidentity.com>
> Date: Thursday, August 6, 2015 at 5:47 AM
> To: Mike Jones <Michael.Jones at microsoft.com>
> Cc: "<openid-specs-ab at lists.openid.net>" <openid-specs-ab at lists.openid.net
> >
> Subject: Re: [Openid-specs-ab] aud & azp
>
> Sure, https://bitbucket.org/openid/connect/issues/973/
>
> On Wed, Aug 5, 2015 at 5:13 PM, Mike Jones <Michael.Jones at microsoft.com>
> wrote:
>
>> Thanks for bringing this up, Brian.  Could you file this as an issue
>> against the “errata” deliverable and the core spec at
>> https://bitbucket.org/openid/connect/issues?status=new&status=open?  We
>> should talk about this on tomorrow morning’s working group call.  After you
>> do, I’ll add the following as a comment on the issue…
>>
>>
>>
>> I think the problematic language is “the Client” in the statement below:
>>
>>
>>
>> If an azp (authorized party) Claim is present, the Client SHOULD verify
>> that its client_id is the Claim Value.
>>
>>
>>
>> The problem is that the azp Client can be different than the requesting
>> client.  It’s the azp Client that needs to do this validation step, not the
>> requesting client.  Do people agree with this?
>>
>>
>>
>>                                                                 -- Mike
>>
>>
>>
>> *From:* Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net]
>> *On Behalf Of *Brian Campbell
>> *Sent:* Wednesday, August 05, 2015 10:11 AM
>> *To:* <openid-specs-ab at lists.openid.net>
>> *Subject:* [Openid-specs-ab] aud & azp
>>
>>
>>
>> I find the text around azp and aud to be rather unclear and I think
>> there's a potential item for errata in it somewhere.
>>
>> From the definition of "aud" in JWT
>> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2frfc7519%23section-4.1.3&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UgVDJXRprGpK9ESVc5UcfRhoeVyqF4FqAreai1hKE%2b8%3d>
>> and its use in Connect's ID Token
>> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.net%2fspecs%2fopenid-connect-core-1_0.html%23IDToken&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UqyFRA5dyeXsDvmbmwVJeZWrboUbFWN%2bR9OpJpvIG0c%3d>
>> (relevant spec text is copied below), it seems that that the client id of
>> the client/RP that made the authentication request has to be one of the
>> values, or the only value, of the "aud" claim in the ID Token. That's
>> logical and consistent and provides reliable and interoperable guidance to
>> implementers about producing and consuming the ID Token. I think that the
>> client id of the RP/client that made the authentication request should
>> always be represented in the aud of the returned ID Token.
>>
>> The text around "azp" in the ID Token section
>> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.net%2fspecs%2fopenid-connect-core-1_0.html%23IDToken&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UqyFRA5dyeXsDvmbmwVJeZWrboUbFWN%2bR9OpJpvIG0c%3d>
>> and the ID Token Validation section
>> <https://na01.safelinks.protection.outlook.com/?url=+http%3a%2f%2fopenid.net%2fspecs%2fopenid-connect-core-1_0.html%23IDTokenValidation&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LrFoSF%2bqjC75ilCneT3yFXJ30Nu8nu%2fbsj5LiEKJkus%3d>
>> seems to maybe suggest something different, however. Like perhaps that the
>> client id of the RP/client that made the authentication request could, in
>> some totally unspecified circumstance, be the value of the azp claim and
>> that the aud would not identify that client as an intended recipient. Am I
>> misinterpreting things? I hope so because that seems like it'd be fragile
>> from an interop perspective and is certainly more cumbersome for general
>> JWT libraries to support.
>>
>>
>>
>>
>> from http://tools.ietf.org/html/rfc7519#section-4.1.3
>> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2frfc7519%23section-4.1.3&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UgVDJXRprGpK9ESVc5UcfRhoeVyqF4FqAreai1hKE%2b8%3d>
>>
>>  4.1.3.  "aud" (Audience) Claim
>>
>>    The "aud" (audience) claim identifies the recipients that the JWT is
>>    intended for.  Each principal intended to process the JWT MUST
>>    identify itself with a value in the audience claim.  If the principal
>>    processing the claim does not identify itself with a value in the
>>    "aud" claim when this claim is present, then the JWT MUST be
>>    rejected.  In the general case, the "aud" value is an array of case-
>>    sensitive strings, each containing a StringOrURI value.  In the
>>    special case when the JWT has one audience, the "aud" value MAY be a
>>    single case-sensitive string containing a StringOrURI value.  The
>>    interpretation of audience values is generally application specific.
>>    Use of this claim is OPTIONAL.
>>
>>
>> from http://openid.net/specs/openid-connect-core-1_0.html#IDToken
>> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.net%2fspecs%2fopenid-connect-core-1_0.html%23IDToken&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UqyFRA5dyeXsDvmbmwVJeZWrboUbFWN%2bR9OpJpvIG0c%3d>
>>
>>   ...
>>
>>   aud
>>
>> REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain
>> the OAuth 2.0 client_id of the Relying Party as an audience value. It
>> MAY also contain identifiers for other audiences. In the general case, the
>> aud value is an array of case sensitive strings. In the common special
>> case when there is one audience, the aud value MAY be a single case
>> sensitive string.
>>
>>   ...
>>
>>   azp
>>
>> OPTIONAL. Authorized party - the party to which the ID Token was issued.
>> If present, it MUST contain the OAuth 2.0 Client ID of this party. This
>> Claim is only needed when the ID Token has a single audience value and that
>> audience is different than the authorized party. It MAY be included even
>> when the authorized party is the same as the sole audience. The azp
>> value is a case sensitive string containing a StringOrURI value.
>>
>>   ...
>>
>> from
>> http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation
>> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fopenid.net%2fspecs%2fopenid-connect-core-1_0.html%23IDTokenValidation&data=01%7c01%7cMichael.Jones%40microsoft.com%7ca97947375f324b13278508d29db9ea16%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ko0MzMkFxNMQmWPYs%2fPYGgMvPE2m%2bhuj4vIUBIwyz1M%3d>
>>
>>   Clients MUST validate the ID Token in the Token Response in the
>> following manner:
>>
>> ...
>> 4. If the ID Token contains multiple audiences, the Client SHOULD verify
>> that an azp Claim is present.
>> ...
>> 5. If an azp (authorized party) Claim is present, the Client SHOULD
>> verify that its client_id is the Claim Value.
>> ...
>> 8 If the JWT alg Header Parameter uses a MAC based algorithm such as
>> HS256, HS384, or HS512, the octets of the UTF-8 representation of the
>> client_secret corresponding to the client_id contained in the aud
>> (audience) Claim are used as the key to validate the signature. For MAC
>> based algorithms, the behavior is unspecified if the aud is multi-valued or
>> if an azp value is present that is different than the aud value.
>> The current time MUST be before the time represented by the exp Claim.
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150810/3655822d/attachment.html>


More information about the Openid-specs-ab mailing list