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

[Sergey Beryozkin]

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

[John Bradley]

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.

Post by Sergey Beryozkin
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.
"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
https://www.ietf.org/mailman/listinfo/oauth

[Sergey Beryozkin]

Hi John

Post by John Bradley
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 :-)

Post by John Bradley
It may be time for a interoperable JWT access token profile of some sort.

+1

Post by John Bradley
We keep getting close with some of the PoP stuff but only specify parts.

Thanks, Sergey

Post by John Bradley
John B.

Post by Sergey Beryozkin
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.
"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
https://www.ietf.org/mailman/listinfo/oauth

[Sergey Beryozkin]

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

Post by Sergey Beryozkin
Hi John

Post by John Bradley
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 :-)

Post by John Bradley
It may be time for a interoperable JWT access token profile of some sort.

+1

Post by John Bradley
We keep getting close with some of the PoP stuff but only specify parts.

Thanks, Sergey

Post by John Bradley
John B.

Post by Sergey Beryozkin
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.
"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
https://www.ietf.org/mailman/listinfo/oauth

[Brian Campbell]

Yeah, the client typically isn't the/an audience of an access token. The AT
is opaque to the client and the client never processes or validates it. So
aud would have the resource(s) and something else could carry the client
id.

FWIW, token exchange is looking to define and register "cid" as a JWT claim
for the client identifier:
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-05#section-4.3

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

Post by Sergey Beryozkin
Hi John

Post by John Bradley
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 :-)

Post by John Bradley
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

Post by John Bradley
John B.

Post by Sergey Beryozkin
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.
"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
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Sergey Beryozkin]

Hi Brian

Thanks, 'cid' is a proper compact name :-), I've made our code
configurable - to support reporting a client_id property either as a
'client_id' or 'cid' claim.

Cheers, Sergey

Post by Brian Campbell
Yeah, the client typically isn't the/an audience of an access token. The
AT is opaque to the client and the client never processes or validates
it. So aud would have the resource(s) and something else could carry the
client id.
FWIW, token exchange is looking to define and register "cid" as a JWT
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-05#section-4.3
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
Hi John
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
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.
"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
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>