[keycloak-dev] Usage of "aud" claim in access tokens

[Nalyvayko, Peter]

Never mind, you did mention the ID token
________________________________________
From: Nalyvayko, Peter
Sent: Monday, June 26, 2017 11:13 AM
To: Schuster Sebastian (INST/ESY1); keycloak-dev
Subject: RE: Usage of "aud" claim in access tokens

Hey Sebastian,

According to OIDC spec (http://openid.net/specs/openid-connect-core-1_0.html):

ID Token
  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.
"
Unless I am misinterpreting the spec, the "aud" claim is expected to contain the client_id, no?

Regards,
Peter
________________________________________
From: keycloak-dev-bounces at lists.jboss.org [keycloak-dev-bounces at lists.jboss.org] on behalf of Schuster Sebastian (INST/ESY1) [Sebastian.Schuster at bosch-si.com]
Sent: Monday, June 26, 2017 7:41 AM
To: keycloak-dev
Subject: [keycloak-dev] Usage of "aud" claim in access tokens

Hi everybody,

While playing around with the authorization api and the photoz example I noticed the aud claim in the access token contained the client_id of the RP similar to the ID token. This was not quite what I expected. The client is the intended consumer of the ID token as per spec: “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.” So everything is fine here.

The consumer of the access token is in my opinion the resource server granting access based on content of the access token (in the case of opaque tokens, the client can’t even read the access token). Per JWT spec: “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 then this claim is present, then the JWT MUST be rejected.”

Therefore, for my access token of the photos example having the client id in the “aud” claim:
{
  "jti": "ad02bc48-ee9c-4480-b8d2-ca57547c8026",
  "exp": 1498475985,
  "nbf": 0,
  "iat": 1498475685,
  "iss": "http://localhost:8180/auth/realms/photoz",
  "aud": "photoz-html5-client",
  "sub": "73c303f1-7088-4f09-85c3-bd39a736c833",
  "typ": "Bearer",
  "azp": "photoz-html5-client",
  "nonce": "02df304b-199b-4dd8-923d-9cf470d1129a",
  "auth_time": 1498475685,
  "session_state": "e202b205-15bd-43c8-9fbd-cd602d0708f0",
  "acr": "1",
  "allowed-origins": [
    "*"
  ],
  "realm_access": {
    "roles": [
      "uma_authorization",
      "user"
    ]
  },
  "resource_access": {
    "photoz-restful-api": {
      "roles": [
        "manage-albums"
      ]
    },
    "account": {
      "roles": [
        "manage-account",
        "manage-account-links",
        "view-profile"
      ]
    }
  },
  "name": "Alice In Chains",
  "preferred_username": "alice",
  "given_name": "Alice",
  "family_name": "In Chains",
  "email": "alice at keycloak.org"
}

I would have expected an audience claim like “aud”:[“photoz-restful-api”, “account”, “http://localhost:8180/auth/realms/photoz”] (the first two for the resource servers defining the roles, the last one for the entire realm and the realm roles).

What do you think?

Best regards,
Sebastian



Mit freundlichen Grüßen / Best regards

Sebastian Schuster

Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Schöneberger Ufer 89-91 | 10785 Berlin | GERMANY | www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Geschäftsführung: Dr.-Ing. Rainer Kallenbach, Michael Hahn



_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev