OFFICIAL
Thanks Max - and separate thanks to Neil and Aaron (I’ll create an issue on the
step-up draft).
> but it wants the client to go get a different token anyway?
In some cases, the RS could save the round-trip by issuing/returning the next
token inline (either minted by the AS via back-channel/token-exchange, or as an
RS-scoped continuation token). The idea is optimisation.
> How does the RS know what the client is going to do next?
Perhaps a contrived example, but something like:
*
Client PUT /file with access token -> RS
*
RS -> 200 OK {“processing”: true} - Authentication-Info: access_token=“abc”
expires_in=7200
*
(old token expired, so client can no longer put/post new file)
*
Client GET /status with new access token -> RS
*
(new token only has rights to perform get status request etc.)
*
RS -> 200 OK {“processed”: true} - Authentication-Info: access_token=“”
expires_in=0
The other flow I’m considering is if a client produces a JWT as a bearer, the
RS could ‘swap' for an access token, something like:
*
Client GET with bearer JWT (client has JWKS URI and CIMD) -> RS
*
RS gets remote resources, verifies sig and authorises client -> 200 OK -
Authentication-Info: access_token=“abc” expires_in=7200
*
(RS essentially saying - great thanks for the valid JWT but let's use an opaque
string now so you don’t have to sign a JWT and I don't need to look up keys
etc.)
*
Client GET with AT -> RS ...
*
(Client could still respond with a JWT and get a valid response, but RS is
indicating a preferred token)
> client is already given the expires_in in the original token response from
> the AS, and can store that value alongside the token today. I haven't run
> into a situation where the expiry of a token updates over time.
Yeah, valid! I suppose this could be a way to roll the expiry?
> token introspection endpoint today to retrieve the same set of information
True - just thinking it might be a way to optimise and reduce queries to the AS.
Thanks, Ollie
OFFICIAL
From: Max Gerber <[email protected]>
Date: Monday, 10 November 2025 at 23:12
To: Chalk, Ollie (DSIT) <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: [OAUTH-WG] Token Issuance/Introspection via Header
(Authentication-Info?)
> A motivating use case is where a client presents a valid bearer token to a
> resource server, and the server wishes to signal that a newer or
> context-specific token should now be used for subsequent requests.
Authentication-Info is used on successful requests, right? So this would mean
that the RS didn't fail the request, but it wants the client to go get a
different token anyway? I suppose the RS could inform the client that the
client could have used a more tightly-scoped token to perform the same request,
but I don't know how the RS could tell the client to get a more tightly-scoped
token for future requests. How does the RS know what the client is going to do
next? if the client reads resource A first, it might update resource B or
delete resource C in the next request. Do you have a more complete real world
example of context-specific scoping?
> The same header could also convey updated token information, such as revised
> expiry time:
> e.g. Authentication-Info: token_type="Bearer", expires_in=3351
If the client knows that its token is close to expiry, the client can perform a
token refresh in advance, instead of waiting for the token to expire and
retrying a failed request. However:
- The client is already given the expires_in in the original token response
from the AS, and can store that value alongside the token today. I haven't run
into a situation where the expiry of a token updates over time.
- If the AS supports it, the client can use the RFC
7662<https://datatracker.ietf.org/doc/html/rfc7662> token introspection
endpoint today to retrieve the same set of information
Best,
Max
On Mon, Nov 10, 2025 at 12:43 PM Chalk, Ollie (DSIT)
<[email protected]<mailto:[email protected]>>
wrote:
OFFICIAL
Hi all - great to meet some of you in Montreal!
I’ve been exploring an idea for an OAuth extension that would allow a resource
server (or authorisation server) to issue or indicate details about tokens in a
HTTP response header.
A seemingly obvious candidate is to use the existing Authentication-Info header.
e.g. Authentication-Info: token_type="Bearer", expires_in=3600,
access_token="YWNjZXNzX3Rva2VuIQ"
A motivating use case is where a client presents a valid bearer token to a
resource server, and the server wishes to signal that a newer or
context-specific token should now be used for subsequent requests.
The same header could also convey updated token information, such as revised
expiry time:
e.g. Authentication-Info: token_type="Bearer", expires_in=3351
New metadata fields could support discovery and registration:
*
token_response_modes_supported (AS metadata)
*
token_response_mode (client metadata / DCR)
Before drafting an Internet-Draft, I wanted to ask if there’s prior work or
existing discussion in this area (I did a quick search of the mailing list),
and whether there’s interest in standardising such a mechanism.
Thanks,
Ollie
OFFICIAL
_______________________________________________
OAuth mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
