[GH-ISSUE #185] OpenID Connect support

kerem commented

2026-02-25 23:41:17 +03:00

Owner

Originally created by @nogweii on GitHub (Aug 13, 2018).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/185

It would be nice if healthchecks supported OAuth/OpenID Connect or similar for on-premise deployments. That way a user could be redirected to a central IAM platform (AWS's, Active Directory's Federated Services, Keycloak, there a number of similar providers and tools) that they likely are already logged in to.

Originally created by @nogweii on GitHub (Aug 13, 2018). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/185 It would be nice if healthchecks supported OAuth/OpenID Connect or similar for on-premise deployments. That way a user could be redirected to a central IAM platform (AWS's, Active Directory's Federated Services, [Keycloak](https://www.keycloak.org/), there a number of similar providers and tools) that they likely are already logged in to.

kerem

2026-02-25 23:41:17 +03:00

closed this issue
added the
feature
label

kerem commented

2026-02-25 23:41:18 +03:00

Author

Owner

@nogweii commented on GitHub (Nov 15, 2018):

LDAP support (#198) is fairly similar to this request, though this is more about SSO -- redirecting the user to the authentication server rather than requiring them to type their username and password again.

@nogweii commented on GitHub (Nov 15, 2018): LDAP support (#198) is fairly similar to this request, though this is more about SSO -- redirecting the user to the authentication server rather than requiring them to type their username and password again.

kerem commented

2026-02-25 23:41:18 +03:00

Author

Owner

@hongkongkiwi commented on GitHub (Nov 27, 2018):

We would like to do Google Authentication, we already use this for all our other internal tools and it works really well taking the security burden away from us.

Can this be added? I think this would be invaluable for your amazing tool.

@hongkongkiwi commented on GitHub (Nov 27, 2018): We would like to do Google Authentication, we already use this for all our other internal tools and it works really well taking the security burden away from us. Can this be added? I think this would be invaluable for your amazing tool.

kerem commented

2026-02-25 23:41:18 +03:00

Author

Owner

@jameskirsop commented on GitHub (Apr 24, 2019):

Another way of approaching this would be to allow HTTP Headers to authenticate a user - in a similar way to Grafana or Zabbix (among many other tools) do.

Alternatively, I've got django_auth_adfs working quite well. I had to manually edit my superuser account to have my UPN as the username, but after that I'm able to sign in and get redirected to my projects with no issue.

Adding ADFS support was pretty simple (in the same way that adding plain AD support seemed easy in #198). I just needed to make sure that LOGIN_URL was set so it redirected my login requests to ADFS instead of the standard healthchecks.io login page.

@jameskirsop commented on GitHub (Apr 24, 2019): Another way of approaching this would be to allow HTTP Headers to authenticate a user - in a similar way to Grafana or Zabbix (among many other tools) do. Alternatively, I've got `django_auth_adfs` working quite well. I had to manually edit my superuser account to have my UPN as the username, but after that I'm able to sign in and get redirected to my projects with no issue. Adding ADFS support was pretty simple (in the same way that adding plain AD support seemed easy in #198). I just needed to make sure that `LOGIN_URL` was set so it redirected my login requests to ADFS instead of the standard `healthchecks.io` login page.

kerem commented

2026-02-25 23:41:18 +03:00

Author

Owner

@nogweii commented on GitHub (Apr 25, 2019):

@jameskirsop I would love to see any changes you've made to make ADFS work. Could you share those here, or perhaps as a gist?

@nogweii commented on GitHub (Apr 25, 2019): @jameskirsop I would love to see any changes you've made to make ADFS work. Could you share those here, or perhaps as a gist?

kerem commented

2026-02-25 23:41:18 +03:00

Author

Owner

@jameskirsop commented on GitHub (Apr 30, 2019):

@evaryont, installed django_auth_adfs via pip and then used the following.

Added the appropriate config to INSTALLED_APPS, MIDDLEWARE and AUTHENTICATION_BACKENDS.

And used this:

    "SERVER": "adfs.mycompany.com.au",
    "CLIENT_ID": "microsoft:identityserver:companyname-healthio",
    "RESOURCE": "companyname-healthio",
    "AUDIENCE": "microsoft:identityserver:companyname-healthio",
    "CLAIM_MAPPING": {"first_name": "given_name",
                      "last_name": "family_name",
                      "email": "email",
                      },
    "USERNAME_CLAIM": 'upn',
}

LOGIN_URL = "django_auth_adfs:login"

A couple of caveats I've found:

When inviting a user via email address the address is translated to lowercase. For users with capitals in their UPN, and then (in some cases) also in the email address handed back in claims, they're logged in with a new account instead because the two don't match. Eg. JBlogs@domain.com is stored as jblogs@domain.com and ADFS can't find a match, it seems.
If a new user logs in without having an account, the 'username' field is populated with their UPN. While this is expected behaviour with django_auth_adfs, it breaks functionality with Healthchecks - particularly when you try and invite an existing ADFS-created user to a project/team - and results in a 500 error - I'm expecting because of the first caveat:

django.urls.exceptions.NoReverseMatch: Reverse for 'hc-check-token' with arguments '('lowercaseaddress@lowercase.com', 'LLFZNDr4u9iGDFlOcb-TVHgIHj5GK2ZU')' not found. 1 pattern(s) tried: ['accounts\\\\/check_token\\\\/(?P<username>[-a-zA-Z0-9_]+)\\\\/(?P<token>[-a-zA-Z0-9_]+)\\\\/$']

The way I get around both of these, currently, is manually copying the token created by Healthcheck, deleting the 'invited' account created by Healthcheck (via ./manage.py shell) and pasting the token into the username field in the database. It's a hacky way of doing it, but it seems to work.

Not using LowercaseEmailField for user accounts would be a step towards allowing better ADFS support in my opinion, but I do understand why it's a useful way of storing emails on public services. Alternatively, manually changing the way django_auth_adfs middleware handles this could be an appropriate option - to have it always translate email address claims to lowercase.

@jameskirsop commented on GitHub (Apr 30, 2019): @evaryont, installed `django_auth_adfs` via pip and then used the following. Added the appropriate config to `INSTALLED_APPS`, `MIDDLEWARE` and `AUTHENTICATION_BACKENDS`. And used this: ```AUTH_ADFS = { "SERVER": "adfs.mycompany.com.au", "CLIENT_ID": "microsoft:identityserver:companyname-healthio", "RESOURCE": "companyname-healthio", "AUDIENCE": "microsoft:identityserver:companyname-healthio", "CLAIM_MAPPING": {"first_name": "given_name", "last_name": "family_name", "email": "email", }, "USERNAME_CLAIM": 'upn', } LOGIN_URL = "django_auth_adfs:login" ``` A couple of caveats I've found: 1. When inviting a user via email address the address is translated to lowercase. For users with capitals in their UPN, and then (in some cases) also in the email address handed back in claims, they're logged in with a new account instead because the two don't match. Eg. JBlogs@domain.com is stored as jblogs@domain.com and ADFS can't find a match, it seems. 2. If a new user logs in without having an account, the 'username' field is populated with their UPN. While this is expected behaviour with `django_auth_adfs`, it breaks functionality with Healthchecks - particularly when you try and invite an existing ADFS-created user to a project/team - and results in a 500 error - I'm expecting because of the first caveat: ``` django.urls.exceptions.NoReverseMatch: Reverse for 'hc-check-token' with arguments '('lowercaseaddress@lowercase.com', 'LLFZNDr4u9iGDFlOcb-TVHgIHj5GK2ZU')' not found. 1 pattern(s) tried: ['accounts\\\\/check_token\\\\/(?P<username>[-a-zA-Z0-9_]+)\\\\/(?P<token>[-a-zA-Z0-9_]+)\\\\/$'] ``` The way I get around both of these, currently, is manually copying the token created by Healthcheck, deleting the 'invited' account created by Healthcheck (via `./manage.py shell`) and pasting the token into the username field in the database. It's a hacky way of doing it, but it seems to work. Not using `LowercaseEmailField` for user accounts would be a step towards allowing better ADFS support in my opinion, but I do understand why it's a useful way of storing emails on public services. Alternatively, manually changing the way `django_auth_adfs` middleware handles this could be an appropriate option - to have it always translate email address claims to lowercase.

kerem commented

2026-02-25 23:41:18 +03:00

Author

Owner

@jameskirsop commented on GitHub (May 1, 2019):

A few hours later and I've made some significant progress with working around the above.

I've subclassed the AdfsBaseBackend and AdfsAuthCodeBackend classes from django_auth_adfs and made a minor tweak so that it handles getting the appropriate claim back and then translates it to work correctly within the existing HealthChecks framework.

I'm going to do some more testing and then put together a PR for a secondary backend that can optionally be used to bridge the divide between HealthCheck and ADFS.

@jameskirsop commented on GitHub (May 1, 2019): A few hours later and I've made some significant progress with working around the above. I've subclassed the `AdfsBaseBackend` and `AdfsAuthCodeBackend` classes from [django_auth_adfs](http://github.com/jobec/django-auth-adfs) and made a minor tweak so that it handles getting the appropriate claim back and then translates it to work correctly within the existing HealthChecks framework. I'm going to do some more testing and then put together a PR for a secondary backend that can optionally be used to bridge the divide between HealthCheck and ADFS.

kerem commented

2026-02-25 23:41:18 +03:00

Author

Owner

@lukasmrtvy commented on GitHub (Oct 25, 2019):

References:
OIDC: https://django-oauth-toolkit.readthedocs.io/
LDAP: https://django-auth-ldap.readthedocs.io/en/latest/
ADFS: https://django-auth-adfs.readthedocs.io/en/latest/

@lukasmrtvy commented on GitHub (Oct 25, 2019): References: OIDC: https://django-oauth-toolkit.readthedocs.io/ LDAP: https://django-auth-ldap.readthedocs.io/en/latest/ ADFS: https://django-auth-adfs.readthedocs.io/en/latest/

kerem commented

2026-02-25 23:41:18 +03:00

Author

Owner

@nogweii commented on GitHub (Dec 24, 2019):

I have the ultimate hack, adding OpenID Connect support to Healthchecks without modifying any code:

from .settings import INSTALLED_APPS as settings_ia
from .settings import AUTHENTICATION_BACKENDS as settings_ab
from .settings import ROOT_URLCONF as settings_ru

INSTALLED_APPS = list(settings_ia)
INSTALLED_APPS.insert(INSTALLED_APPS.index("django.contrib.auth")+1, "mozilla_django_oidc")
INSTALLED_APPS = tuple(INSTALLED_APPS)

AUTHENTICATION_BACKENDS = settings_ab + ("mozilla_django_oidc.auth.OIDCAuthenticationBackend",)

OIDC_RP_CLIENT_ID = "client-789"
OIDC_RP_CLIENT_SECRET = "secret-123"
OIDC_OP_AUTHORIZATION_ENDPOINT = "https://example.com/openid-connect/auth"
OIDC_OP_TOKEN_ENDPOINT = "https://example.com/openid-connect/token"
OIDC_OP_USER_ENDPOINT = "https://example.com/openid-connect/userinfo"
OIDC_OP_JWKS_ENDPOINT = "https://example.com/openid-connect/certs"
OIDC_RP_SIGN_ALGO = "RS256"

LOGIN_REDIRECT_URL = '/'

from django.urls import path, include
from django.views.generic.base import RedirectView
from types import ModuleType

# Create a dynamic module that injects some additional routes before HC's
sys.modules['sneaky_url'] = ModuleType('sneaky_url')
class _Sneaky(ModuleType):
  @property
  def urlpatterns(self):
    return [
      path('oidc/', include('mozilla_django_oidc.urls')),
      path('accounts/login/', RedirectView.as_view(url='/oidc/authenticate', permanent=True)),
      path('', include(settings_ru))
    ]
sys.modules['sneaky_url'].__class__ = _Sneaky
ROOT_URLCONF = 'sneaky_url'

Copy & paste this into local_settings.py and it should, roughly, Just Work. Oh, and make sure you run pip install mozilla-django-oidc.

@cuu508 I'm sorry for this horrible python but it's pretty clever, eh?

@nogweii commented on GitHub (Dec 24, 2019): I have the ultimate hack, adding OpenID Connect support to Healthchecks without modifying any code: ```python from .settings import INSTALLED_APPS as settings_ia from .settings import AUTHENTICATION_BACKENDS as settings_ab from .settings import ROOT_URLCONF as settings_ru INSTALLED_APPS = list(settings_ia) INSTALLED_APPS.insert(INSTALLED_APPS.index("django.contrib.auth")+1, "mozilla_django_oidc") INSTALLED_APPS = tuple(INSTALLED_APPS) AUTHENTICATION_BACKENDS = settings_ab + ("mozilla_django_oidc.auth.OIDCAuthenticationBackend",) OIDC_RP_CLIENT_ID = "client-789" OIDC_RP_CLIENT_SECRET = "secret-123" OIDC_OP_AUTHORIZATION_ENDPOINT = "https://example.com/openid-connect/auth" OIDC_OP_TOKEN_ENDPOINT = "https://example.com/openid-connect/token" OIDC_OP_USER_ENDPOINT = "https://example.com/openid-connect/userinfo" OIDC_OP_JWKS_ENDPOINT = "https://example.com/openid-connect/certs" OIDC_RP_SIGN_ALGO = "RS256" LOGIN_REDIRECT_URL = '/' from django.urls import path, include from django.views.generic.base import RedirectView from types import ModuleType # Create a dynamic module that injects some additional routes before HC's sys.modules['sneaky_url'] = ModuleType('sneaky_url') class _Sneaky(ModuleType): @property def urlpatterns(self): return [ path('oidc/', include('mozilla_django_oidc.urls')), path('accounts/login/', RedirectView.as_view(url='/oidc/authenticate', permanent=True)), path('', include(settings_ru)) ] sys.modules['sneaky_url'].__class__ = _Sneaky ROOT_URLCONF = 'sneaky_url' ``` Copy & paste this into `local_settings.py` and it should, roughly, Just Work. Oh, and make sure you run [`pip install mozilla-django-oidc`](https://github.com/mozilla/mozilla-django-oidc). @cuu508 I'm sorry for this horrible python but it's pretty clever, eh?

kerem commented

2026-02-25 23:41:18 +03:00

Author

Owner

@cuu508 commented on GitHub (Dec 26, 2019):

@evaryont that's quite a hack indeed! 👍

I'm interested in adding "official" OpenID Connect support into the project and the hosted site as well. Picking the default identity providers will be tricky, but starting with Github and Google seems reasonable.

Checking out mozilla-django-oidc library now – looks like it's designed to support a single, preconfigured identity provider, right?

@cuu508 commented on GitHub (Dec 26, 2019): @evaryont that's quite a hack indeed! :+1: I'm interested in adding "official" OpenID Connect support into the project and the hosted site as well. Picking the default identity providers will be tricky, but starting with Github and Google seems reasonable. Checking out mozilla-django-oidc library now – looks like it's designed to support a single, preconfigured identity provider, right?

kerem commented

2026-02-25 23:41:18 +03:00

Author

Owner

@nogweii commented on GitHub (Jan 2, 2020):

Indeed, looking around there isn't a way to configure it to support multiple providers simultaneously. You might be able to get it working by creating multiple applications, one for each provider, but boy that does sound hacky.

@nogweii commented on GitHub (Jan 2, 2020): Indeed, looking around there isn't a way to configure it to support multiple providers simultaneously. You might be able to get it working by creating multiple applications, one for each provider, but boy that does sound hacky.

kerem commented

2026-02-25 23:41:18 +03:00

Author

Owner

@decentral1se commented on GitHub (Apr 10, 2020):

Is anyone working on this? I'd be most interested in Keycloak integration and I see that there is https://django-keycloak.readthedocs.io/en/latest/. Is anyone against me taking a stab at integrating this just for Keycloak?

@decentral1se commented on GitHub (Apr 10, 2020): Is anyone working on this? I'd be most interested in Keycloak integration and I see that there is https://django-keycloak.readthedocs.io/en/latest/. Is anyone against me taking a stab at integrating this just for Keycloak?

kerem commented

2026-02-25 23:41:18 +03:00

Author

Owner

@cuu508 commented on GitHub (Apr 14, 2020):

Hi @decentral1se – here's a quick summary of my plans and the current situation.

I've looked at adding OIDC auth option. I haven't started any development on it. When looking at this, and making a survey of what other similar services support, it seemed Google and Github would be good candidates for initial identity providers to support.
I haven't looked at how OIDC auth would integrate the existing authentication – what new database fields, forms, email messages etc. would be needed. Some nontrivial work and design decisions here.
I've also considered adding SAML support. No customer has explicitly asked for it, and there might be ways to support it indirectly via, say, Auth0. So I don't have near-term plans to work on it.

I'm not familiar with Keycloak (or, to be completely honest, with the other mentioned technologies), would Keycloak work as another OIDC identity provider? If that's the case, we should plan for supporting other OIDC providers in future too.

@cuu508 commented on GitHub (Apr 14, 2020): Hi @decentral1se – here's a quick summary of my plans and the current situation. * I've looked at adding OIDC auth option. I haven't started any development on it. When looking at this, and making a survey of what other similar services support, it seemed Google and Github would be good candidates for initial identity providers to support. * I haven't looked at how OIDC auth would integrate the existing authentication – what new database fields, forms, email messages etc. would be needed. Some nontrivial work and design decisions here. * I've also considered adding SAML support. No customer has explicitly asked for it, and there might be ways to support it indirectly via, say, Auth0. So I don't have near-term plans to work on it. I'm not familiar with Keycloak (or, to be completely honest, with the other mentioned technologies), would Keycloak work as another OIDC identity provider? If that's the case, we should plan for supporting other OIDC providers in future too.

kerem commented

2026-02-25 23:41:18 +03:00

Author

Owner

@lukasmrtvy commented on GitHub (Apr 14, 2020):

Keycloak, https://github.com/dexidp/dex or generic oidc provider connector is always good start, because these will allow to You "federate" from other upstream oidc providers.

@lukasmrtvy commented on GitHub (Apr 14, 2020): Keycloak, https://github.com/dexidp/dex or generic oidc provider connector is always good start, because these will allow to You "federate" from other upstream oidc providers.

kerem commented

2026-02-25 23:41:18 +03:00

Author

Owner

@lukasmrtvy commented on GitHub (Jul 14, 2020):

@cuu508 is there any progress ?

@lukasmrtvy commented on GitHub (Jul 14, 2020): @cuu508 is there any progress ?

kerem commented

2026-02-25 23:41:18 +03:00

Author

Owner

@cuu508 commented on GitHub (Jul 14, 2020):

@lukasmrtvy from my side, unfortunately no.

@cuu508 commented on GitHub (Jul 14, 2020): @lukasmrtvy from my side, unfortunately no.

kerem commented

2026-02-25 23:41:18 +03:00

Author

Owner

@jameskirsop commented on GitHub (Jul 15, 2020):

Here's a blob of the subclasses I wrote for django_auth_adfs integration with Healthchecks. I've been using this in production for about 12 months now with no issue back against initially ADFS, and now AzureAD.

I don't know, @cuu508, if you'd like to have this in the project to allow for some support of third party logins for those who are hosting themselves?? It might be a little niche, but it would solve the problem for a number of people who've posted on this issue.

I'm happy to create a PR for this after writing up some documentation, if you'd like to have it included.

@jameskirsop commented on GitHub (Jul 15, 2020): [Here's a blob of the subclasses](https://github.com/jameskirsop/healthchecks/blob/adfs_integration/hc/accounts/backends_adfs.py) I wrote for `django_auth_adfs` integration with Healthchecks. I've been using this in production for about 12 months now with no issue back against initially ADFS, and now AzureAD. I don't know, @cuu508, if you'd like to have this in the project to allow for _some_ support of third party logins for those who are hosting themselves?? It might be a little niche, but it would solve the problem for a number of people who've posted on this issue. I'm happy to create a PR for this after writing up some documentation, if you'd like to have it included.

kerem commented

2026-02-25 23:41:18 +03:00

Author

Owner

@peppelinux commented on GitHub (Jul 17, 2020):

I used djangosaml2 for doing SAML2 authentication, an example in my fork here, see saml2_sp and requirements:
https://github.com/UniversitaDellaCalabria/healthchecks

@peppelinux commented on GitHub (Jul 17, 2020): I used djangosaml2 for doing SAML2 authentication, an example in my fork here, see saml2_sp and requirements: https://github.com/UniversitaDellaCalabria/healthchecks

kerem commented

2026-02-25 23:41:18 +03:00

Author

Owner

@Akruidenberg commented on GitHub (Jan 3, 2022):

+1 for this feature!

@Akruidenberg commented on GitHub (Jan 3, 2022): +1 for this feature!

kerem commented

2026-02-25 23:41:18 +03:00

Author

Owner

@peppelinux commented on GitHub (Jan 3, 2022):

I'd suggest also SATOSA as IAM Proxy

See
https://github.com/italia/Satosa-Saml2Spid

@peppelinux commented on GitHub (Jan 3, 2022): I'd suggest also SATOSA as IAM Proxy See https://github.com/italia/Satosa-Saml2Spid

kerem commented

2026-02-25 23:41:18 +03:00

Author

Owner

@nogweii commented on GitHub (Jan 11, 2022):

With the HTTP header auth merged in, I think the only thing that remains would be an example configuration of something like the following stack:

nginx/apache/traefik/caddy listening for incoming requests on 80 & 443
oauth2-proxy or vouch-proxy intercepting some portion of the requests (for example, we don't want to require an OIDC session to send a ping)
Everything else being reverse proxied to django & Healthchecks itself.

Documenting that and referring people to it should hopefully provide the foundation for plugging in whatever authentication proxies people would like.

@cuu508 the only I'd like to ask of you is do you have a list of routes that should be excluded from from authentication? I could make some guesses, but it would be nice to be more confident about the choices.

@nogweii commented on GitHub (Jan 11, 2022): With the HTTP header auth merged in, I think the only thing that remains would be an example configuration of something like the following stack: * nginx/apache/traefik/caddy listening for incoming requests on 80 & 443 * [oauth2-proxy](https://oauth2-proxy.github.io/oauth2-proxy/) or [vouch-proxy](https://github.com/vouch/vouch-proxy) intercepting some portion of the requests (for example, we don't want to require an OIDC session to send a ping) * Everything else being reverse proxied to django & Healthchecks itself. Documenting that and referring people to it should hopefully provide the foundation for plugging in whatever authentication proxies people would like. @cuu508 the only I'd like to ask of you is do you have a list of routes that should be excluded from from authentication? I could make some guesses, but it would be nice to be more confident about the choices.

kerem commented

2026-02-25 23:41:18 +03:00

Author

Owner

@cuu508 commented on GitHub (Jan 13, 2022):

Hi @nogweii, here'sthe list of routes that I think would make sense to be excluded from authentication:

urlpattern	view	view name
`/`	hc.front.views.index	hc-index
`/accounts/unsubscribe_reports/<str:signed_username>/`	hc.accounts.views.unsubscribe_reports	hc-unsubscribe-reports
`/api/v1/badges/`	hc.api.views.badges
`/api/v1/channels/`	hc.api.views.channels
`/api/v1/checks/`	hc.api.views.checks
`/api/v1/checks/<sha1:unique_key>`	hc.api.views.get_check_by_unique_key
`/api/v1/checks/<sha1:unique_key>/flips/`	hc.api.views.flips_by_unique_key
`/api/v1/checks/<uuid:code>`	hc.api.views.single	hc-api-single
`/api/v1/checks/<uuid:code>/flips/`	hc.api.views.flips_by_uuid	hc-api-flips
`/api/v1/checks/<uuid:code>/pause`	hc.api.views.pause	hc-api-pause
`/api/v1/checks/<uuid:code>/pings/`	hc.api.views.pings	hc-api-pings
`/api/v1/metrics/`	hc.api.views.metrics
`/api/v1/notifications/<uuid:code>/status`	hc.api.views.notification_status	hc-api-notification-status
`/api/v1/status/`	hc.api.views.status
`/badge/<slug:badge_key>/<slug:signature>.<slug:fmt>`	hc.api.views.badge	hc-badge-all
`/badge/<slug:badge_key>/<slug:signature>/<quoted:tag>.<slug:fmt>`	hc.api.views.badge	hc-badge
`/checks/cron_preview/`	hc.front.views.cron_preview
`/docs/`	hc.front.views.serve_doc	hc-docs
`/docs/<slug:doc>/`	hc.front.views.serve_doc	hc-serve-doc
`/docs/cron/`	hc.front.views.docs_cron	hc-docs-cron
`/integrations/<uuid:code>/unsub/<str:signed_token>/`	hc.front.views.unsubscribe_email	hc-unsubscribe-alerts
`/integrations/<uuid:code>/verify/<slug:token>/`	hc.front.views.verify_email	hc-verify-email
`/integrations/add_pushover/`	hc.front.views.pushover_help	hc-pushover-help
`/integrations/add_slack/`	hc.front.views.slack_help	hc-slack-help
`/integrations/pagerduty/`	hc.front.views.pd_help	hc-pagerduty-help
`/integrations/telegram/`	hc.front.views.telegram_help	hc-telegram-help
`/integrations/telegram/bot/`	hc.front.views.telegram_bot	hc-telegram-webhook
`/ping/<slug:ping_key>/<slug:slug>`	hc.api.views.ping_by_slug
`/ping/<slug:ping_key>/<slug:slug>/<int:exitstatus>`	hc.api.views.ping_by_slug
`/ping/<slug:ping_key>/<slug:slug>/fail`	hc.api.views.ping_by_slug
`/ping/<slug:ping_key>/<slug:slug>/start`	hc.api.views.ping_by_slug
`/ping/<uuid:code>`	hc.api.views.ping
`/ping/<uuid:code>/`	hc.api.views.ping
`/ping/<uuid:code>/<int:exitstatus>`	hc.api.views.ping
`/ping/<uuid:code>/fail`	hc.api.views.ping
`/ping/<uuid:code>/start`	hc.api.views.ping
`/projects/<uuid:code>/checks/metrics/<slug:key>`	hc.front.views.metrics
`/projects/<uuid:code>/metrics/<slug:key>`	hc.front.views.metrics	hc-metrics
`/tv/`	hc.front.views.dashboard	hc-dashboard

kerem commented

2026-02-25 23:41:18 +03:00

Author

Owner

@axelcypher commented on GitHub (Mar 25, 2022):

With the HTTP header auth merged in, I think the only thing that remains would be an example configuration of something like the following stack:

nginx/apache/traefik/caddy listening for incoming requests on 80 & 443

oauth2-proxy or vouch-proxy intercepting some portion of the requests (for example, we don't want to require an OIDC session to send a ping)

Everything else being reverse proxied to django & Healthchecks itself.

Documenting that and referring people to it should hopefully provide the foundation for plugging in whatever authentication proxies people would like.

@cuu508 the only I'd like to ask of you is do you have a list of routes that should be excluded from from authentication? I could make some guesses, but it would be nice to be more confident about the choices.

Soooo... did anyone managed to get it to work? Right now i'm trying to authenticate via Authentik with Traefik, but i can't get it to work...

@axelcypher commented on GitHub (Mar 25, 2022): > With the HTTP header auth merged in, I think the only thing that remains would be an example configuration of something like the following stack: > > * nginx/apache/traefik/caddy listening for incoming requests on 80 & 443 > * [oauth2-proxy](https://oauth2-proxy.github.io/oauth2-proxy/) or [vouch-proxy](https://github.com/vouch/vouch-proxy) intercepting some portion of the requests (for example, we don't want to require an OIDC session to send a ping) > * Everything else being reverse proxied to django & Healthchecks itself. > > Documenting that and referring people to it should hopefully provide the foundation for plugging in whatever authentication proxies people would like. > > @cuu508 the only I'd like to ask of you is do you have a list of routes that should be excluded from from authentication? I could make some guesses, but it would be nice to be more confident about the choices. Soooo... did anyone managed to get it to work? Right now i'm trying to authenticate via Authentik with Traefik, but i can't get it to work...

kerem commented

2026-02-25 23:41:18 +03:00

Author

Owner

@cuu508 commented on GitHub (Dec 16, 2022):

I currently have no plans to add OIDC authentication options. I want to preserve the discussion in the comments, so I'm converting this issue to a discussion rather than closing it.

@cuu508 commented on GitHub (Dec 16, 2022): I currently have no plans to add OIDC authentication options. I want to preserve the discussion in the comments, so I'm converting this issue to a discussion rather than closing it.

Rows
Columns

[GH-ISSUE #185] OpenID Connect support #130