[Openid-specs-ab] Issue #973: Core 2 / 3.1.3.7 - azp claim underspecified (openid/connect)

Brian Campbell issues-reply at bitbucket.org
Thu Aug 6 12:13:38 UTC 2015


New issue 973: Core 2 / 3.1.3.7 - azp claim underspecified
https://bitbucket.org/openid/connect/issues/973/core-2-3137-azp-claim-underspecified

Brian Campbell:

>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](http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation) section 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, would contradict RFC 7519, and is certainly more cumbersome for general JWT libraries to support.



from [http://tools.ietf.org/html/rfc7519#section-4.1.3](http://tools.ietf.org/html/rfc7519#section-4.1.3)

```
#!text

 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](http://openid.net/specs/openid-connect-core-1_0.html#IDToken)


```
#!text

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


```
#!text

Clients MUST validate the ID Token in the Token Response in the following manner:
...
  3. The Client MUST validate that the aud (audience) Claim contains its client_id
    value registered at the Issuer identified by the iss (issuer) Claim as an audience. 
    The aud (audience) Claim MAY contain an array with more than one element.
    The ID Token MUST be rejected if the ID Token does not list the Client as a
    valid audience, or if it contains additional audiences not trusted by the Client. 
  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.
...
```





More information about the Openid-specs-ab mailing list