cancel
Showing results for 
Search instead for 
Did you mean: 
Administration & Architecture
Explore discussions on Databricks administration, deployment strategies, and architectural best practices. Connect with administrators and architects to optimize your Databricks environment for performance, scalability, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 

Databrick Oauth federation

taglud_dbw
New Contributor II

I try to get databrick token from my databricks workspace, 

I set up properly databricks federation policy, but i still get this error.

"invalid_client": "user '123456' is not a member of workspace '123456' "

i have checked in databricks console workspace permission, the user is present, i gave him all the permission also "workspace access"

i have check the databricks console user management, the user is present. so the sync from IDP entra ID work properly.
i can not figure out what other issue could cause it to fail.

Thank you in advance for your help

 

2 REPLIES 2

Satyasai
New Contributor II

Check your Federation Policy in the Databricks Account Console > Security > Authentication.

Ensure the Subject claim field is explicitly set to preferred_username or User Principal Name (instead of the default).

Ashwin_DSA
Databricks Employee
Databricks Employee

Hi @taglud_dbw,

The "invalid_client": "user '123456' is not a member of workspace '123456' "  error during token federation means that the OAuth token exchange endpoint could not resolve the user as a direct member of the target workspace at the moment it tried to mint the token. Even though you are in the workspace UI and have all the right permissions, a few things can cause this mismatch.

Firstly, the token exchange endpoint checks workspace membership differently from how the admin console displays it. If you have access to the workspace only through a group (indirect assignment) rather than being directly added as a workspace member, the federation token exchange may not recognise you. Try explicitly adding your user name as a direct member of the workspace (not just via group membership) and test again. This is a known gap in certain configurations.

Secondly, verify if the username/email claim matches exactly. The federation flow uses a claim from your Entra ID token (typically sub, upn, or email) to look up the user in Databricks. If there is a case mismatch between the claim value and the username stored in Databricks, the lookup will fail. For example, if Entra sends User@Domain.com but Databricks has the user stored as user@domain.com, the token exchange can reject it. Check the subject_claim setting in your federation policy and compare the exact value in the token against what Databricks has stored for that user.

If you are using identity federation with SCIM or a similar sync mechanism, you need to be active in the Databricks account, not just present. A user who has been synced but has never completed an interactive login may be in an inactive state. Check if your status in the account console under User Management and confirm it shows as "Active."

Lastly, make sure your federation policy is configured at the right level. An account-wide federation policy lets any user in the account exchange tokens, while a service-principal-level policy is scoped to that specific SP. If you are using account-wide federation for end users, do not set client_id in the token exchange request. If you are using a service-principal-level policy, the client_id must match the SP's application ID. See the token exchange documentation for the exact request format.

If none of the above helps, open a support ticket with the decoded token claims and the exact federation policy configuration so the team can trace the lookup path.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.

Regards,
Ashwin | Delivery Solution Architect @ Databricks
Helping you build and scale the Data Intelligence Platform.
***Opinions are my own***