You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At present both the access and id tokens return an audience (aud) claim equal to the client_id used in the OIDC grant (e.g. authorization code flow).
This is correct for ID tokens, since the audience of these tokens is the client itself. This is, however, incorrect for access tokens.
The first way this is incorrect is that the Solid-OIDC specification requires that the audience claim in access tokens be the string "solid".
The second way this is incorrect is that, according to the JWT specification (where the aud claim is defined), if an audience claim is provided and if an identifier for the receiving entity (i.e. the principal processing the claim) is not listed in the aud claim, then the token needs to be rejected.
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 case of a resource server, that identifier will not match, and therefore, according to RFC 7519, these access tokens should be rejected.
Using an NSS-based identity provider, I was able to login to an NSS-based Pod. The access token had the following claim:
{"aud": ["ccd63b7c8d824639f0cdefeab11bd9c2"]}
and the ID token had the following claim:
{"aud": "ccd63b7c8d824639f0cdefeab11bd9c2"}
The difference between list and bare string is not an issue from a spec perspective, though that is an unexpected inconsistency.
The text was updated successfully, but these errors were encountered:
At present both the access and id tokens return an audience (
aud
) claim equal to the client_id used in the OIDC grant (e.g. authorization code flow).This is correct for ID tokens, since the audience of these tokens is the client itself. This is, however, incorrect for access tokens.
The first way this is incorrect is that the Solid-OIDC specification requires that the audience claim in access tokens be the string "solid".
The second way this is incorrect is that, according to the JWT specification (where the
aud
claim is defined), if an audience claim is provided and if an identifier for the receiving entity (i.e. the principal processing the claim) is not listed in theaud
claim, then the token needs to be rejected.In the case of a resource server, that identifier will not match, and therefore, according to RFC 7519, these access tokens should be rejected.
Using an NSS-based identity provider, I was able to login to an NSS-based Pod. The access token had the following claim:
and the ID token had the following claim:
The difference between list and bare string is not an issue from a spec perspective, though that is an unexpected inconsistency.
The text was updated successfully, but these errors were encountered: