10:14 a.m.
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": "alice(a)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@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