OIDC Identity Provider (ADFS): scope not sent in token exchange request, groups claim missing

Getting advice
, , ,
1

Environment: Keycloak 26.2.4 (Quarkus), Oracle DB, ADFS as OIDC Identity Provider

Issue 1: Scope not included in token exchange POST request

We have Keycloak brokering authentication to Microsoft ADFS via OIDC. ADFS requires the allatclaims scope to include group claims in the token.

We configured defaultScope = “openid profile email allatclaims” in the ADFS Identity Provider settings. The authorization request (browser redirect) correctly includes scope=openid+profile+email+allatclaims, confirmed via HAR capture.

However, the token exchange request (POST to /adfs/oauth2/token) does NOT include the scope parameter. It only sends: code, grant_type, redirect_uri, client_secret, client_id.

ADFS responds with “scope”: “openid” and no group claims in the token.

We also tried setting sendScopeOnTokenExchange = true in the IDP config, no change observed.

Questions:

  1. Does Keycloak send the defaultScope in the token exchange POST body (authorization_code grant), or only in the authorization redirect?
  2. Is there a supported way to include the scope in the token exchange request?
  3. What does sendScopeOnTokenExchange actually control, the authorization_code exchange or only the token-exchange grant type?

Issue 2: Auto-linking brokered users to existing LDAP users

We have LDAP User Federation syncing users from Active Directory. When a user authenticates via ADFS for the first time, the First Broker Login flow triggers. “Create User If Unique” detects the existing LDAP user but cannot auto-link because “Handle Existing Account” requires password re-authentication, which ADFS-brokered users don’t have.

We searched for “Automatically Set Existing User” authenticator but it doesn’t appear available in 26.2.4.

Question: Is there a supported authenticator or configuration in Keycloak 26.2.4 to automatically link a brokered identity to an existing user (matched by username) without requiring password re-authentication?

Current workaround: Manually inserting records into the FEDERATED_IDENTITY table.

Summary

This text will be hidden