Hi John
On 11/08/16 23:24, John Bradley wrote:
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.
I was suspecting I might be on my own here yes :-)
It may be time for a interoperable JWT access token profile of some sort.
+1
We keep getting close with some of the PoP stuff but only specify parts.
Thanks, Sergey
John B.
On Aug 11, 2016, at 6:16 PM, Sergey Beryozkin <sberyoz...@gmail.com> 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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
