Realm roles (group) missing when connecting MCP server using Dynamic Client Registration (DCR) in ChatGPT #43756

Lexachoc · 2025-10-22T13:40:17Z

Lexachoc
Oct 22, 2025

Before reporting an issue

I have read and understood the above terms for submitting issues, and I understand that my issue may be closed without action if I do not follow them.

Area

oidc

Describe the bug

When I use ChatGPT to add an MCP server with Keycloak as the authorization server, the client is created via Dynamic Client Registration (DCR). However, the resulting client’s access tokens do not include the realm roles associated to the user.

I expected that realm roles assigned to the user would be included in the token, but after DCR registration, they are missing. This breaks authorization for my backend MCP server, which relies on certain realm role to determine whether the user is authenticated.

Version

26.4.1

Regression

The issue is a regression

Expected behavior

Realm roles assigned to the user should appear in the access token for DCR-registered clients, or DCR should set Full scope allowed=true by default (consistent with clients created via the admin UI).

I've tested that both manually created public/confidencial client have Full scope allowed ON. But it is turned off for the DCR-registered clients.

Actual behavior

Access tokens from DCR-created clients omit all realm roles (except "offline_access") until Full Scope Allowed is manually enabled.

How to Reproduce?

Use ChatGPT to connect an MCP server to Keycloak (OAuth2 flow).
The MCP server uses DCR to automatically register a confidencial client.
Check the newly created client in the Keycloak admin console.
Go to Client scopes → DCR client-id-dedicated → Scope tab. By default, Full Scope Allowed = OFF.
When Full Scope Allowed is OFF, the access token looks like this (example):

{
  "exp": 1761096101,
  "iat": 1761092501,
  "auth_time": 1761092497,
  "jti": "d41ce6bf-4bdd-4a25-8f22-8d9e3c7c2760",
  "iss": "https://accounts.example.com/realms/example",
  "sub": "c2ef38e8-9632-499c-a973-24a4b8120572",
  "typ": "Bearer",
  "azp": "2c52c437-d5a6-4026-9727-c4f98660d0b7",
  "sid": "5cf3cd5e-c0c2-42c3-aea9-8ce712ad7519",
  "acr": "1",
  "allowed-origins": ["https://chatgpt.com", "*"],
  "realm_access": { "roles": ["offline_access"] },
  "scope": "phone offline_access microprofile-jwt address profile email",
  "upn": "user@example.com",
  "email_verified": true,
  "address": {},
  "name": "Example User",
  "groups": ["offline_access"],
  "preferred_username": "user@example.com",
  "given_name": "Example",
  "family_name": "User",
  "email": "user@example.com"
}

When Full Scope Allowed is ON, the access token looks like this (example):

{
  "exp": 1761139931,
  "iat": 1761136331,
  "auth_time": 1761136329,
  "jti": "c747789e-ff82-4464-b54f-bf4f0a247576",
  "iss": "https://accounts.example.com/realms/example",
  "aud": "account",
  "sub": "c2ef38e8-9632-499c-a973-24a4b8120572",
  "typ": "Bearer",
  "azp": "7aacafac-1c59-4f4e-9e4b-bc3881b17821",
  "sid": "793cb47b-b83c-4117-9f2f-e9daace4690c",
  "acr": "1",
  "allowed-origins": ["https://chatgpt.com"],
  "realm_access": {
    "roles": [
      "offline_access",
      "uma_authorization",
      "App-example-insider",
      "default-roles-example"
    ]
  },
  "resource_access": {
    "account": {
      "roles": ["manage-account", "manage-account-links", "view-profile"]
    }
  },
  "scope": "phone offline_access roles microprofile-jwt address profile email",
  "upn": "user@example.com",
  "email_verified": true,
  "address": {},
  "name": "Example User",
  "groups": [
    "offline_access",
    "uma_authorization",
    "App-example-insider",
    "default-roles-example"
  ],
  "preferred_username": "user@example.com",
  "given_name": "Example",
  "family_name": "User",
  "email": "user@example.com"
}

P.S. I need the realm role: "App-example-insider" to authenticate the user to access the backend endpoints, but the token (when Full Scope Allowed is OFF) doesn't contain associated realm roles (except "offline_access")!

