oAuth2 support for HTTP Monitors (Authorization Providers)

[GraemeMitchell84]

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.

[deefdragon]

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?)

[GraemeMitchell84]

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.

[dsimoes]

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.

[deefdragon]

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

[atla]

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?

[ankit-ls]

@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.

[dnltech2020]

is there an update when JWT authentication will be available ?

[dnltech2020]

is there an update when JWT authentication will be available ?

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

[mwllgr]

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

[hegerdes]

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.