I think most people put the a resource URI in the aud. Connect uses the client ID as that is bit more stable than trying to use a redirect URI when there could be multiple ones. Given that a resource server doesn’t typically have a client_id the resource uri make a reasonable value.
You could put it in resource if you like, but that is probably not what others are doing. It may be time for a interoperable JWT access token profile of some sort. We keep getting close with some of the PoP stuff but only specify parts. John B. > On Aug 11, 2016, at 6:16 PM, Sergey Beryozkin <[email protected]> wrote: > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
