Skip to content

feat(auth): support live Okta OBO token exchange#1681

Draft
afourniernv wants to merge 5 commits into
NVIDIA:mainfrom
afourniernv:feat/okta-obo
Draft

feat(auth): support live Okta OBO token exchange#1681
afourniernv wants to merge 5 commits into
NVIDIA:mainfrom
afourniernv:feat/okta-obo

Conversation

@afourniernv
Copy link
Copy Markdown

Summary

Adds delegated identity via RFC 8693 / Okta OBO token exchange.

Related Issue

N/A

Changes

  • add Okta OBO provider profile
  • support live delegated token exchange from authenticated user context
  • add end-user OBO docs

Testing

  • mise run pre-commit passes
  • Unit tests added/updated
  • E2E tests added/updated (if applicable)

Checklist

  • Follows Conventional Commits
  • Commits are signed off (DCO)

@copy-pr-bot
Copy link
Copy Markdown

copy-pr-bot Bot commented Jun 2, 2026

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@mrunalp
Copy link
Copy Markdown
Collaborator

mrunalp commented Jun 3, 2026

I think Keycloak can also be supported for OBO flow with this work. The flow should be similar, the differences would be around configuration.

Copy link
Copy Markdown

@usize usize left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was really happy to come across this work, as my team over at Red Hat have been exploring the possibility of leveraging sandbox gateways to achieve obo semantics. \o/

let token_url = oauth2_token_url(state)?;
let client_id = required_material(&state.material, "client_id")?;
let client_secret = required_material(&state.material, "client_secret")?;
let subject_token = required_material(&state.material, "subject_token")?;
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Down the line, if we make the subject token a resolvable reference to a SPIFFE SVID, the caller's OIDC bearer, or a gateway-signed assertion this strategy would move further into a general-purpose delegation layer.

We could also support actor tokens and client assertion fields. (fwiw my team has been investigating ways of moving token exchange logic into OpenShell and this would give us what we need).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants