starred/uptime-kuma

Fork 0

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

oAuth2 support for HTTP Monitors (Authorization Providers) #384

New issue

Closed

opened 2026-02-28 01:44:46 -05:00 by deekerman · 10 comments

deekerman commented

2026-02-28 01:44:46 -05:00

Owner

Originally created by @GraemeMitchell84 on GitHub (Oct 11, 2021).

Is your feature request related to a problem? Please describe.
We would like to use uptime kuma to monitor a whole bunch of microservices which are secured using oAuth2 / OpenID Connect. This is possible to some extent as we can ping an endpoint on the API and expect a 401 in response back from the API, which would indicate in at least someway that we think the API is probably up. However, I want to also take a step further and determine whether that API is really up-and-running, considering what that API communicates with. We might have a GET /_health endpoint on our apis which makes a basically connectivity test to the backend database (or whatever it connects to) and returns a 200 with some body if successful.

Describe the solution you'd like
I'm specifically looking for support using a client credentials grant type as I think this makes most sense for most people. I'd be looking to have an "Authorization" option in the HTTP monitor configuration which allows you to choose from a list of "Authorization Providers". Authorization providers could be configured on another screen which determines type of provider, a couple of common for HTTP would be basic / oauth2 for example. Maybe there is scope to evolve that for other monitor types in future besides HTTP. The authorization providers themselves may then be shared and re-used across multiple monitors. Most of our microservices will be secured by the same oAuth2 / OpenID Connect provider (IDP), but it would make sense to have multiple instances of an oauth2 provider, rather than one, in the event we're monitoring APIs secured by different IDPs. I may have a client configured in my IDP representing uptime kuma as client credentials grant type and use that client across all Microservice I want to monitor from uptime kuma. I also might use different clients / secrets for different services for better isolation from a security perspective. An access token retrieved for a given authorization provider configuration (IDP + client + secret + scopes, etc) should be re-used across all monitors until it becomes expires. That token would need to be renewed and managed within uptime kuma on detection of a 401 response to trigger a new token request, followed by a retry of the request using the newly stored token without the initial 401 being seen as an outage or "retry" from an uptime Kuma perspective. Different microservices may be secured by different IDPs, which is why multiple oAuth2 providers could be specified with different clients / secrets / scopes, and the appropriate provider for that service may be selected on the monitor itself. Keeping those tokens / credentials secured in the app would be of importance of course.

Describe alternatives you've considered
I've considering monitoring backends (such as databases) independently using a TCP monitor (for example). However, this is not completely reliable as the outage doesn't cascade up to the APIs that use it, which would be down. it also doesn't cover scenarios where some specific issue occurs between API and backend, e.g. coding mistake, password change on service account, network connectivity from API -> DB issue, etc, etc. I've also considered implementing proxies for the health services that bypass the security, but that's not great because it...bypassing the security :)

Additional context
Happy to hear if others would benefit from this. I expect a lot of people to use oAuth2 / OpenID connect given that it's pretty industry standard for securing APIs.

