[GH-ISSUE #1085] [Feature]: Add option to disable SSL verification for OIDC #774

Closed
opened 2026-05-06 12:32:49 +02:00 by BreizhHardware · 5 comments

Originally created by @mrtncode on GitHub (Apr 22, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1085

Originally assigned to: @netscout2001 on GitHub.

Problem or Use Case

My Authentik instance is running behind a selfsigned ssl certificate. The auth fails because bambuddy cant fetch the OIDC config from Authentik.

Proposed Solution

It would be great if we add an toggle in the oidc settings to disable SSL verification

Alternatives Considered

No response

Feature Category

Other

Priority

Critical for my use case

Mockups or Examples

No response

Contribution

  • I would be willing to help implement this feature

Checklist

  • I have searched existing issues to ensure this feature hasn't already been requested
Originally created by @mrtncode on GitHub (Apr 22, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/1085 Originally assigned to: @netscout2001 on GitHub. ### Problem or Use Case My Authentik instance is running behind a selfsigned ssl certificate. The auth fails because bambuddy cant fetch the OIDC config from Authentik. ### Proposed Solution It would be great if we add an toggle in the oidc settings to disable SSL verification ### Alternatives Considered _No response_ ### Feature Category Other ### Priority Critical for my use case ### Mockups or Examples _No response_ ### Contribution - [x] I would be willing to help implement this feature ### Checklist - [x] I have searched existing issues to ensure this feature hasn't already been requested
BreizhHardware 2026-05-06 12:32:49 +02:00
Author
Owner

@netscout2001 commented on GitHub (Apr 22, 2026):

Thanks for the report — this is a well-known pain point for self-hosted
OIDC providers using self-signed certificates.

The feature makes sense for homelab setups where BamBuddy and the OIDC
provider (Authentik, Keycloak, PocketID, etc.) run on the same internal
network. On a local network the practical MITM risk is low, but disabling
TLS verification entirely still has real implications:

  • The OIDC discovery document fetch is no longer authenticated → an
    attacker on the network could substitute a malicious IdP
  • The token endpoint call transmits the client_secret — interception
    would expose it
  • If the JWKS endpoint is spoofed, forged JWTs could be accepted

These risks are acceptable in a trusted private network when the user
consciously opts in, but the toggle must be clearly labeled as insecure.

Proposed implementation

Rather than only a verify=False toggle, I'd suggest implementing both
options side by side:

  1. Custom CA certificate field (preferred): The user pastes their
    root CA certificate (PEM) into a text field. httpx uses
    verify=ca_bundle — the certificate chain is still validated, just
    against a custom CA. This is the secure way to handle self-signed certs.

  2. Disable TLS verification toggle (escape hatch): Sets verify=False
    on the httpx client used for OIDC discovery and token exchange only —
    not globally. The UI should show a visible warning when this is active
    (e.g., a red badge on the provider card).

Both options would be stored on the OIDCProvider model
(verify_ssl: bool = True, ca_certificate: str | None).

Every login via a provider with verification disabled should produce a
WARNING log entry.

Questions before implementation

A few things that would help scope this correctly:

  1. Is your Authentik instance accessible only on the internal network,
    or also reachable from the internet?
  2. Do you have access to your Authentik CA certificate (PEM), or is
    adding a CA bundle not an option in your setup?
  3. Are there other OIDC providers besides Authentik where this comes up?

If the CA certificate approach works for you, it would be the better
long-term solution.

<!-- gh-comment-id:4298735048 --> @netscout2001 commented on GitHub (Apr 22, 2026): Thanks for the report — this is a well-known pain point for self-hosted OIDC providers using self-signed certificates. The feature makes sense for homelab setups where BamBuddy and the OIDC provider (Authentik, Keycloak, PocketID, etc.) run on the same internal network. On a local network the practical MITM risk is low, but disabling TLS verification entirely still has real implications: - The OIDC discovery document fetch is no longer authenticated → an attacker on the network could substitute a malicious IdP - The token endpoint call transmits the `client_secret` — interception would expose it - If the JWKS endpoint is spoofed, forged JWTs could be accepted These risks are acceptable in a trusted private network when the user consciously opts in, but the toggle must be clearly labeled as insecure. ## Proposed implementation Rather than only a `verify=False` toggle, I'd suggest implementing both options side by side: 1. **Custom CA certificate field (preferred):** The user pastes their root CA certificate (PEM) into a text field. httpx uses `verify=ca_bundle` — the certificate chain is still validated, just against a custom CA. This is the secure way to handle self-signed certs. 2. **Disable TLS verification toggle (escape hatch):** Sets `verify=False` on the httpx client used for OIDC discovery and token exchange only — not globally. The UI should show a visible warning when this is active (e.g., a red badge on the provider card). Both options would be stored on the `OIDCProvider` model (`verify_ssl: bool = True`, `ca_certificate: str | None`). Every login via a provider with verification disabled should produce a `WARNING` log entry. ## Questions before implementation A few things that would help scope this correctly: 1. Is your Authentik instance accessible only on the internal network, or also reachable from the internet? 2. Do you have access to your Authentik CA certificate (PEM), or is adding a CA bundle not an option in your setup? 3. Are there other OIDC providers besides Authentik where this comes up? If the CA certificate approach works for you, it would be the better long-term solution.
Author
Owner

@mrtncode commented on GitHub (Apr 22, 2026):

@netscout2001

  1. Of course only in internal network :)
  2. Would be possible but would also bring (unneccessary) complexity for my project.
  3. I dont know. But why not? Since its a general problem with SSL certs, it shouldnt be only a problem with Authentik
<!-- gh-comment-id:4299135988 --> @mrtncode commented on GitHub (Apr 22, 2026): @netscout2001 1. Of course only in internal network :) 2. Would be possible but would also bring (unneccessary) complexity for my project. 3. I dont know. But why not? Since its a general problem with SSL certs, it shouldnt be only a problem with Authentik
Author
Owner

@netscout2001 commented on GitHub (Apr 23, 2026):

Thank you for the report and for your willingness to contribute!

After careful consideration, we've decided not to add SSL verification controls to the OIDC provider settings. The feature would require significant security hardening to implement safely, and we believe there is a simpler and more robust solution for your use case.

What we recommend instead

Put a valid TLS certificate in front of your Authentik instance. This solves the problem permanently — not just for BamBuddy but for every other client connecting to it:

  • Caddy (easiest): automatically provisions and renews Let's Encrypt certificates with minimal configuration
  • nginx + Certbot: standard Let's Encrypt setup if you're already running nginx
  • mkcert: if your Authentik instance has no public DNS record, mkcert lets you create a local CA in minutes

All three options are well-documented and actively supported by the self-hosting community.

<!-- gh-comment-id:4303984770 --> @netscout2001 commented on GitHub (Apr 23, 2026): Thank you for the report and for your willingness to contribute! After careful consideration, we've decided not to add SSL verification controls to the OIDC provider settings. The feature would require significant security hardening to implement safely, and we believe there is a simpler and more robust solution for your use case. What we recommend instead Put a valid TLS certificate in front of your Authentik instance. This solves the problem permanently — not just for BamBuddy but for every other client connecting to it: - **Caddy** (easiest): automatically provisions and renews Let's Encrypt certificates with minimal configuration - **nginx + Certbot**: standard Let's Encrypt setup if you're already running nginx - **mkcert**: if your Authentik instance has no public DNS record, mkcert lets you create a local CA in minutes All three options are well-documented and actively supported by the self-hosting community.
Author
Owner

@maziggy commented on GitHub (Apr 23, 2026):


If you find Bambuddy useful, please consider giving it a on GitHub — it helps others discover the project!

<!-- gh-comment-id:4304004350 --> @maziggy commented on GitHub (Apr 23, 2026): ----- If you find Bambuddy useful, please consider giving it a ⭐ on [GitHub](https://github.com/maziggy/bambuddy) — it helps others discover the project!
Author
Owner

@mrtncode commented on GitHub (Apr 23, 2026):

@netscout2001 @maziggy Thats bad :(

The feature would require significant security hardening to implement safely,

Why that? The other apps with OIDC I selfhost have the same thing: Option to disable SSL verification or option to use a CA certificate. Why this reqzure security hardening?

Put a valid TLS certificate in front of your Authentik instance. This solves the problem permanently — not just for BamBuddy but for every other client connecting to it:

That isnt an option for me (and probably many others). I use local DNS names (so LE isnt an option for me). As far as I know mkcert only installs the CA certificate in the trust storage from the host device!

<!-- gh-comment-id:4305438773 --> @mrtncode commented on GitHub (Apr 23, 2026): @netscout2001 @maziggy Thats bad :( > The feature would require significant security hardening to implement safely, Why that? The other apps with OIDC I selfhost have the same thing: Option to disable SSL verification or option to use a CA certificate. Why this reqzure security hardening? > Put a valid TLS certificate in front of your Authentik instance. This solves the problem permanently — not just for BamBuddy but for every other client connecting to it: That isnt an option for me (and probably many others). I use local DNS names (so LE isnt an option for me). As far as I know mkcert only installs the CA certificate in the trust storage from the host device!
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/bambuddy#774
No description provided.