I have checked also the mappers:
Client scopes → Roles

(The User Client Role mapper is also fully enabled.)

Anything else?

If I manually turn Full Scope Allowed = ON, realm roles immediately appear in the token and authorization works correctly in ChatGPT.
However, this manual step defeats the purpose of Dynamic Client Registration I think,DCR should produce a fully functional client configuration automatically.

My backend MCP server relies on realm roles to validate authentication.
Since ChatGPT’s DCR-created client receives an access token without associated realm roles (e.g., "App-example-insider"), all protected API endpoints respond with 403 Forbidden, and ChatGPT cannot successfully connect to my MCP server.

Is this behavior intended, or is it a bug in how Keycloak handles default scope settings for DCR-created clients?

My frontend application is a public client (React-based) that users log into directly.
However, the DCR process used by ChatGPT creates a confidential client for the MCP server.
I confirmed that when I manually create either a public or confidential client from the Keycloak admin console, Full Scope Allowed is ON by default.
Only the DCR-created client has Full Scope Allowed = OFF by default.
This difference appears to cause the missing realm roles.

I also tested that when Full Scope Allowed is turned OFF, even users logging in through my public client (React frontend) do not receive their assigned realm roles in the access token.

Am I misunderstanding how realm roles are supposed to be includ 10000 ed in tokens?

As a temporary workaround, I'm considering forcing the DCR-registered client to have Full Scope Allowed = ON automatically. However, I don't know how to do this.
Also, I’m not sure if this is the correct or secure approach or if there’s a better, recommended way to ensure realm roles are properly included in tokens for dynamically registered client (DCR).

Any guidance would be greatly appreciated!

Answered by stianst

Oct 28, 2025

The client registration policies just enforce what is possible, not what is configured. So, when you change the policy to allow full scope that just means that when creating a client using client registration you can specify full scope; however, that means using the Keycloak client representations and not standard OAuth/OIDC client metadata.

You'll probably want to do this by creating a client scope not using full scope allowed. We're overusing the name scope in Keycloak for sure, so let me try to explain

Create a client scope - make it optional and give it some name that you can refer to later
Under the scope tab for the client scope you create add the realm roles you need

Then you nee…

View full answer

Lexachoc · 2025-10-22T14:58:45Z

Lexachoc
Oct 22, 2025
Author

I read from Client Registration Policies:

It says:

Full Scope Policy - Newly registered clients will have Full Scope Allowed switch disabled. This means they won’t have any scoped realm roles or client roles of other clients.

And in the Client registration page:

It is clear that "Full Scope Allowed" is disabled. I wonder if this is disabled by default for all newly created DCR clients. What should we do to add the realm roles back?

Is removing the Full Scope Allowed policy a good idea? Is there a better way?

I confirmed that after removing this policy, the newly created DCR clients can have associated realm roles in the token.

0 replies

jbman · 2025-10-22T17:57:24Z

jbman
Oct 22, 2025

I thought that policy "Allowed Client Scopes" could be used to allow specific scopes in the DCR which then provide the required roles in the token.

However I could not make it work. This is my DCR:

curl --request POST \
  --url https://.../realms/example/clients-registrations/openid-connect \
  --header 'content-type: application/json' \
  --data '{
    "client_name": "TEST",
    "redirect_uris": [ "https://trusted-domain.com/code/" ],
    "grant_types": ["authorization_code","refresh_token"],
    "token_endpoint_auth_method": "none",
    "scope": "keycloak-admin-api"
  }'

...and it is rejected despite my change of the policy above:

{"error":"insufficient_scope","error_description":"Policy 'Allowed Clients Scopes' rejected request to client-registration service. Details: Not permitted to use specified clientScope"}

(Keycloak Version 26.0)

0 replies

stianst · 2025-10-28T07:17:27Z

stianst
Oct 28, 2025
Maintainer

The client registration policies just enforce what is possible, not what is configured. So, when you change the policy to allow full scope that just means that when creating a client using client registration you can specify full scope; however, that means using the Keycloak client representations and not standard OAuth/OIDC client metadata.

You'll probably want to do this by creating a client scope not using full scope allowed. We're overusing the name scope in Keycloak for sure, so let me try to explain

