RFC 8693 OAuth 2.0 Token Exchange

[seankhliao]

Overview

Implement RFC 8693 which specifies exchanging third party tokens for native ones.

What this PR does / why we need it

There are times when we wish to grant machines access to a protected endpoint without using long-lived, static API keys or user/password combinations.
Many modern execution environments can expose short-lived OIDC tokens for the duration of the execution, examples include:

• GCP Service Identity
• AWS Execution Role
• Github Actions OIDC
• CircleCI OIDC
• Kubernetes Service Accounts

As these are machine users, handling a redirect is not very feasible.
In these cases, clients will have independently authenticated to the upstream IDP (sometimes implicitly by virtue of the IDP integrating with the execution environment) and obtained an ID token.
This PR allows using this prior authentication to be used in obtaining a dex issued token for use with downstream clients.

As a concrete example:
We're running ArgoCD with dex as the identity provider, connected to Okta for humans.
We want to access the ArgoCD API from our CI environments without keeping around a static key which may be compromised.

Related issues:

• Token exchange for external tokens #1484
• Question: non-web based clients? #1668
• Get OIDC token issued by Dex using a token issued by one of the connectors. #2657

Special notes for your reviewer

The RFC:

• Isn't very clear on what are the accepted subject/requested token types. I'm assuming it's ID tokens for subject, and ID/Access for requested.
• actor_token and actor_token_type are "MUST ... if the actor token is present, also perform the appropriate validation procedures for its indicated token type", but it's unclear what to authenticate them in this context (an existing user?)
• specifies an optional resource field which I don't see any use for
• specifies an audience field which I'm using for connector ID, based on how GCP Workload Identity Pools use them

It was also unclear if the correct arguments are passed to newIDToken / newAccessToken

Does this PR introduce a user-facing change?

oidc connections now support the grant type "urn:ietf:params:oauth:grant-type:token-exchange"

[seankhliao]

I think this is good enough for a first round of reviews.
Not quite sure about what to do with the CodeQL failures on logging user input

[baz-bakerhughes]

Truly would like this merged into main so dex can be our complete Authentication proxy solution.

[sagikazarmark]

I can't promise it's gonna happen before KubeCon, but we will get to this.

[gnunn1]

Just as a data point if it helps, I tested this PR with the Openshift connector after adding a very hacky implementation of the TokenIdentity method to the connector and it worked fine.

[blairdrummond]

Are there any docs/examples of this flow for Github Actions kicking around? I would be very interested in trying it out, even off of a branch build

[nabokihms]

@seankhliao, sorry for the long delay. I have no excuses (besides KubeCon 😄 ). The code looks good to me.
I want to test the feature manually and give my green light after that.

BTW could you please rebase the PR to resolve conflicts?

[seankhliao]

@nabokihms rebased, no need for excuses :)

@blairdrummond https://github.com/seankhliao/testrepo0191
dex config is in config.yaml
curl commands in the workflow
run: https://github.com/seankhliao/testrepo0191/actions/runs/4940627858/jobs/8832465909

[blairdrummond]

@aidansteele, just incase you're interested, I recently read aws-iam-oidc-idps-need-more-controls, and it seems like this might help resolve the things you have implemented via jwtex. I think the only thing missing is nested json claim mapping which is still a TODO.

[gnunn1]

I have the OpenShift connector updated to implement token exchange for this PR, should I wait for this to be merged before submitting a PR since it depends on this PR?

[nabokihms]

@gnunn1 yes, for now it is better to hold your PR util we merge the current one.

[dhasmac-bh]

Is there any info on how we can test with oidc type connector like auth0. I want to test if the access token through client-credentials grant be exchanged for DEX approved token through token-exchange.

[dhasmac-bh]

Is there any info on how we can test with oidc type connector like auth0. I want to test if the access token through client-credentials grant be exchanged for DEX approved token through token-exchange.

It worked.

[baz-bakerhughes]

OK. We have been running this build with this PR for about 3 weeks in our test environment. I am curious if there is any concern that this will be rejected. If it eventually would be accepted, we can promote the version with the PR and then swap once its in. But if there is a concern that having dexidp support this functionality (even if it was re coded in a different way) but there is a philosophical reason against this that would change our plans. Any thoughts?

[baz-bakerhughes]

@nabokihms Is there any assistance needed to get this merged into main. We have been using the branch build in our environment for a while now and tested all the functional options on tokens we are using. That is @dhasmac-bh has and it all works great.

• auth code flow
• token exchange

[nabokihms]

@baz-bakerhughes, for now, no assistance is needed. DEP was accepted, so it is only a matter of testing. Because of the PTO season, we a throttling with this PR a bit, but no worries. We will merge it eventually.

[seankhliao]

I've reworked the TokenIdentiy part a bit so it should properly work with both id and access tokens.
I think getUserInfo should work now, except I don't have a real backend to test against, the providers I'm using don't support that endpoint at all

[nabokihms]

@seankhliao I tested a dex - dex communication (configuring the second dex instance as an oidc provider for the first) 😄.

[seankhliao]

Ok, I think dex - dex works too with my updated code

[nabokihms]

@seankhliao awesome! Thank you for your work. It was a long journey!

P.S. It would be awesome if you could add a doc about the Token Exchange feature to the Dex documentation.

[sagikazarmark]

Thank you @seankhliao for making this happen!

[seankhliao]

I've created dexidp/website#140 for website documentation
and #3027 for adding grantTypes to the config example (linked from the website).

[dhasmac-bh]

Thanks for the merge, any ETA when this will be available as a release. I can update my helm chart accordingly.

[nabokihms]

There is no release date for the upcoming releases, but it will probably be August something.

[sl1pm4t]

Thanks for this feature, we are using it already to enable ArgoCD to authenticate with managed clusters across multiple clouds.
To facilitate this, and in case it's helpful for anyone else, I wrote this Kubernetes Credential helper that exchanges a Kubernetes Service Account token with one signed by Dex:
https://github.com/sl1pm4t/tokenxchange

[nabokihms]

@sl1pm4t great, thank you for sharing 🙌