Custom user attributes intermittently missing from access tokens with user federation and password grant (v26.1.0, Quarkus-based Keycloak) #39692

jonathankamau · 2025-05-13T15:55:05Z

jonathankamau
May 13, 2025

Hi Keycloak team and community,

I'm encountering an intermittent issue where custom user attributes injected via a user federation plugin are not consistently included in access tokens issued through the password grant type. This occurs in Keycloak v26.1.0 (Quarkus-based).

🔧 Environment Details

Keycloak version: 26.1.0
Distribution: Quarkus-based
Client type: Public
Flow used: password grant type
Scopes requested: Always includes openid, profile, and additional custom scopes.
Token endpoint used: /realms/{realm}/protocol/openid-connect/token
User federation setup:
- A plugin using a custom LegacyUserService that fetches user data from a remote API
- Wired via a UserStorageProviderFactory
- No local import; Keycloak always delegates to the remote API
- getAttributes() is overridden in the custom UserAdapter to expose external user fields

💡 What I'm Observing

Access tokens most of the time will contain the expected custom claims.
There are a few odd cases where, with the same credentials and scope parameters, the access token is issued without those claims.
So far the inconsistency is only observed with requests originating from the mobile application (IOS and Android).
When the same token request is executed using curl from a terminal, postman or web app, the token always includes all expected custom attributes.

✅ What I've Verified / Ruled Out

The custom protocol mappers are configured in a client scope, with "Add to access token" enabled.
The client scope is assigned to the client as a default scope.
Scopes are consistent across all test cases.

🕵️‍♂️ Additional Observations

This issue only occurs intermittently with mobile-originated requests; the same token request made using from other sources yields the expected result every time.
This suggests the federation plugin is behaving correctly and returning user attributes, but that something in the request context may be altering behavior.

📋 Questions / Help Needed

Are there known issues with user federation-based attribute access during token generation in the password grant flow in recent Keycloak versions?
Are there log categories that would help confirm whether protocol mappers are executing with access to user attributes?
Could this be caused by token generation happening before federation attribute hydration completes?
Is there anything else I need to override or explicitly implement in the custom provider to ensure attributes are always accessible during token creation?

Thanks in advance for your help on this!

Navigation Menu

Repository navigation

Custom user attributes intermittently missing from access tokens with user federation and password grant (v26.1.0, Quarkus-based Keycloak) #39692

Uh oh!

{{title}}

Uh oh!

Replies: 0 comments

Select a reply

Uh oh!

Custom user attributes intermittently missing from access tokens with user federation and password grant (v26.1.0, Quarkus-based Keycloak) #39692

Uh oh!

jonathankamau May 13, 2025

🔧 Environment Details

💡 What I'm Observing

✅ What I've Verified / Ruled Out

🕵️‍♂️ Additional Observations

📋 Questions / Help Needed

Replies: 0 comments

jonathankamau
May 13, 2025