[Openid-specs-ab] aud & azp

Brian Campbell bcampbell at pingidentity.com
Wed Aug 5 17:11:06 UTC 2015


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
<http://tools.ietf.org/html/rfc7519#section-4.1.3> and its use in Connect's
ID Token <http://openid.net/specs/openid-connect-core-1_0.html#IDToken>
(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
<http://openid.net/specs/openid-connect-core-1_0.html#IDToken> and the ID
Token Validation section
<http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation>
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

 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
  ...
  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

  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/20150805/33903724/attachment.html>


More information about the Openid-specs-ab mailing list