Originally created by @GraemeMitchell84 on GitHub (Oct 11, 2021). **Is your feature request related to a problem? Please describe.** We would like to use uptime kuma to monitor a whole bunch of microservices which are secured using oAuth2 / OpenID Connect. This is possible to some extent as we can ping an endpoint on the API and expect a 401 in response back from the API, which would indicate in at least someway that we think the API is probably up. However, I want to also take a step further and determine whether that API is really up-and-running, considering what that API communicates with. We might have a GET /_health endpoint on our apis which makes a basically connectivity test to the backend database (or whatever it connects to) and returns a 200 with some body if successful. **Describe the solution you'd like** I'm specifically looking for support using a client credentials grant type as I think this makes most sense for most people. I'd be looking to have an "Authorization" option in the HTTP monitor configuration which allows you to choose from a list of "Authorization Providers". Authorization providers could be configured on another screen which determines type of provider, a couple of common for HTTP would be basic / oauth2 for example. Maybe there is scope to evolve that for other monitor types in future besides HTTP. The authorization providers themselves may then be shared and re-used across multiple monitors. Most of our microservices will be secured by the same oAuth2 / OpenID Connect provider (IDP), but it would make sense to have multiple instances of an oauth2 provider, rather than one, in the event we're monitoring APIs secured by different IDPs. I may have a client configured in my IDP representing uptime kuma as client credentials grant type and use that client across all Microservice I want to monitor from uptime kuma. I also might use different clients / secrets for different services for better isolation from a security perspective. An access token retrieved for a given authorization provider configuration (IDP + client + secret + scopes, etc) should be re-used across all monitors until it becomes expires. That token would need to be renewed and managed within uptime kuma on detection of a 401 response to trigger a new token request, followed by a retry of the request using the newly stored token without the initial 401 being seen as an outage or "retry" from an uptime Kuma perspective. Different microservices may be secured by different IDPs, which is why multiple oAuth2 providers could be specified with different clients / secrets / scopes, and the appropriate provider for that service may be selected on the monitor itself. Keeping those tokens / credentials secured in the app would be of importance of course. **Describe alternatives you've considered** I've considering monitoring backends (such as databases) independently using a TCP monitor (for example). However, this is not completely reliable as the outage doesn't cascade up to the APIs that use it, which would be down. it also doesn't cover scenarios where some specific issue occurs between API and backend, e.g. coding mistake, password change on service account, network connectivity from API -> DB issue, etc, etc. I've also considered implementing proxies for the health services that bypass the security, but that's not great because it...bypassing the security :) **Additional context** Happy to hear if others would benefit from this. I expect a lot of people to use oAuth2 / OpenID connect given that it's pretty industry standard for securing APIs.

deekerman

2026-02-28 01:44:46 -05:00

closed this issue
added the
feature-request

A:monitor
labels

deekerman commented

2026-02-28 01:44:51 -05:00

Author

Owner

@deefdragon commented on GitHub (Oct 11, 2021):

#529 is adding support for headers/body, so putting an authorization header into a monitor by hand will soon be possible, but this request sounds like it is asking for automation of the token refresh specifically, not just adding a token? (Along with several long term considerations in dealing with said tokens?)

@deefdragon commented on GitHub (Oct 11, 2021): #529 is adding support for headers/body, so putting an authorization header into a monitor by hand will soon be possible, but this request sounds like it is asking for automation of the token refresh specifically, not just adding a token? (Along with several long term considerations in dealing with said tokens?)

deekerman commented

2026-02-28 01:44:51 -05:00

Author

Owner

@GraemeMitchell84 commented on GitHub (Oct 12, 2021):

Correct. I've seen that issue and whilst it is a useful enhancement (I'd like to see support for HEAD method specifically for example), it does not provide a suitable solution for managing authorization in my opinion, for a few reasons. It would be impractical for oAuth2 where short lived access tokens which might expire within 5 minutes an hour, or even if it stretched out to a few days. Adding authorization provider functionality could solve that, but it might also alleviate security concerns around secret management for somebody needing to add basic auth (or an API key for example), where the contents of "headers" would presumably be stored insecurely and human readable.

I guess postman is a nice example to compare - you can configure headers separately where you could pass choose to pass authorization, but it's actually meant to be managed in a separate authorization tab where you choose your authorization methodology.

@GraemeMitchell84 commented on GitHub (Oct 12, 2021): Correct. I've seen that issue and whilst it is a useful enhancement (I'd like to see support for HEAD method specifically for example), it does not provide a suitable solution for managing authorization in my opinion, for a few reasons. It would be impractical for oAuth2 where short lived access tokens which might expire within 5 minutes an hour, or even if it stretched out to a few days. Adding authorization provider functionality could solve that, but it might also alleviate security concerns around secret management for somebody needing to add basic auth (or an API key for example), where the contents of "headers" would presumably be stored insecurely and human readable. I guess postman is a nice example to compare - you can configure headers separately where you could pass choose to pass authorization, but it's actually meant to be managed in a separate authorization tab where you choose your authorization methodology.

