On Aug 2, 2024, at 5:36 AM, Indeewari Wijesiri <indeewa...@gmail.com> wrote:
> Hi Warren,
>
> Thank you for your attention.
>
> When public web clients use the authorization code grant for authentication,
> a successful response includes an access token and, optionally, a refresh
> token. If the access token is a JWT rather than an opaque token, the identity
> server will issue a new JWT access token for each authentication request with
> the same client_id and scope, based on the "issued at" (iat) claim. This
> means each authentication attempt generates a new JWT access token.
>
Each interaction with the authorization endpoint with the user MUST generate a
new authorization code when using code grant type. An authorization code MUST
be short lived and single-use.
Beyond that, it is expected that servers have their own policy. There’s no
requirement they do refresh token rotation or support refreshes at all. There
is AFAIK no requirement that the new access token be different than a previous
access token, on grant or refresh. These are all policies for the AS to
implement.
Refresh token rotation (and making sure you issue new access tokens on refresh)
is effectively using the refresh token mechanism as a way to detect cloning. If
someone exfiltrates the access token (or even the access and refresh token) and
uses them independently, eventually the two clients will be out of sync, and
the server will have visibility that there are potentially multiple “clients”
using the tokens.
The queued security topics BCP (
https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ ) and the
BCPs for native applications and in-progress one for browser-based applications
are likely the best resources here for policy recommendations for AS
implementations/deployments. There are some cross-cutting recommendations for
all clients, but there may not be a best-fit policy if you have client
diversity (say, browser-based applications, smart tv and set-top box
applications, and third party hosted services needing long-running data access)
Another way of looking at it is that a client is being authorized for delegated
access for a period of time; you can represent that as a single access token, a
series of access tokens created off of a single refresh token, or a series of
access and refresh tokens. These could all effectively give the same access
over the same period of time.
Business and security/risk policies at the AS make this decision opaquely;
different clients might get tokens with different behaviors, and tokens with
different behaviors may be created by the scope or resource being requested.
The BCPs provide guidance to help the AS understand appropriate security and
risk decisions.
> In this context, how should the refresh token behave? Is it advisable to use
> a long-lived refresh token in conjunction with the JWT access token, or
> should the refresh token be rotated each time a new JWT access token is
> issued?
>
The browser-apps BCP (as an example) indicates that if you do, they MUST either
rotate on each refresh or that the refresh tokens be sender-constrained
(through a mechanism like DPoP). It requires certain token lifetime policies be
in place, but does not give mandates on what these lifetimes should be (e.g. 4
hours or 4 years). This advice comes from the higher risk of token exfiltration
in the browser environment when the credential is held within local storage
which is easily readable by javascript or the user.
I don’t expect it is common policy for a new access token (issued outside a
refresh, e.g. code grant) is associated with an existing authorization grant.
A browser-based client or native app client can have multiple concurrent
authorizations, because the end user may have multiple browsers/devices. These
sorts of “client instances” usually don’t have a way to be individually
identified, so (from the AS perspective) they have a lifetime of the token
validity. If a client does a code grant, there’s no way (in the core protocol)
to identify as a that being related to a previous grant.
> For opaque access tokens, since they are not renewed with each request, a
> long-lived refresh token can be used.
>
I am making an assumption that by ‘opaque access tokens’, you are speaking to
requiring a resource server to use an interface like the token introspection
endpoint to determine validity and purpose, rather than introspecting the token
contents based on some known format like RFC9068.
All access tokens should be effectively opaque to clients, so whether a token
is opaque or parsable doesn’t affect malicious clients having authorization.
Access token interpretation is set between resource servers and the AS.
-DW
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
