Correctly populate `expires_in` in internal-to-external token exchange responses for oauth2 IDPs #45702

Paul-E · 2026-01-22T23:49:06Z

Paul-E
Jan 22, 2026

I noticed when doing internal-to-external token exchange against a federated oauth 2 IDP, the expires_in in the response always has a 0 value, even if the token is not expired, and even when the external IDP provides a expires_in value during authentication.

Looking at the implementation of token exchange in oauth 2.0, it looks like the expiration is unconditionally set to 0:

keycloak/services/src/main/java/org/keycloak/broker/oidc/AbstractOAuth2IdentityProvider.java

Line 443 in a24183a

tokenResponse.setRefreshExpiresIn(0);

Whereas in OIDC, it looks like there is some logic to set this value intelligently

keycloak/services/src/main/java/org/keycloak/broker/oidc/OIDCIdentityProvider.java

Lines 219 to 259 in a24183a

    
           if (exp != null && exp <= currentTime + getConfig().getMinValidityToken()) { 
        
               if (tokenResponse.getRefreshToken() == null) { 
        
                   return exchangeTokenExpired(uriInfo, authorizedClient, tokenUserSession, tokenSubject); 
        
               } 
        
               String response = getRefreshTokenRequest(session, tokenResponse.getRefreshToken(), 
        
                       getConfig().getClientId(), vaultStringSecret.get().orElse(getConfig().getClientSecret())).asString(); 
        
               if (response.contains("error")) { 
        
                   logger.debugv("Error refreshing token, refresh token expiration?: {0}", response); 
        
                   model.setToken(null); 
        
                   session.users().updateFederatedIdentity(authorizedClient.getRealm(), tokenSubject, model); 
        
                   event.detail(Details.REASON, "requested_issuer token expired"); 
        
                   event.error(Errors.INVALID_TOKEN); 
        
                   return exchangeTokenExpired(uriInfo, authorizedClient, tokenUserSession, tokenSubject); 
        
               } 
        
               AccessTokenResponse newResponse = JsonSerialization.readValue(response, AccessTokenResponse.class); 
        
               if (newResponse.getExpiresIn() > 0) { 
        
                   int accessTokenExpiration = currentTime + (int) newResponse.getExpiresIn(); 
        
                   newResponse.getOtherClaims().put(ACCESS_TOKEN_EXPIRATION, accessTokenExpiration); 
        
               } 
        
               if (newResponse.getRefreshToken() == null && tokenResponse.getRefreshToken() != null) { 
        
                   newResponse.setRefreshToken(tokenResponse.getRefreshToken()); 
        
                   newResponse.setRefreshExpiresIn(tokenResponse.getRefreshExpiresIn()); 
        
               } 
        
               response = JsonSerialization.writeValueAsString(newResponse); 
        
               String oldToken = tokenUserSession.getNote(FEDERATED_ACCESS_TOKEN); 
        
               if (oldToken != null && oldToken.equals(tokenResponse.getToken())) { 
        
                   int accessTokenExpiration = newResponse.getExpiresIn() > 0 ? currentTime + (int) newResponse.getExpiresIn() : 0; 
        
                   tokenUserSession.setNote(FEDERATED_TOKEN_EXPIRATION, Long.toString(accessTokenExpiration)); 
        
                   tokenUserSession.setNote(FEDERATED_REFRESH_TOKEN, newResponse.getRefreshToken()); 
        
                   tokenUserSession.setNote(FEDERATED_ACCESS_TOKEN, newResponse.getToken()); 
        
                   tokenUserSession.setNote(FEDERATED_ID_TOKEN, newResponse.getIdToken()); 
        
               } 
        
               model.setToken(response); 
        
               session.users().updateFederatedIdentity(authorizedClient.getRealm(), tokenSubject, model); 
        
               tokenResponse = newResponse; 
        
           } else if (exp != null) { 
        
               tokenResponse.setExpiresIn(exp - currentTime); 
        
           }

The documentation indicates this is a known possibility, though it doesn't document when:

Expiration information may or may not be included for clients requesting an external issuer through the requested_issuer parameter.

It looks like there has been a lot of work recently around token exchange, and this might easier to solve now. This would create a more consistent experience when using token exchange. Callers of token exchange endpoints wouldn't need to be aware if an IDP is oauth 2 or not.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Correctly populate `expires_in` in internal-to-external token exchange responses for oauth2 IDPs #45702

Uh oh!

{{title}}

Uh oh!

Replies: 0 comments

Select a reply

Uh oh!

Correctly populate expires_in in internal-to-external token exchange responses for oauth2 IDPs #45702

Uh oh!

Paul-E Jan 22, 2026

Replies: 0 comments

Correctly populate `expires_in` in internal-to-external token exchange responses for oauth2 IDPs #45702

Paul-E
Jan 22, 2026