Add group_id support for assuming a group during U2M OAuth login#1747
Open
grundprinzip wants to merge 2 commits into
Open
Add group_id support for assuming a group during U2M OAuth login#1747grundprinzip wants to merge 2 commits into
grundprinzip wants to merge 2 commits into
Conversation
Add the ability to assume a Databricks group during the user-to-machine (U2M) OAuth login flow. When configured, the numeric group ID is sent as the `assume_group` query parameter on the `/oidc/v1/authorize` request. The server validates that the user may assume the group and bakes the claim into the minted access token, so no header or parameter needs to be attached to subsequent API calls. Changes: - Add `Config.AssumeGroupID` (`group_id` in profiles, `DATABRICKS_GROUP_ID` env var) so `.databrickscfg` profiles can carry an optional group ID. - Add the `u2m.WithAssumeGroup` PersistentAuth option, injecting `assume_group` into the authorize URL for both the standard PKCE flow (appended to the authorization endpoint) and the discovery flow (set on the nested destination_url). - Reject assuming a group for account-level logins at construction time, mirroring the server-side workspace-only constraint. Assuming a group is only supported for workspace-level U2M logins. The value is decided at login time; the SDK's runtime databricks-cli token source is unaffected. Co-authored-by: Isaac Signed-off-by: Martin Grund <martin.grund@databricks.com>
grundprinzip
temporarily deployed
to
test-trigger-is
July 3, 2026 11:58 — with
GitHub Actions
Inactive
The workspace-only guard for assume_group enumerated the account cases (account argument and account-targeted discovery) as a blocklist, which let a UnifiedOAuthArgument through. Unified arguments are account-capable -- they carry an account ID and authenticate via the account/unified endpoint -- so assume_group would be appended to a non-workspace authorize URL and only rejected server-side, defeating the intended fail-fast. Switch the guard to an allowlist: permit assume_group only for a workspace argument or a non-account-targeted discovery login, and reject everything else. This also prevents future account-capable argument types from slipping through by default. Expand the validation test to cover workspace, discovery, account, unified, and account-targeted discovery arguments. Co-authored-by: Isaac Signed-off-by: Martin Grund <martin.grund@databricks.com>
grundprinzip
temporarily deployed
to
test-trigger-is
July 3, 2026 12:30 — with
GitHub Actions
Inactive
|
If integration tests don't run automatically, an authorized user can run them manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Add the ability to assume a Databricks group during the user-to-machine (U2M) OAuth login flow. When configured, the numeric group ID is sent as the
assume_groupquery parameter on the/oidc/v1/authorizerequest. The server validates that the user may assume the group and bakes the claim into the minted access token, so no header or parameter needs to be attached to subsequent API calls.What changed
Config.AssumeGroupID(group_idin profiles,DATABRICKS_GROUP_IDenv var) so.databrickscfgprofiles can carry an optional group ID.u2m.WithAssumeGroupPersistentAuth option, injectingassume_groupinto the authorize URL for both the standard PKCE flow (appended to the authorization endpoint) and the discovery flow (set on the nested destination_url).Assuming a group is only supported for workspace-level U2M logins. The value is decided at login time; the SDK's runtime databricks-cli token source is unaffected.
How is this tested?
Added appropriate unit tests.
Co-authored-by: Isaac