Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

[Vittorio Bertocci <[e-mail]>]

Hi Denis,
Thank you for your feedback!
Inline

> Privacy has not really been a concern in the WG since originally the AT and the RS were co-located.
Colocation of AS and RS was a frequent occurrence, but by no mean mandatory… AFAIK one of the drivers for the changes between OAuth1 and OAuth2 was providing the ability of supporting topologies where AS and RS are distinct right out of the box.
The scenario where AS and RS are distinct was always possible in Outh2, and and not by accident. The JWT AT just happens to be particularly handy in empowering the RS to validate incoming tokens without having to phone home to the AS every time, hence it gives the opportunity to discuss implications of that scenario more in depth, but doesn’t really introduce anything that wasn’t possible before. Even the possibility of a token format passing info by value isn’t forbidden, default OAuth2 ATs are not mandatorily opaque- they just happen not to have a well defined format.

>In such cases, it is important to be able to make sure that an authorization server will NOT be able to know where the authorizations
tokens that it issues will be used. Using another wording, an AS SHALL NOT be able to know where an AT requested by a given client will be used:
Authorization servers SHALL not have the capability to act as "Big Brother" and thus SHALL not be able to know which resources are going
to be accessed by clients.
The scenario in which a token issuer isn’t aware of where the client will spend the corresponding token is important, but it is more the province of SSI than mainstream OAuth2 usage today.
Mainstream OAuth2 in current use, regardless of the AT format, typically do know for whom the token is being issued: a great deal of logic is predicated on that knowledge. Did the user consent for this client to access this particular resource? Does access to this resource warrant presenting a stronger authentication prompt? Are there other authorization considerations that influences whether the requested token should be issued? Those are considerations an AS need to be able to perform in the general case, regardless of the AT format. That doesn’t mean they MUST be done in every case, but making them impossible would deny a lot of very important scenarios for which JWT ATs (and ATs in general) are used for today.
The split structure you suggest is interesting, but I would recommend is enshrined in its own spec (maybe in the SSI orbit) rather than in an interop profile for the general AT case.

>On the contrary, a client SHALL be able to inspect the content of the access token to make sure that the AS has not included in the AT some private information
that should not be present, before forwarding the AT to the RS. It is possible for an AS to change the format of the AT, but the RS will not necessarily be in synch
with the RS.
I can see the value in doing what we can to prevent abuses, but I find this requirement problematic. The access token is an artifact meant to enable the client to access a resource. Its format remains a private matter between the RS and the AS, which retains the freedom to change it as they see fit without worrying about client code that takes a dependency on characteristics of the AT that might very well be transient. As far the client is concerned, the RS and the AS might switch their agreement from JWT AT to opaque tokens to be validated via introspection at any time, which would break any client side logic inspecting the AT and expecting it to be a JWT. The client has no control whatsoever on the content that is transmitted via opaque token, hence privacy-wise the fact that the content of the JWT is visible is more of a concern about such content being accessible on the client. One additional point: even if clients would be able to safely peek inside an AT without risking breaking their code, there’s no guarantee that the client would understand the semantic of the claims in the AT, as those are meant for consumption by the RS which can assign any semantic to them; nor the client can reliably trust the content of the claims, given that the AS could and sometimes will encrypt their content for the intended recipient (another reason for which the AS in the general case needs to know the intended recipient).

>. It is possible for an AS to change the format of the AT, but the RS will not necessarily be in synch with the RS.
I don’t understand this sentence. Is the last RS meant to be AS?
Assuming that’s the case: It doesn’t look very likely that an RS would simply accept tokens from an AS without some out of band negotiation, nor it seems very likely that an AS would issue tokens for resources it doesn’t know- see above. Such scenarios might exist, but they don’t seem to model common business solutions or the typical deployment, where an API will be protected by middleware/gateway with precise assumptions on how to validate incoming tokens. There might be changes that are inconsequential (order of claims, additional claims) but anything more substantive would likely simply break the solution.

> This means that an identifier of the profile of the AT should be able to be included into the AT. This allows for future extensions.
Can you expand on the exact scenario you are thinking of that calls for a version? If it’s a matter of extensions, those should always be possible – it’s more breaking changes that require versioning, but I don’t recall precedents in similar specs.
If this is aimed at mitigating the “AS changes format without telling RS”, I don’t think that would work – besides of being unnecessary per the above considerations, this wouldn’t protect the RS from changes well within the current spec (which allows adding arbitrary claims as long as it’s done according to JWT rules), from changes within the claim content (eg private string formats) and from complete departures from the use of JWT for ATs.

