-
Notifications
You must be signed in to change notification settings - Fork 22
Description
Spec:
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 when this claim is present, then the JWT MUST be
rejected
I interpret the above as:
When JWT has an aud
claim present, the code calling jwt.Verify()
must also specify an audience key that must be one of the items in JWT's aud
array.
I would expect this to fail:
jwt.Verify(jwt.EdDSA, signerPubKey, tokenBytes)
But instead I need to add to get verification to fail when there's an audience mismatch:
jwt.Verify(jwt.EdDSA, signerPubKey, tokenBytes, jwt.Expected{
Audience: jwt.Audience{"bar"},
})
My concrete use case: I have an single-sign on server for a multi-tenant app. The aud
is the tenant ID, and is always present when the SSO server issues the JWT.
Now if I have code that forgets to add jwt.Expected{Audience: jwt.Audience{"bar"},}
, then I'll accidentally accept JWT for any tenant, when JWT spec compliant library would've protected me from processing a JWT that I wasn't the audience for.
e.g. tenant 2's user 4's JWT works for tenant 3 as well, accessing data for a different user because I forgot to specify the audience. A spec-compliant JWT library would prevent this accident.