Create a client scope - make it optional and give it some name that you can refer to later
Under the scope tab for the client scope you create add the realm roles you need

Then you need to allow the above client scopes for dynamic client registration by going to clients, then client registration, and selecting anynomous or authenticated depending on how ChatGPT authenticates to the client registration endpoints. Updated Allowed Client Scopes to add the one you created earlier.

As a last step you need to make sure ChatGPT requests this scope when creating the client.

1 reply

Lexachoc Oct 29, 2025
Author

Thank you so much for your detailed guide! Very appreciated!

I want to confirm and share feedback about this.

================================================================================
I went to the dynamically registered client --> Client scopes:
The "roles" is already there by default when I do nothing you mentioned above about creating a new client scope.
Doesn't that mean that the roles are automatically mapped? Seems not.

So I tried the "Allowed Client Scopes" policy as well (@jbman also asked this before, but I got different error messages though):

But this doen't work. So I tried to allow all scopes:

Still not working.

Apparently, something is missing.

So I go back and follow your instructions, and this time it works!

What is the difference between the "Allowed Client Scopes" and the method you mentioned (create new client scope) ?
Is it the same if I don't create a new client area, but add the required realm roles directly to the default client scope "roles"?
Also, like @jbman said, we thought that policy "Allowed Client Scopes" could be used to allow specific scopes in the DCR.

To confirm my guess, I tried to add the required realm roles directly to the default client scope "roles", and leave the "Allowed Client Scopes" empty as it was by default. And it works now!

stianst · 2025-10-28T07:19:29Z

stianst
Oct 28, 2025
Maintainer

Moving this to a discussion as this is not a bug; rather it is expected that roles are not mapped to dynamically registered clients out of the box. Full scope allowed is also something that really should only be used for dev/testing purposes.

0 replies

jbman · 2025-10-29T17:56:24Z

jbman
Oct 29, 2025

I found that my DCR was rejected with following log message in the list:
Requested scope 'basic' not trusted in the list: [roles, keycloak-admin-api, profile, acr, roles, web-origins, role_list, roles, keycloak-admin-api, department.team_claim, extended, address, profile-options, uh_group_context, phone, offline_access, microprofile-jwt]
However "basic" was not explicitly requested, just "scope": "keycloak-admin-api".

How I could get working:

added the client scope "basic to my registration policy:

Send the DCR:

curl --request POST \
  --url https://.../realms/example/clients-registrations/openid-connect \
  --header 'content-type: application/json' \
  --data '{
    "client_name": "TEST",
    "redirect_uris": [ "https://trusted-domain.com/code/" ],
    "grant_types": ["authorization_code","refresh_token"],
    "token_endpoint_auth_method": "none",
    "scope": "keycloak-admin-api"
  }'

...then, registration was successful and the created client has client scopes:

TLDR: Add client scope "basic" to your client registration policy to make DCR work. This seems to be a workaround, as basic is not even configured as default but still added automatically

0 replies

Realm roles (group) missing when connecting MCP server using Dynamic Client Registration (DCR) in ChatGPT #43756

Uh oh!

Uh oh!

Lexachoc Oct 22, 2025

Before reporting an issue

Area

Describe the bug

Version

Regression

Expected behavior

Actual behavior

How to Reproduce?

Anything else?

Replies: 5 comments · 1 reply

Uh oh!

Uh oh!

Lexachoc Oct 22, 2025 Author

Uh oh!

Uh oh!

jbman Oct 22, 2025

Uh oh!

stianst Oct 28, 2025 Maintainer

Uh oh!

Lexachoc Oct 29, 2025 Author

Apparently, something is missing.

So I go back and follow your instructions, and this time it works!

Uh oh!

stianst Oct 28, 2025 Maintainer

Uh oh!

Uh oh!

jbman Oct 29, 2025

Lexachoc
Oct 22, 2025

Replies: 5 comments 1 reply

Lexachoc
Oct 22, 2025
Author

jbman
Oct 22, 2025

stianst
Oct 28, 2025
Maintainer

Lexachoc Oct 29, 2025
Author

stianst
Oct 28, 2025
Maintainer

jbman
Oct 29, 2025