Re: [OAUTH-WG] JWS JWT Access Tokens and resource audiences

[Sergey Beryozkin <[e-mail]>]

Hi,


After updating my earlier code (where 'client_id' was set as the 
standard JWT access token 'aud' property) to use 'aud' to represent the 
resource audiences I'm now thinking how to represent a 'client_id' in 
this token.

For now if I'm using a 'client_id' claim, to be consistent with a 
standard token introspection response.

The other thing is how to represent a name of the user who authorized 
the code grant which was exchanged for this token.

Again I'm using a "username" claim, to be consistent with a standard 
token introspection response.

Also thinking, what value if any a 'sub' claim in such a token should 
have. I'm setting it to a unique user identifier (similarly to IdToken).

Any comments are welcome

Sergey

On 11/08/16 23:30, Sergey Beryozkin wrote:
> 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 <[e-mail]>
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>