AI Agent acting on behalf of a user: tokens can’t be refreshed after the user logs out #53875

mosherobinov · 2026-10-12T17:30:13Z

mosherobinov
Oct 12, 2026

I have the following setup:

The user logs in to our web app through a gateway (a confidential client using the authorization code flow). The gateway keeps the user’s tokens in its server-side session.
In the app, the user starts a chat with an AI agent. The agent is a separate back-end service with its own confidential client.
The gateway forwards the user’s access token to the agent. The agent exchanges it for its own token using standard token exchange V2, with refresh tokens allowed for the same session (SAME_SESSION).
The agent uses that token to call our internal MCP servers and APIs as the user, and refreshes it as needed. A run can take minutes to hours.

Problem

If the user logs out mid-run, the agent’s refresh fails because its token belongs to the user’s session, and the run fails.

Constraints: the agent must act as the user (not a service account), with no extra login or consent screen.

What we’ve considered

offline_access in token exchange: not supported in V2.
The gateway gets an offline token and the agent exchanges from it: we get an access token but no refresh token.
A longer access token lifespan on the agent client: tokens can’t be revoked and stay usable after logout. That’s poor security practice.
The agent gets its own offline token through a silent auth code request (prompt=none, scope=offline_access) while the user’s SSO session is active.
JWT authorization grant / identity assertion JWT (ID-JAG): preview, and no refresh tokens.

Questions

What’s the recommended pattern for an agent that must keep acting as a user after their session ends?
Is option 4 the intended approach, or can token exchange give a long-lived or offline token?
Are there plans to support this case in token exchange or the JWT authorization grant?

Answered by AZapata27

Oct 13, 2026

With what Keycloak ships today, option 4 is the way to go. Standard token exchange won't give you an offline or long-lived token, and that's by design.

In V2 the refresh setting only has two values, NO and SAME_SESSION. If the subject token comes from an offline (or transient) session, asking for requested_token_type=refresh_token fails with "creating a new session is needed". An access-token exchange is then served from a transient session, which is why option 2 gives you no refresh token. offline_access is also rejected explicitly. This was a deliberate choice when V2 was designed: in #37115 minting offline tokens through exchange was considered too powerful, with a note to revisit if p…

View full answer

AZapata27 · 2026-10-13T06:55:39Z

AZapata27
Oct 13, 2026

With what Keycloak ships today, option 4 is the way to go. Standard token exchange won't give you an offline or long-lived token, and that's by design.

In V2 the refresh setting only has two values, NO and SAME_SESSION. If the subject token comes from an offline (or transient) session, asking for requested_token_type=refresh_token fails with "creating a new session is needed". An access-token exchange is then served from a transient session, which is why option 2 gives you no refresh token. offline_access is also rejected explicitly. This was a deliberate choice when V2 was designed: in #37115 minting offline tokens through exchange was considered too powerful, with a note to revisit if people asked. See StandardTokenExchangeProvider#exchangeClientToOIDCClient and the "standard token exchange details" section of https://www.keycloak.org/securing-apps/token-exchange. The delegation preview in 26.8 and the JWT authorization grant also issue access tokens only, in transient sessions, so neither helps here yet.

For option 4, a few things matter:

The prompt=none request has to go through the user's browser. Do it as a top-level redirect right after the gateway login (or when the chat starts), with the code delivered to the agent's own redirect URI. Iframes tend to break with third-party cookie blocking.
The agent client needs the standard flow enabled, offline_access as an optional scope and Consent required off. Otherwise prompt=none should come back with consent_required.
Make that request after the gateway already has its online session. Since 26.1, if offline_access is the first request of a session, the online session is dropped.
Set Client Offline Session Idle/Max on the agent client to roughly your longest run (Max needs "Offline Session Max Limited" enabled at realm level), and revoke the token when the run finishes. Users can also see and revoke it in the account console.

The tradeoff is that logout no longer stops the agent, so decide explicitly whether logging out should cancel running jobs.

If you want token exchange to cover this natively, I'd open a feature request referencing #37115.

0 replies

mosherobinov · 2026-10-14T06:51:03Z

mosherobinov
Oct 14, 2026
Author

Thanks for the quick reply!

0 replies

Navigation Menu

Repository navigation

AI Agent acting on behalf of a user: tokens can’t be refreshed after the user logs out #53875

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 2 comments

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

AI Agent acting on behalf of a user: tokens can’t be refreshed after the user logs out #53875

Uh oh!

Uh oh!

mosherobinov Oct 12, 2026

Problem

What we’ve considered

Questions

Replies: 2 comments

Uh oh!

AZapata27 Oct 13, 2026

Uh oh!

mosherobinov Oct 14, 2026 Author

mosherobinov
Oct 12, 2026

AZapata27
Oct 13, 2026

mosherobinov
Oct 14, 2026
Author