> 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) <Ollie.Chalk= [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] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
