🚀 Feature: Client Credentials flow support #56

New Issue

OVERLORD · 2025-10-06T23:59:34+03:00

OVERLORD commented

2025-10-06 23:59:34 +03:00

Originally created by @savely-krasovsky on GitHub.

Feature description

Client Credentials flow is a very useful flow for m2m integrations. Since #566 is already merged it would be nice to support getting access token using both methods:

With a pair of client_id and client_secret.
With a federated credential (client_id + client_assertion).

Pitch

Client Credentials flow can be used to programmatically bypass IAPs (Identity-Aware Proxy) such as oauth2-proxy and many others. For example it will allow monitoring products like Uptime Kuma or Gatus to monitor services behind those proxies by providing access token they received from Pocket-ID using client credential flow.

Originally created by @savely-krasovsky on GitHub. ### Feature description [Client Credentials flow](https://datatracker.ietf.org/doc/html/rfc6749#section-4.4) is a very useful flow for m2m integrations. Since #566 is already merged it would be nice to support getting access token using both methods: 1. With a pair of `client_id` and `client_secret`. 2. With a federated credential (`client_id` + `client_assertion`). ### Pitch Client Credentials flow can be used to programmatically bypass IAPs (Identity-Aware Proxy) such as [oauth2-proxy](https://github.com/oauth2-proxy/oauth2-proxy) and many others. For example it will allow monitoring products like Uptime Kuma or Gatus to monitor services behind those proxies by providing access token they received from Pocket-ID using client credential flow.

OVERLORD added the needs more upvotes label 2025-10-06 23:59:34 +03:00

OVERLORD closed this issue

2025-10-06 23:59:35 +03:00

OVERLORD commented

2025-10-06 23:59:38 +03:00

@savely-krasovsky commented on GitHub:

I think @ItalyPaleAle can provide even better examples, as he has more experience with Kubernetes, which can be configured to trust access tokens issued via the client_credentials flow.

@savely-krasovsky commented on GitHub: I think @ItalyPaleAle can provide even better examples, as he has more experience with Kubernetes, which can be configured to trust access tokens issued via the `client_credentials` flow.

OVERLORD commented

2025-10-06 23:59:38 +03:00

@stonith404 commented on GitHub:

Could you clarify the use case a bit more? I'm not really sure if I understand it correctly. From my perspective, it sounds like the idea is that one client can request an access token in order to call another client. For example, client A obtaining an access token from Pocket ID to access client B.

What's the advantage of having this over just a simple API key that is provided by the IAP, that allows client A to bypass authentication of client B?

@stonith404 commented on GitHub: Could you clarify the use case a bit more? I'm not really sure if I understand it correctly. From my perspective, it sounds like the idea is that one client can request an access token in order to call another client. For example, client A obtaining an access token from Pocket ID to access client B. What's the advantage of having this over just a simple API key that is provided by the IAP, that allows client A to bypass authentication of client B?

OVERLORD commented

2025-10-06 23:59:39 +03:00

@savely-krasovsky commented on GitHub:

@stonith404 there are many cases where a service does not provide its own tokens for access, but instead trusts access tokens issued by a trusted IdP (Identity Provider — Pocket-ID in our case). For example, this can be used for service-to-service authentication in a microservice architecture. You create an OIDC client, it contacts the IdP and exchanges the client_id + client_secret (or a client_assertion) for an access_token, and then Service A can call Service B using that token. Service B can easily verify that the token was issued for Service A by the trusted IdP. This removes the need for Service B to implement its own authentication scheme.

In the case of OAuth2 Proxy, it does not have any embedded authentication mechanisms other than OAuth2 JWT access tokens passed as Bearer tokens (see docs: https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview/, --skip-jwt-bearer-tokens flag). Notable projects such as Uptime Kuma and Gatus can use the client_credentials flow to obtain an access token and present it while polling endpoints.

@savely-krasovsky commented on GitHub: @stonith404 there are many cases where a service does not provide its own tokens for access, but instead trusts access tokens issued by a trusted IdP (Identity Provider — Pocket-ID in our case). For example, this can be used for service-to-service authentication in a microservice architecture. You create an OIDC client, it contacts the IdP and exchanges the `client_id` + `client_secret` (or a `client_assertion`) for an `access_token`, and then Service A can call Service B using that token. Service B can easily verify that the token was issued for Service A by the trusted IdP. This removes the need for Service B to implement its own authentication scheme. In the case of OAuth2 Proxy, it does not have any embedded authentication mechanisms other than OAuth2 JWT access tokens passed as Bearer tokens (see docs: https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview/, `--skip-jwt-bearer-tokens` flag). Notable projects such as Uptime Kuma and Gatus can use the client_credentials flow to obtain an access token and present it while polling endpoints.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pocket-id#56