Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Audience claim in access tokens #28

Open
acoburn opened this issue Dec 21, 2020 · 0 comments
Open

Audience claim in access tokens #28

acoburn opened this issue Dec 21, 2020 · 0 comments

Comments

@acoburn
Copy link

acoburn commented Dec 21, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant