Feature: Replace id_token with refresh token request #39

Closed
opened 2025-10-06 23:59:03 +03:00 by OVERLORD · 4 comments
Owner

Originally created by @cfpwastaken on GitHub.

Reproduction steps

  1. Perform regular OIDC auth
  2. Call POST /token with grant_type=refresh_token
  3. Receive a new Access and Refresh Token, but no new ID Token ):

Expected behavior

It should return a new ID Token too, as described in the OIDC specification in section 3.1.3.3.:

In addition to the response parameters specified by OAuth 2.0, the following parameters MUST be included in the response:

id_token
ID Token value associated with the authenticated session.

Actual Behavior

It omits the id_token from the response

Pocket ID Version

v1.10.0

Database

SQLite

OS and Environment

Docker on Alpine Linux v3.21 (Kernel 6.12.13-0-lts), served through Caddy

Log Output

No response

Originally created by @cfpwastaken on GitHub. ### Reproduction steps 1. Perform regular OIDC auth 2. Call POST /token with grant_type=refresh_token 3. Receive a new Access and Refresh Token, but no new ID Token ): ### Expected behavior It should return a new ID Token too, as described in the OIDC specification in section 3.1.3.3.: > In addition to the response parameters specified by OAuth 2.0, the following parameters MUST be included in the response: > > id_token > ID Token value associated with the authenticated session. ### Actual Behavior It omits the id_token from the response ### Pocket ID Version v1.10.0 ### Database SQLite ### OS and Environment Docker on Alpine Linux v3.21 (Kernel 6.12.13-0-lts), served through Caddy ### Log Output _No response_
OVERLORD added the needs more upvotes label 2025-10-06 23:59:03 +03:00
Author
Owner

@cfpwastaken commented on GitHub:

Seconding this ^^
The token might also contain outdated data (user changed their profile). Also, Keycloak for example does return a new id_token on refresh.

@cfpwastaken commented on GitHub: Seconding this ^^ The token might also contain outdated data (user changed their profile). Also, Keycloak for example does return a new id_token on refresh.
Author
Owner

@kmendell commented on GitHub:

The id token only holds the user information nothing about the access should it should never become "unusable" technically.

I talked with elias and im going to siwtch this to a feature request and mark it needs more upvotes, as this is a optional part of the spec so if the community wants it we can think about adding it in.

@kmendell commented on GitHub: The id token only holds the user information nothing about the access should it should never become "unusable" technically. I talked with elias and im going to siwtch this to a feature request and mark it needs more upvotes, as this is a optional part of the spec so if the community wants it we can think about adding it in.
Author
Owner

@kmendell commented on GitHub:

Correct, but in the case of a refresh_token in that flow its optional to return a new id_token since its the same sessions just refreshing the tokens for it:

12.2. Successful Refresh Response
Upon successful validation of the Refresh Token, the response body is the Token Response of Section 3.1.3.3 except that it might not contain an id_token.

So in short the id_token does not need to be returned in the refresh token, though it can be if the provider chooses too.

@kmendell commented on GitHub: Correct, but in the case of a refresh_token in that flow its optional to return a new id_token since its the same sessions just refreshing the tokens for it: > 12.2. Successful Refresh Response Upon successful validation of the Refresh Token, the response body is the Token Response of [Section 3.1.3.3](https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse) except that it might not contain an id_token. So in short the `id_token` does not need to be returned in the refresh token, though it can be if the provider chooses too.
Author
Owner

@ItalyPaleAle commented on GitHub:

@kmendell should we probably return it however? Since the old id_token may be expired by then and so would be unusable

@ItalyPaleAle commented on GitHub: @kmendell should we probably return it however? Since the old id_token may be expired by then and so would be unusable
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/pocket-id#39