I have one comment on the Security Considerations section and several
comments on the Privacy Considerations section.
*Security Considerations section(Section 5)
*
The intent of this comment is to add information, but not to change the
meaning.
Current text:
The JWT access token data layout described here is very similar to
the one of the id_token as defined by [OpenID.Core].
The explicit typing required in this profile, in line with the
recommendations in [RFC8725] helps the resource server to distinguish
between JWT access tokens and OpenID Connect ID Tokens.
Proposed text:
The JWT access token data layout described here is very similar to
the one of the id_token as defined by [OpenID.Core].
The explicit typing required in this profile (i.e. "at+jwt", see
section 2.1), in line with the recommendations in [RFC8725] helps
the resource server to distinguish between JWT access tokens (i.e. "
jwt") and OpenID Connect ID Tokens (i.e. either "jwt" or "json").
*Privacy Considerations section(Section 6)
*
Current text:
As JWT access tokens carry information by value, it now becomes
possible for clients and potentially even end users 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
(for example by switching from this profile to opaque tokens) hence
any logic in the client relying on the ability to read the access
token content would break without recourse.
The OAuth 2.0 framework assumes that access tokens are treated as
opaque by clients.Administrators of authorization servers should
also take into account
that the content of an access token is visible to the
client.Whenever client access to the access token content presents
privacy issues for a given scenario,
the authorization server should take explicit steps to prevent it.
Rational for a change:
The following sentence at the beginning of the second paragraph is correct:
"The OAuth 2.0 framework assumes that access tokens are treated as
opaque by clients".
The current first sentence says that it is possible to directly peek
inside the token claims collection. This is indeed possible /in the
context of this RFC/
(/i.e. not in general/) since that client is able to test if a "typ"
header parameter exists and if it contains the value " at+jwt".
It is sufficient to warn the reader that such peeking is not possible in
general, but is possible when/if the previous two conditions are satisfied.
Before proposing a text replacement, if we were using sub-paragraphs for
addressing the different topics, the text would be more readable:
6.1. Peeking inside the token claims collection
6.2. End-user identifier correlation
6.3. AS tracking
Let us start with the last one (6.3). An email sent by Vittorio Bertocci
on 2020-04-29 states in its last sentence:
" I’ll try to come up with concise language that clarifies to the
reader that the current mechanism does allow AS tracking".
See:
https://mailarchive.ietf.org/arch/msg/oauth/x2Xvd14hREBoYKEZ1h0bDsPRGKM/
However, no sentence has been added to address this warning. This
explains why I propose the following text :
6.3. AS tracking
Since an "aud" claim parameter is included by the AS inside every
access token, the AS is in a position to know
and trace where each access token is likely to be used. In addition,
if token introspection is used by the RS,
this allows the AS to know and trace exactly where and when each
access token has been used.This may be
a privacy concern for some end-users.
Let us come back to the three previously quoted paragraphs.
Proposed text replacement:
6. Privacy Considerations
6.1. Peeking inside the token claims collection
JWT access tokens issued under this profile include in the "typ"
header parameter of an access token the value "at+jwt"
to explicitly declare that the JWT represents an access token
compliant to this profile. This information allow RSs to know
if they receive an access token compliant to this profile.
The OAuth 2.0 framework assumes that access tokens are treated as
opaque by clients.
Nevertheless, when a client gets back an access token from an AS, if
the value "at+jwt" is present in the "typ" header parameter
of that access token, as such access tokens carry information by
value, it is possible for clients and potentially even end users
to directly peek inside the token claims collection.
However, the AS and the RS might decide to change the token format
at any time (for example by switching from this profile to opaque
tokens)
hence any logic in the client relying on the ability to read the
access token content would break without recourse.As a consequence,
clients
should not expect to be always able to inspect the content of access
tokens.
Furthermore, this profile does not allow a client to request an
access token format conformant to this profile.
Administrators of authorization servers should take into account
that the content of an access token is visible to the client.
If this is a concern for the AS, it should take explicit steps to
prevent it.
The three paragraphs that come after can remain unchanged. To be
explicit, here they are:
In scenarios in which JWT access tokens are accessible to the end
user, it should be evaluated whether the information can be accessed
without privacy violations (for example, if an end user would simply
access his or her own personal information) or if steps must be taken
to enforce confidentiality.
Possible measures to prevent leakage of information to clients and
end users include: encrypting the access token, encrypting the
sensitive claims, omitting the sensitive claims or not using this
profile, falling back on opaque access tokens.
In every scenario, the content of the JWT access token will
eventually be accessible to the resource server.It’s important to
evaluate whether the resource server gained the proper entitlement to
have access to any content received in form of claims, for example
through user consent in some form, policies and agreements with the
organization running the authorization servers, and so on.
The next and last original paragraph is addressing another topic. It
starts with the following sentence:
"This profile mandates the presence of the "sub" claim in every JWT
(...) ".
A key sentence is the following: " The "sub" claim should be populated
by the authorization servers according to a privacy impact assessment ".
This sentence does not provide a sufficient guidance. It is important to
mention that there exists three options for the "sub" claim:
* a globally unique identifier,
* a resource server specific identifier, or
* an access token specific identifier.
and then, although no specific parameter has been defined to allow the
client to choose between these three options,
it is possible for an AS to allow such a choice using the "scope" parameter.
Proposed text replacement for the last original paragraph:
6.2. End-user identifier correlation
This profile mandates the presence of the "sub" claim in every JWT
access token. The "sub" claim is defined in RFC 7519 (section 4.1.2)
in the following way:
"The subject value MUST either be scoped to be locally unique in the
context of the issuer or be globally unique."
When the subject value is scoped to be globally unique, it is
possible for every RS to use that information for correlating
incoming requests
with data stored locally for the authenticated principal with
different RSs. It is also possible for servers that are not resource
servers (RSs)
but which use the same globally unique identifiers for correlating
stored data.
Although the ability to correlate requests and stored data might be
required by design in some scenarios, there are scenarios where such
correlation is not desirable.
In such scenarios, the AS may use an identifier that is locally
unique in the context of the issuer: it may be unique either for
every RS or for every access token :
- In order to prevent tracking principal activities across multiple
resource servers, the authorization server should ensure that JWT
access tokens meant
for different resource servers have distinct "sub" values
that cannot be correlated in the event of resource servers collusion.
- In order to prevent a resource server from correlating the
principal’s activity within the resource itself, the authorization
server should assign different "sub" values
for every JWT access token issued.In turn, the client
should obtain a new JWT access token for every call to the resource
server, to ensure that the resource server
receives different "sub" and "jti" values at every call,
thus preventing correlation between distinct requests.
This profile does not define a specific parameter that allows a
client or an end-user to choose between these three options for the
"sub" claim parameter:
* a globally unique identifier (that allows correlations between
RSs and beyond),
* a resource server specific identifier (to prevent correlations
between RSs and beyond), or
* an access token specific identifier (for anonymous accesses to
one or more RSs).
The choice between these three options for the "sub" claim parameter
is managed by the AS.
However, if the AS supports a "scope" parameter in the access token
request, it is possible for the AS to define different scopes that
support one or more of these options.
Alternatively, an AS may use one of these options for all its
end-users or some of them on a per-user basis. In addition, such a
choice may depend on the RS being accessed.
Denis
The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document: - 'JSON Web Token (JWT) Profile
for OAuth 2.0 Access Tokens'
<draft-ietf-oauth-access-token-jwt-11.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2021-02-09. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.
Abstract
This specification defines a profile for issuing OAuth 2.0 access
tokens in JSON web token (JWT) format. Authorization servers and
resource servers from different vendors can leverage this profile to
issue and consume access tokens in interoperable manner.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
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
