starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Add OIDC Client Credentials Grant as authenthification method #1524

New issue

Closed

opened 2026-02-28 02:24:10 -05:00 by deekerman · 6 comments

deekerman commented

2026-02-28 02:24:10 -05:00

Owner

Originally created by @ste1nstone on GitHub (Oct 30, 2022).

⚠️ Please verify that this feature request has NOT been suggested before.

I checked and didn't find similar feature request

🏷️ Feature Request Type

Other

🔖 Feature description

At the moment you can use basic auth and ntlm to authenticate against http endpoints.
To monitor the availability of APIs it would be helpful to have the additional alternative with the OIDC Client Credentials Grant

✔️ Solution

request a jwt token and add it as bearer header to oidc protected http endoints

Most of the providers (I checked KeyCloak, AWS Cognito and Azure AD) implement the client credential flow according to the standard https://www.rfc-editor.org/rfc/rfc6749#section-4.4
Auth0 as another big provider adds an additional field to the request with audience

So my suggestion would be that if you select OIDC Client Credentials Grant as auth method in the UI you receive the following input fields
Mandatory:

Token Endpoint
Client Id
Client Secret

Optional:

Scope
Audience

Then before the actual http call is triggered a jwt token is requested and added to the http header.
Because the response of the grant flow should also contains an expire time the token can be cached.

❓ Alternatives

I'm aware that the push monitor would be alternative possibility but would be nice to handle the checks with a build in functionality

📝 Additional Context

I would also be willing to provide a PR for the topic

Originally created by @ste1nstone on GitHub (Oct 30, 2022). ### ⚠️ Please verify that this feature request has NOT been suggested before. - [X] I checked and didn't find similar feature request ### 🏷️ Feature Request Type Other ### 🔖 Feature description At the moment you can use basic auth and ntlm to authenticate against http endpoints. To monitor the availability of APIs it would be helpful to have the additional alternative with the OIDC Client Credentials Grant ### ✔️ Solution request a jwt token and add it as bearer header to oidc protected http endoints Most of the providers (I checked [KeyCloak](https://www.appsdeveloperblog.com/keycloak-client-credentials-grant-example/), [AWS Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/token-endpoint.html) and [Azure AD](https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow)) implement the client credential flow according to the standard https://www.rfc-editor.org/rfc/rfc6749#section-4.4 [Auth0 ](https://auth0.com/docs/get-started/authentication-and-authorization-flow/call-your-api-using-the-client-credentials-flow)as another big provider adds an additional field to the request with audience So my suggestion would be that if you select OIDC Client Credentials Grant as auth method in the UI you receive the following input fields Mandatory: - Token Endpoint - Client Id - Client Secret Optional: - Scope - Audience Then before the actual http call is triggered a jwt token is requested and added to the http header. Because the response of the grant flow should also contains an expire time the token can be cached. ### ❓ Alternatives I'm aware that the push monitor would be alternative possibility but would be nice to handle the checks with a build in functionality ### 📝 Additional Context I would also be willing to provide a PR for the topic

deekerman

2026-02-28 02:24:10 -05:00

closed this issue
added the
feature-request
label

deekerman commented

2026-02-28 02:24:19 -05:00

Author

Owner

@cwchristerw commented on GitHub (Jul 8, 2023):

Related to #21 #553

@cwchristerw commented on GitHub (Jul 8, 2023): Related to #21 #553

deekerman commented

2026-02-28 02:24:19 -05:00

Author

Owner

@hegerdes commented on GitHub (Jul 8, 2023):

I provided a PR which implements this: #3119. Feel free to provide feedback!

@hegerdes commented on GitHub (Jul 8, 2023): I provided a PR which implements this: #3119. Feel free to provide feedback!

deekerman commented

2026-02-28 02:24:19 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jul 8, 2023):

Related to #553

Not related: this issue talks about adding a monitor (see #3119)

@CommanderStorm commented on GitHub (Jul 8, 2023): > Related to #553 Not related: this issue talks about adding a monitor (see #3119)

deekerman commented

2026-02-28 02:24:19 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Aug 24, 2023):

@ste1nstone
https://github.com/louislam/uptime-kuma/pull/3119 was merged, but we accidentally left this issue open.
Could you please close this issue?

PS: @hegerdes The next time please add Fixes #issuenumber as a literal string (github only understand one issue per fixes) as requested in https://github.com/louislam/uptime-kuma/pull/3119#issuecomment-1627476341
The reason is that otherwise resolved issues are not getting closed ^^

@CommanderStorm commented on GitHub (Aug 24, 2023): @ste1nstone https://github.com/louislam/uptime-kuma/pull/3119 was merged, but we accidentally left this issue open. Could you please close this issue? PS: @hegerdes The next time please add `Fixes #issuenumber` as a literal string (github only understand one issue per fixes) as requested in https://github.com/louislam/uptime-kuma/pull/3119#issuecomment-1627476341 The reason is that otherwise resolved issues are not getting closed ^^

deekerman commented

2026-02-28 02:24:19 -05:00

Author

Owner

@goshlanguage commented on GitHub (Jun 24, 2025):

This issue shouldn't be closed, as the PR referenced is only a partial implementation of the client crendentials flow. It's still missing the ability to send the audience parameter, which is required for a certain providers, such as Auth0.

I wouldn't mind digging in and helping with implementation if its welcome

@goshlanguage commented on GitHub (Jun 24, 2025): This issue shouldn't be closed, as the PR referenced is only a partial implementation of the client crendentials flow. It's still missing the ability to send the audience parameter, which is required for a certain providers, such as Auth0. I wouldn't mind digging in and helping with implementation if its welcome

deekerman commented

2026-02-28 02:24:19 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jun 24, 2025):

I'like to not reopen this issue as this issue is about adding oauth. Oauth is added.
Audience field has been marked as not required in the issue.

But if you want to work on this, that is fine and does not require an issue.
Alternatively, I think a different smaller issue is a better call. That way I can mark it as a good first issue without intimidating people with the legacy of this issue

@CommanderStorm commented on GitHub (Jun 24, 2025): I'like to not reopen this issue as this issue is about adding oauth. Oauth is added. Audience field has been marked as not required in the issue. But if you want to work on this, that is fine and does not require an issue. Alternatively, I think a different smaller issue is a better call. That way I can mark it as a good first issue without intimidating people with the legacy of this issue