Hi All
Awhile back I was asking why would self-contained JWS JWT access tokens
would be used (as opposed to JWE JWTs), my concern was that anyone with
a JWT library can read this token's content - but as I was explained
that should not be a problem if such a JWS JWT token contains
non-sensitive information. Besides, in some cases, it gives RS an option
to validate this JWS JWT locally, without having to make a remote
validation call.
So I've started experimenting and the immediate question I have is this
one: which claim should one use to represent a resource server audience
to get the most inter-operable RS level validation logic ?
For example, a given RS may talk to different 3rd party authorization
servers, say AS1 (vendor1) and AS2 (vendor2), and either AS1 or AS2 JWS
JWT tokens that this RS validates locally should ideally use the same
claim to represent a resource audience. RS validation logic is written
independently (without using AS1 or AS2 aware validation libraries).
We do expect such requirements coming in our deployments. AS1 &
independent validation logic is already in use. Just a matter of time
before AS2 is introduced.
So JWT has a standard 'aud' claim - but I believe this should be a
'clientId' of the client a token is issued to, similarly to the way the
'aud' is treated in IdToken.
So I've prototyped the code where JWT has these claims:
"aud" = clientId
"resource" = 'http://myResourceServer'
where 'resource' is borrowed from OAuth2 Resource Indicators draft and
represent a specific RS target address, the resource server audience.
Am I on the right path ? How would others do it when facing a task of
including a resource audience in a self-contained JWS JWT access token ?
Many thanks, Sergey
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