> Allowing a client to only specify a scope and a resource is very restrictive.
Specifying scope or using resource indicators are all the mechanisms I am aware of that OAuth2 offers for specifying what an access token should be for- at least at the time in which the spec was incepted. In fact, resource indicators was not even RFC and in market vendors used proprietary functional equivalents. What other interoperable mechanisms would you offer in addition to the ones listed here?


From: OAuth <[e-mail]> on behalf of Denis <[e-mail]>
Date: Thursday, April 9, 2020 at 09:26
To: oauth <[e-mail]>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

I have three concerns, two of them being related to privacy.

1) Privacy has not really been a concern in the WG since originally the AT and the RS were co-located. However, this draft now recognizes
that there may exist cases where "the authorization server and resource server are not co-located, are not ran by the same entity,
or are otherwise separated by some boundary".

In such cases, it is important to be able to make sure that an authorization server will NOT be able to know where the authorizations
tokens that it issues will be used. Using another wording, an AS SHALL NOT be able to know where an AT requested by a given client will be used:
Authorization servers SHALL not have the capability to act as "Big Brother" and thus SHALL not be able to know which resources are going
to be accessed by clients.
This means that, in such cases, an authorization server SHALL not be able to know for which resource server an AT has been targeted.
It is a fact that most solutions currently deployed support a built-in "Spy by design" architecture instead of a "Privacy by design" architecture.
However, for security reasons an AT still needs to be targeted.

The problem to be solved is the following:

  *   for security reasons, the AT must be targeted.
  *   for privacy reasons, the AS must be kept ignorant of the name of the target.
One way to solve the problem is to consider that the AT is composed of a sequence of two structures: a signed structure and an unsigned structure.

The signed structure contains a "salted aud claim".
The unsigned structure contains a "aud salt claim".

In practice, the "salted aud claim" will be composed of both a one way hash function algorithm identifier and a hash value.
Before requesting an AT to an AS, the client chooses a resource server and select a resource indicator value corresponding to the identifier the resource server.
It then chooses a random value which it uses as a "aud salt claim" and then computes a hash value by using a one-way hash function which combines
one of the resource indicators of the RS with the "aud salt claim". Both the one way hash function algorithm identifier and the computed  hash value
are then included into the "salted aud claim".
The AT request then contains a "salted aud claim" instead of an"aud claim". The AT blindly copies this value into the AT which is then identified as
a "salted aud claim" instead of an "aud claim".
When the AT is received by the client, it adds to the AT the unsigned part to the AT which contains the "aud salt claim" and sends both the signed
and the unsigned part of the AT to the RS.

When the RS receives the AT, using the one way hash function algorithm identifier contained in the "salted aud claim", it combines each of its resource indicators
with the "aud salt claim" contained in the unsigned part of the AT and verifies whether it matches with the hash value contained in the "salted aud claim".
If none of these resource indicators is providing a match, then the RS SHALL rejected the AT.

The implication is to allow an AT to contain both a signed part and an unsigned part.

In addition, the "aud claim" should be multi-valued where, as a consequence, both the "salted aud claim" with the "aud salt claim" would also be multi-valued.


2) Within clause 6, "Privacy Considerations", the text states:

   As JWT access tokens carry information by value, it now becomes
   possible for requestors and receivers to directly peek inside the
   token claims collection.  The client MUST NOT inspect the content of
   the access token: the authorization server and the resource server
   might decide to change token format at any time (...).

On the contrary, a client SHALL be able to inspect the content of the access token to make sure that the AS has not included in the AT some private information
that should not be present, before forwarding the AT to the RS. It is possible for an AS to change the format of the AT, but the RS will not necessarily be in synch
with the RS.

Since there are now cases where "the authorization server and resource server are not co-located, are not ran by the same entity, or are otherwise separated
by some boundary", a key point is that an AS and a RS DO NOT necessarily need to know each other. The RS only needs to trust the AS. (full stop)

This means that an identifier of the profile of the AT should be able to be included into the AT. This allows for future extensions.

In any case, the "MUST NOT" in the quoted sentence should be removed or changed or the whole sentence should be removed..


3) Within clause 2.2.2 (second paragraph):

   This profile does not introduce any mechanism for a client to
   directly request the presence of specific claims in JWT access
   tokens, as the authorization server can determine what additional
   claims are required by a particular resource server by taking in
   consideration the client_id of the client, the scope and the resource
   parameters included in the request.

Allowing a client to only specify a scope and a resource is very restrictive.

What would be the title of an RFC that would allow the client to request the presence of specific claims in JWT access ?

If such a restriction is kept, would the current title of this RFC still be inappropriate
"JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" ?

Denis
DP Security Consulting