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(a)lists.jboss.org [keycloak-dev-bounces(a)lists.jboss.org] on behalf of Schuster Sebastian (INST/ESY1) [Sebastian.Schuster(a)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": &quot;alice(a)keycloak.org&quot; } 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@bosch-si.com<mailto:Sebastian.Schuster@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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev