Client Credentials Grant #1629

xtremerui · 2020-01-16T19:58:26Z

so client can get access to Dex resources e.g. forwarding auth request and performing token exchange while handling callback from Dex.

karunchennuri · 2020-06-10T15:11:35Z

@xtremerui I've been evaluating Dex as SP front ending Okta IdP. One of the use cases, I was looking at is support for client_credentials grant type. In a way, I want client application to use static client id and secret, configured at the time of Dex connector configuration, to retrieve id_token, refresh_token, access_token, code from Dex.

This PR is going to support that? The connector type 'am exploring is OIDC.

xtremerui · 2020-06-10T15:36:30Z

@karunchennuri yes we have similar use case thus we implemented this in our fork https://github.com/concourse/dex. Not sure how it is gonna be in upstream.

karunchennuri · 2020-06-10T15:40:13Z

Thanks a lot I will use your fork to test today. Just checking it works on oidc connector type right? Also to test this do you have gRPC client application? With Regards Karun Chennuri

…

________________________________ From: Rui Yang <notifications@github.com> Sent: Wednesday, June 10, 2020 8:36:46 AM To: dexidp/dex <dex@noreply.github.com> Cc: Chennuri, Karun <Karun.Chennuri1@T-Mobile.com>; Mention <mention@noreply.github.com> Subject: Re: [dexidp/dex] Client Credentials Grant (#1629) [External] @karunchennuri<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkarunchennuri&data=02%7C01%7CKarun.Chennuri1%40T-Mobile.com%7C6f239a7bc83b41a37a7308d80d54162d%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637274002080775697&sdata=HpT4ik9WkAB8Q6q6OKT0tyZ0Ccuu2i8zRn1sXmhUOfU%3D&reserved=0> yes we have similar use case thus we implemented this in our fork https://github.com/concourse/dex<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fconcourse%2Fdex&data=02%7C01%7CKarun.Chennuri1%40T-Mobile.com%7C6f239a7bc83b41a37a7308d80d54162d%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637274002080785690&sdata=Rus8zrNYFO%2F5IJxTiMvBUvPENA0F671et8RgQldYIOk%3D&reserved=0>. Not sure how it is gonna be in upstream. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdexidp%2Fdex%2Fpull%2F1629%23issuecomment-642089715&data=02%7C01%7CKarun.Chennuri1%40T-Mobile.com%7C6f239a7bc83b41a37a7308d80d54162d%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637274002080785690&sdata=FslR9xe0EKNt6UDEZCZxt47DafA8gSyeseqIE8vYSec%3D&reserved=0>, or unsubscribe<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAEKPQROP4L4KGLBTMRRXKSDRV6SA5ANCNFSM4KHZYJOA&data=02%7C01%7CKarun.Chennuri1%40T-Mobile.com%7C6f239a7bc83b41a37a7308d80d54162d%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637274002080795681&sdata=w2qyKV2xd1aIAUbN744MuVDpCABSsaSAdMqpEsqiJmo%3D&reserved=0>.

karunchennuri · 2020-06-10T22:44:11Z

@xtremerui I tested this PR on the master branch of dex. Worked perfectly fine.
Somehow I had difficulty running local tests on the https://github.com/concourse/dex. That's the reason just cherry picked your PR. Thanks a lot for putting this together, I was reading some older posts on the reluctance to support client_credentials grant type, there must be a reason, I would be interested in knowing more on that from others on this thread.

xtremerui · 2020-06-11T01:01:25Z

@karunchennuri glad it works. The test could be ran using the Makefile

dex/Makefile

Lines 44 to 45 in 2ca992e

    
           test: bin/test/kube-apiserver bin/test/etcd 
        
           	@go test -v ./...

make test

mvdkleijn · 2020-07-30T08:18:04Z

@xtremerui Would you be open to update this PR since it has conflicts?

xtremerui · 2020-07-30T13:47:32Z

@mvdkleijn absolutely. Most of my PRs got conflicts I will update all of them. Thank you!

xtremerui · 2021-11-10T19:46:00Z

@sagikazarmark could I get some feedback on this PR please?

server/handlers.go

RealHarshThakur · 2022-12-15T06:04:08Z

Hey folks, is there anything I can do to help this PR move forward?

cloudmarius · 2023-09-13T15:55:42Z

Hi there, any intention still to merge this feature?

jarrettprosser · 2023-09-13T23:20:52Z

I've tested the fork this change is based on and found that in the case of a public client, Dex will issue client credentials for the public client if I provide the client ID and leave out the secret value (or set it to null). This is an issue for our use; simply knowing the client ID (which is sent in plaintext by the UI when getting a token) is enough to get an access token. Not sure if that has been resolved in this PR though.

We've ended up using the Device Code Flow with a staticClient and staticPassword as an alternative, but having full support for the Client Credentials Grant would be better.

nabokihms · 2024-02-09T08:29:38Z

With the allowedGrants, I think now we can add the support for client credentials grant and make it not enabled by default.

@sagikazarmark what do you think?

smehboub · 2024-06-09T13:31:40Z

Hello,

Thank you very much for your work.
Any news on progress ?

Thanks in advance :-)
Rgs

Signed-off-by: Rui Yang <ruiya@vmware.com>

This fixes two issues in the existing client credentials change: - client_credentials was not listed as a supported grant type - access tokens are not the storage ID Signed-off-by: Michael Kelly <mkelly@arista.com>

Signed-off-by: Rui Yang <ruiya@vmware.com>

cardoe · 2025-09-11T17:31:53Z

@sagikazarmark and @nabokihms wanted to re-raise what you mentioned about including this and leaving it disabled by default. What would you think?

Reason I ask is that I know folks are using this for robot / machine accounts. It might also be acceptable to add the ability to have the hidden connectors that robot / machine accounts utilize without having that prompt users.

testinfected · 2025-12-08T17:08:11Z

@sagikazarmark We have exactly the same issue as @xtremerui and @kellyma2 with Flyte. Flyte deploys in a Kubernetes env and has a concept of a worker which needs to authenticate to the Flyte control plane. We can only setup a single OIDC/OAuth2 server, and we use Dex for it (Okta connector). Flyte uses client credentials grant for the worker.

As per @nabokihms @cardoe suggestions, would it be fine to disable it by default. ~~Also, would need to add verification of the client secret as well. Currently only the ID is checked.~~

Thanks

sagikazarmark · 2025-12-09T15:40:49Z

I'm inclined to accept this given the popular demand.

Unfortunately I have limited time, so if someone could run some tests, it would be immensely helpful.

The code change itself is relatively small, so once we have confirmation it works as expected, we should be able to get this merged relatively quickly.

(I'm constantly flooded by GitHub emails, so keep pinging me if I don't respond. Thanks! 🙏 )

cardoe · 2025-12-09T21:42:11Z

To further this along, I've pulled this PR into build that I made at https://github.com/cardoe/dex/releases/tag/v2.44.90 You can grab the container to test with at ghcr.io/cardoe/dex:v2.44.90 and report back on this PR.

testinfected · 2025-12-09T22:03:41Z

I pulled this PR as well on my side and have tested it against Flyte (our use case). Works without issues. I have reviewed the code which looks alright (although I'm new to the codebase).

My 2 cents
Thanks guys

sagikazarmark

I really hate to be the gatekeeper (especially since @xtremerui has been rebasing this PR for years now), but I had some comments, one of them is potentially a blocker.

sagikazarmark · 2026-01-13T18:02:36Z

server/handlers.go

 	w.Write(claims)
 }

+func (s *Server) handleClientCredentialsGrant(w http.ResponseWriter, r *http.Request, client storage.Client) {


Correct me if I'm wrong, but client credentials grant isn't supposed to work with public clients, is it?

Shouldn't there be some sort of check here?

Technically, withClientFromStorage checks the secret, but public clients have empty secret, so it will always match.

If I'm right, this is a rather serious vulnerability.

@cardoe any chance you could give this a try in your build?

Also, it would probably be a good idea to cover at least the happy path with tests.

sagikazarmark · 2026-01-13T18:04:36Z

server/handlers.go

+
+	claims := storage.Claims{UserID: client.ID}
+
+	accessToken, _, err := s.newAccessToken(r.Context(), client.ID, claims, scopes, nonce, "client")


Is generating an access token always necessary? Shouldn't it be returned based on the requested scopes?

sagikazarmark · 2026-01-13T18:05:36Z

server/handlers.go

+	accessToken, _, err := s.newAccessToken(r.Context(), client.ID, claims, scopes, nonce, "client")
+	if err != nil {
+		s.logger.ErrorContext(r.Context(), "failed to create new access token", "err", err)
+		s.tokenErrHelper(w, errServerError, err.Error(), http.StatusInternalServerError)


We've just merged #4457 removing internal error messages from responses. I think a generic error message should be returned here.

See the linked PR.

sagikazarmark · 2026-01-13T18:05:44Z

server/handlers.go

+
+	idToken, expiry, err := s.newIDToken(r.Context(), client.ID, claims, scopes, nonce, accessToken, "", "client")
+	if err != nil {
+		s.tokenErrHelper(w, errServerError, fmt.Sprintf("failed to create ID token: %v", err), http.StatusInternalServerError)


Same as above.

xtremerui mentioned this pull request Jan 16, 2020

Sync concourse/dex with upstream Dex concourse/concourse#4983

Open

xtremerui requested a review from sagikazarmark January 16, 2020 21:36

xtremerui force-pushed the pr/client-credentials-grant-sync branch 2 times, most recently from d06e60b to 37225ee Compare August 4, 2020 19:13

xtremerui force-pushed the pr/client-credentials-grant-sync branch 3 times, most recently from 579a1de to 133d9b6 Compare September 28, 2020 19:39

xtremerui force-pushed the pr/client-credentials-grant-sync branch 3 times, most recently from 47d4519 to b648030 Compare October 5, 2020 17:39

xtremerui force-pushed the pr/client-credentials-grant-sync branch from b648030 to 00c37b6 Compare October 16, 2020 16:43

xtremerui force-pushed the pr/client-credentials-grant-sync branch 2 times, most recently from 5b265dd to 12421b2 Compare November 5, 2020 04:19

xtremerui force-pushed the pr/client-credentials-grant-sync branch from 12421b2 to 378e4c2 Compare December 15, 2020 15:54

xtremerui force-pushed the pr/client-credentials-grant-sync branch 2 times, most recently from 4530e4b to 1eeff38 Compare March 16, 2021 16:15

xtremerui force-pushed the pr/client-credentials-grant-sync branch from 1eeff38 to 93b8d35 Compare March 20, 2021 20:06

This was referenced Nov 9, 2021

Add support for client credentials grant #2322

Closed

Add support for client_credentials grant type aristanetworks/dex#5

Merged

xtremerui closed this Nov 10, 2021

xtremerui reopened this Nov 10, 2021

xtremerui force-pushed the pr/client-credentials-grant-sync branch from e84cf0e to dbb4f3e Compare November 10, 2021 19:44

github-advanced-security bot found potential problems Aug 2, 2022

View reviewed changes

server/handlers.go Fixed Show fixed Hide fixed

xtremerui force-pushed the pr/client-credentials-grant-sync branch 2 times, most recently from a031678 to 73f1657 Compare September 16, 2022 05:28

xtremerui force-pushed the pr/client-credentials-grant-sync branch 2 times, most recently from 1905f8f to 4e3fe5b Compare October 4, 2022 10:34

xtremerui force-pushed the pr/client-credentials-grant-sync branch from 4e3fe5b to 895f3b2 Compare October 31, 2022 15:02

xtremerui force-pushed the pr/client-credentials-grant-sync branch from 895f3b2 to 7a07880 Compare March 20, 2023 13:31

xtremerui force-pushed the pr/client-credentials-grant-sync branch from 7a07880 to 3f0f531 Compare June 30, 2023 14:13

taylorsilva force-pushed the pr/client-credentials-grant-sync branch from 3f0f531 to f72d7eb Compare January 16, 2025 18:41

xtremerui force-pushed the pr/client-credentials-grant-sync branch from f72d7eb to 08844c6 Compare February 19, 2025 13:20

nabokihms added the release-note/new-feature Release note: Exciting New Features label Feb 25, 2025

xtremerui force-pushed the pr/client-credentials-grant-sync branch from 08844c6 to ce3617b Compare July 22, 2025 17:21

taylorsilva mentioned this pull request Jul 22, 2025

Tracking deltas from upstream dexidp/dex concourse/dex#1

Open

Rui Yang and others added 3 commits September 1, 2025 13:24

add client crendential grant type

c0c53bd

Signed-off-by: Rui Yang <ruiya@vmware.com>

Fix issues in existing client credentials change

24b3df4

This fixes two issues in the existing client credentials change: - client_credentials was not listed as a supported grant type - access tokens are not the storage ID Signed-off-by: Michael Kelly <mkelly@arista.com>

Fix tests in TestServerSupportedGrants for client credentials

3925296

Signed-off-by: Rui Yang <ruiya@vmware.com>

xtremerui force-pushed the pr/client-credentials-grant-sync branch from ce3617b to 3925296 Compare September 1, 2025 13:24

testinfected mentioned this pull request Dec 8, 2025

Allowing client_credential grant type #4429

Closed

2 tasks

cardoe added a commit to cardoe/dex that referenced this pull request Dec 9, 2025

Merge dexidp#1629

f0a8db7

sagikazarmark requested changes Jan 13, 2026

View reviewed changes


		claims := storage.Claims{UserID: client.ID}

		accessToken, _, err := s.newAccessToken(r.Context(), client.ID, claims, scopes, nonce, "client")

Client Credentials Grant #1629

Are you sure you want to change the base?

Client Credentials Grant #1629

Conversation

xtremerui commented Jan 16, 2020

Uh oh!

karunchennuri commented Jun 10, 2020

Uh oh!

xtremerui commented Jun 10, 2020

Uh oh!

karunchennuri commented Jun 10, 2020 via email

Uh oh!

karunchennuri commented Jun 10, 2020

Uh oh!

xtremerui commented Jun 11, 2020

Uh oh!

mvdkleijn commented Jul 30, 2020

Uh oh!

xtremerui commented Jul 30, 2020

Uh oh!

xtremerui commented Nov 10, 2021

Uh oh!

Uh oh!

RealHarshThakur commented Dec 15, 2022

Uh oh!

cloudmarius commented Sep 13, 2023

Uh oh!

jarrettprosser commented Sep 13, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nabokihms commented Feb 9, 2024

Uh oh!

smehboub commented Jun 9, 2024

Uh oh!

cardoe commented Sep 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

testinfected commented Dec 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sagikazarmark commented Dec 9, 2025

Uh oh!

cardoe commented Dec 9, 2025

Uh oh!

testinfected commented Dec 9, 2025

Uh oh!

sagikazarmark left a comment

Choose a reason for hiding this comment

Uh oh!

sagikazarmark Jan 13, 2026

Choose a reason for hiding this comment

Uh oh!

sagikazarmark Jan 13, 2026

Choose a reason for hiding this comment

Uh oh!

sagikazarmark Jan 13, 2026

Choose a reason for hiding this comment

Uh oh!

sagikazarmark Jan 13, 2026

Choose a reason for hiding this comment

Uh oh!

sagikazarmark Jan 13, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

13 participants

jarrettprosser commented Sep 13, 2023 •

edited

Loading

cardoe commented Sep 11, 2025 •

edited

Loading

testinfected commented Dec 8, 2025 •

edited

Loading