[Bug] OIDC via Cloudflare Access has incorrect username #1018

Closed
opened 2025-12-29 02:27:33 +01:00 by adam · 2 comments
Owner

Originally created by @uppercaseVar on GitHub (May 13, 2025).

Is this a support request?

  • This is not a support request

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

When a user logs in via OIDC (using Cloudflare Access), Headscale sets the username to the full Issuer URL combined with the user UUID, instead of using a more appropriate identifier like the email or sub claim. The resulting username looks like:

https://<tenant>.cloudflareaccess.com/cdn-cgi/access/sso/oidc/<client_id>/<user_uuid>

Expected Behavior

Headscale should extract a meaningful and stable identifier for the username from the OIDC token—such as the email or sub claim—rather than using the full Issuer URL with a user UUID.

Steps To Reproduce

  1. Set up OIDC authentication in Headscale using Cloudflare Access as the identity provider.
  2. Configure the issuer, client_id, and client_secret according to Cloudflare Access settings.
  3. Start Headscale with OIDC enabled.
  4. Log in as a user via the Cloudflare Access login flow.
  5. Observe the username assigned to the logged-in user.

Environment

- OS: Ubuntu 20.04.6 LTS
- Headscale version: v0.25.1
- Tailscale version: 1.82.5

Runtime environment

  • Headscale is behind a (reverse) proxy
  • Headscale runs in a container

Debug information

Headscale Configuration (OIDC section):

oidc:
  only_start_if_oidc_is_available: true
  issuer: "https://<tenant>.cloudflareaccess.com/cdn-cgi/access/sso/oidc/<client_id>"
  client_id: "<redacted>"
  client_secret: "<redacted>"
  expiry: 180d
  scope: ["openid", "profile", "email"]

All other settings are default except those required to get headscale going.

Originally created by @uppercaseVar on GitHub (May 13, 2025). ### Is this a support request? - [x] This is not a support request ### Is there an existing issue for this? - [x] I have searched the existing issues ### Current Behavior When a user logs in via OIDC (using Cloudflare Access), Headscale sets the username to the full Issuer URL combined with the user UUID, instead of using a more appropriate identifier like the email or `sub` claim. The resulting username looks like: ``` https://<tenant>.cloudflareaccess.com/cdn-cgi/access/sso/oidc/<client_id>/<user_uuid> ``` ### Expected Behavior Headscale should extract a meaningful and stable identifier for the username from the OIDC token—such as the `email` or `sub` claim—rather than using the full Issuer URL with a user UUID. ### Steps To Reproduce 1. Set up OIDC authentication in Headscale using Cloudflare Access as the identity provider. 2. Configure the `issuer`, `client_id`, and `client_secret` according to Cloudflare Access settings. 3. Start Headscale with OIDC enabled. 4. Log in as a user via the Cloudflare Access login flow. 5. Observe the username assigned to the logged-in user. ### Environment ```markdown - OS: Ubuntu 20.04.6 LTS - Headscale version: v0.25.1 - Tailscale version: 1.82.5 ``` ### Runtime environment - [ ] Headscale is behind a (reverse) proxy - [ ] Headscale runs in a container ### Debug information Headscale Configuration (OIDC section): ```yaml oidc: only_start_if_oidc_is_available: true issuer: "https://<tenant>.cloudflareaccess.com/cdn-cgi/access/sso/oidc/<client_id>" client_id: "<redacted>" client_secret: "<redacted>" expiry: 180d scope: ["openid", "profile", "email"] ``` All other settings are default except those required to get headscale going.
adam added the stalebug labels 2025-12-29 02:27:33 +01:00
adam closed this issue 2025-12-29 02:27:34 +01:00
Author
Owner

@github-actions[bot] commented on GitHub (Aug 12, 2025):

This issue is stale because it has been open for 90 days with no activity.

@github-actions[bot] commented on GitHub (Aug 12, 2025): This issue is stale because it has been open for 90 days with no activity.
Author
Owner

@github-actions[bot] commented on GitHub (Aug 20, 2025):

This issue was closed because it has been inactive for 14 days since being marked as stale.

@github-actions[bot] commented on GitHub (Aug 20, 2025): This issue was closed because it has been inactive for 14 days since being marked as stale.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#1018