deekerman commented

2026-02-28 01:44:51 -05:00

Author

Owner

@dsimoes commented on GitHub (Nov 16, 2021):

This would be a great feature, since most modern API's rely on bearer tokens.
It would be nice to have an ability to configure a pre-request that would target the authentication endpoint and retrieve the data that could be injected via variables or tokens into the actual monitored http request.

@dsimoes commented on GitHub (Nov 16, 2021): This would be a great feature, since most modern API's rely on bearer tokens. It would be nice to have an ability to configure a pre-request that would target the authentication endpoint and retrieve the data that could be injected via variables or tokens into the actual monitored http request.

deekerman commented

2026-02-28 01:44:51 -05:00

Author

Owner

@deefdragon commented on GitHub (Nov 17, 2021):

Thinking about this, this might be better addressed as an "pre-processor" plugin type. Referencing #117 for consideration.

@deefdragon commented on GitHub (Nov 17, 2021): Thinking about this, this might be better addressed as an "pre-processor" plugin type. Referencing #117 for consideration.

deekerman commented

2026-02-28 01:44:51 -05:00

Author

Owner

@atla commented on GitHub (May 2, 2022):

Hi, any update on this request - did someone manage to find a way to bring in client credential oauth2 auth? Does the pre-processor plugin type help here?

@atla commented on GitHub (May 2, 2022): Hi, any update on this request - did someone manage to find a way to bring in client credential oauth2 auth? Does the pre-processor plugin type help here?

deekerman commented

2026-02-28 01:44:51 -05:00

Author

Owner

@ankit-ls commented on GitHub (Sep 20, 2022):

@deefdragon Bumping this up, as with the increasing security attacks everyday, I feel it becomes a necessary feature to ensure API security.

For your reference: Gatus already supports this, and works seamlessly with OAuth servers.

@ankit-ls commented on GitHub (Sep 20, 2022): @deefdragon Bumping this up, as with the increasing security attacks everyday, I feel it becomes a necessary feature to ensure API security. **For your reference:** [Gatus](https://github.com/TwiN/gatus#client-configuration) already supports this, and works seamlessly with OAuth servers.

deekerman commented

2026-02-28 01:44:51 -05:00

Author

Owner

@dnltech2020 commented on GitHub (Nov 12, 2022):

is there an update when JWT authentication will be available ?

@dnltech2020 commented on GitHub (Nov 12, 2022): is there an update when JWT authentication will be available ?

deekerman commented

2026-02-28 01:44:51 -05:00

Author

Owner

@dnltech2020 commented on GitHub (Dec 23, 2022):

is there an update when JWT authentication will be available ?

Just wondering when this will be added in as a function?

@dnltech2020 commented on GitHub (Dec 23, 2022): > is there an update when JWT authentication will be available ? Just wondering when this will be added in as a function?

deekerman commented

2026-02-28 01:44:51 -05:00

Author

Owner

@mwllgr commented on GitHub (Apr 4, 2023):

+1 for this feature. OIDC support would really be a nice addition to the fantastic existing features.

@mwllgr commented on GitHub (Apr 4, 2023): +1 for this feature. OIDC support would really be a nice addition to the fantastic existing features.

deekerman commented

2026-02-28 01:44:51 -05:00

Author

Owner

@hegerdes commented on GitHub (May 2, 2023):

Since one of my clients also needed this feature I took the opportunity and provided a first implementation example in #3119.

Feel free to test it and share any improvements and thoughts.

@hegerdes commented on GitHub (May 2, 2023): Since one of my clients also needed this feature I took the opportunity and provided a first implementation example in #3119. Feel free to test it and share any improvements and thoughts.