starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-11 20:00:28 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

[Bug] OIDC users don't always get a username #901

New Issue
Closed
opened 2025-12-29 02:25:36 +01:00 by adam · 42 comments
adam commented 2025-12-29 02:25:36 +01:00
Owner
Copy Link

Originally created by @ToxicMushroom on GitHub (Jan 8, 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 logging in for the first time with oidc I only got a display_name and no username/name set in headscale.

This can be worked around currently by docker exec headscale headscale users rename --identifier 1 -r merlijn
But that'd be inconvenient for future users so it should probably get resolved.

Expected Behavior

All the required user fields get set when logging in with oidc,

  • either by requiring certain claims are present in the idToken.
  • or by making the cli commands more flexible: by accepting user ids as an alternative.

Steps To Reproduce

  1. Setup OIDC (can see my config below)
  2. Authenticate new user (My oidc resource server is ran on Kanidm, returned claims are also below)
  3. List the user's fields (also below)

Environment

- OS: Debian 12
- Headscale version: ghcr.io/juanfont/headscale:0.24.0-beta.2-debug
- Tailscale version: 1.78.1

Runtime environment

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

Anything else?

root@zungenbrecher:/opt/vpn_exit_node# docker exec headscale headscale users list -o json

[
    {
        "id": 1,
        "created_at": {
            "seconds": 1735582411,
            "nanos": 102993003
        },
        "display_name": "Merlijn",
        "provider_id": "oauth2urlthing",
        "provider": "oidc"
    }
]
oidc claims for my user with "profile", "email", "groups" scopes 
claims: {
    "sub": "2fa57e05-fcc9-43db-8ca6-a98602346aa5",
    "exp": 1736341021,
    "name": "Merlijn",
    "preferred_username": "merlijn@idm.melijn.com",
    "groups": [
        "idm_all_persons@idm.melijn.com",
        "00000000-0000-0000-0000-000000000035",
        "idm_all_accounts@idm.melijn.com",
        "00000000-0000-0000-0000-000000000036",
        "poweruser@idm.melijn.com",
        "91f2f258-3122-4644-a860-cbfe2cce5b73",
        "seafile_users@idm.melijn.com",
        "1163f5cc-6dee-46c8-85db-fd635247c9bd",
        "friends@idm.melijn.com",
        "553b933b-0f01-432d-88a8-d69b182c4cf6",
        "xmpp_users@idm.melijn.com",
        "77b999f8-cd55-4a71-8133-ee9ec674e02f",
        "jellyfin_users@idm.melijn.com",
        "ef5a6995-759f-48fa-a4cf-262506f7712e",
        "melijn_admin@idm.melijn.com",
        "f5c60e0c-0562-438e-908b-f6182a9e1651",
        "jellyfin_admin@idm.melijn.com",
        "844abd6f-f2d9-4b61-9bec-6625e6cb3501",
        "mastodon_admin@idm.melijn.com",
        "4bc73263-b472-4fa8-87fe-ba3c5ffe2841",
        "mastodon_users@idm.melijn.com",
        "432f03b2-260a-4c16-8588-5fdabf805c01",
        "webdav_users@idm.melijn.com",
        "8141a6e0-0f66-4a3d-b287-550b5e4477dd",
        "git_users@idm.melijn.com",
        "d827b7e0-2a54-41a8-bb30-4fada22b9c4d",
        "immich_users@idm.melijn.com",
        "185f75f5-6527-47be-8058-9cf0978aa63f",
        "family@idm.melijn.com",
        "dbcb4f90-5451-4967-86f6-5faa2f94670b",
        "mealie_users@idm.melijn.com",
        "cbcb7793-f25b-48a1-93e2-d9593b70a151",
        "komga_users@idm.melijn.com",
        "292b042d-84db-4541-8f3c-465394efaae7",
        "mealie_admins@idm.melijn.com",
        "89239a93-efc6-4cca-bbfe-f1ba1bdf547f",
        "idm_people_self_name_write@idm.melijn.com",
        "00000000-0000-0000-0000-000000000048",
        "headscale_users@idm.melijn.com",
        "b0b1647e-a4d5-4e25-a211-3824e06fae8b",
        "headscale_admins@idm.melijn.com",
        "b367fe8e-2041-47ee-abec-af5a2fb230fb"
    ],
    "email": "redacted against spam bots",
    "email_verified": true
}
config.yaml 
---
# headscale will look for a configuration file named `config.yaml` (or `config.json`) in the following order:
#
# - `/etc/headscale`
# - `~/.headscale`
# - current working directory

# The url clients will connect to.
# Typically this will be a domain like:
#
# https://myheadscale.example.com:443
#
server_url: https://headscale.example.com

# Address to listen to / bind to on the server
#
# For production:
# listen_addr: 0.0.0.0:8080
listen_addr: 0.0.0.0:8080

# Address to listen to /metrics, you may want
# to keep this endpoint private to your internal
# network
#
metrics_listen_addr: 127.0.0.1:9090

# Address to listen for gRPC.
# gRPC is used for controlling a headscale server
# remotely with the CLI
# Note: Remote access _only_ works if you have
# valid certificates.
#
# For production:
# grpc_listen_addr: 0.0.0.0:50443
grpc_listen_addr: 127.0.0.1:50443

# Allow the gRPC admin interface to run in INSECURE
# mode. This is not recommended as the traffic will
# be unencrypted. Only enable if you know what you
# are doing.
grpc_allow_insecure: false

# The Noise section includes specific configuration for the
# TS2021 Noise protocol
noise:
  # The Noise private key is used to encrypt the
  # traffic between headscale and Tailscale clients when
  # using the new Noise-based protocol.
  private_key_path: /var/lib/headscale/noise_private.key

# List of IP prefixes to allocate tailaddresses from.
# Each prefix consists of either an IPv4 or IPv6 address,
# and the associated prefix length, delimited by a slash.
# It must be within IP ranges supported by the Tailscale
# client - i.e., subnets of 100.64.0.0/10 and fd7a:115c:a1e0::/48.
# See below:
# IPv6: https://github.com/tailscale/tailscale/blob/22ebb25e833264f58d7c3f534a8b166894a89536/net/tsaddr/tsaddr.go#LL81C52-L81C71
# IPv4: https://github.com/tailscale/tailscale/blob/22ebb25e833264f58d7c3f534a8b166894a89536/net/tsaddr/tsaddr.go#L33
# Any other range is NOT supported, and it will cause unexpected issues.
prefixes:
  v4: 100.64.0.0/10
  v6: fd7a:115c:a1e0::/48

  # Strategy used for allocation of IPs to nodes, available options:
  # - sequential (default): assigns the next free IP from the previous given IP.
  # - random: assigns the next free IP from a pseudo-random IP generator (crypto/rand).
  allocation: sequential

# DERP is a relay system that Tailscale uses when a direct
# connection cannot be established.
# https://tailscale.com/blog/how-tailscale-works/#encrypted-tcp-relays-derp
#
# headscale needs a list of DERP servers that can be presented
# to the clients.
derp:
  server:
    # If enabled, runs the embedded DERP server and merges it into the rest of the DERP config
    # The Headscale server_url defined above MUST be using https, DERP requires TLS to be in place
    enabled: false

    # Region ID to use for the embedded DERP server.
    # The local DERP prevails if the region ID collides with other region ID coming from
    # the regular DERP config.
    region_id: 999

    # Region code and name are displayed in the Tailscale UI to identify a DERP region
    region_code: "headscale"
    region_name: "Headscale Embedded DERP"

    # Listens over UDP at the configured address for STUN connections - to help with NAT traversal.
    # When the embedded DERP server is enabled stun_listen_addr MUST be defined.
    #
    # For more details on how this works, check this great article: https://tailscale.com/blog/how-tailscale-works/
    stun_listen_addr: "0.0.0.0:3478"

    # Private key used to encrypt the traffic between headscale DERP
    # and Tailscale clients.
    # The private key file will be autogenerated if it's missing.
    #
    private_key_path: /var/lib/headscale/derp_server_private.key

    # This flag can be used, so the DERP map entry for the embedded DERP server is not written automatically,
    # it enables the creation of your very own DERP map entry using a locally available file with the parameter DERP.paths
    # If you enable the DERP server and set this to false, it is required to add the DERP server to the DERP map using DERP.paths
    automatically_add_embedded_derp_region: true

    # For better connection stability (especially when using an Exit-Node and DNS is not working),
    # it is possible to optionally add the public IPv4 and IPv6 address to the Derp-Map using:
    ipv4: 1.2.3.4
    ipv6: 2001:db8::1

  # List of externally available DERP maps encoded in JSON
  urls:
    - https://controlplane.tailscale.com/derpmap/default

  # Locally available DERP map files encoded in YAML
  #
  # This option is mostly interesting for people hosting
  # their own DERP servers:
  # https://tailscale.com/kb/1118/custom-derp-servers/
  #
  # paths:
  #   - /etc/headscale/derp-example.yaml
  paths: []

  # If enabled, a worker will be set up to periodically
  # refresh the given sources and update the derpmap
  # will be set up.
  auto_update_enabled: true

  # How often should we check for DERP updates?
  update_frequency: 24h

# Disables the automatic check for headscale updates on startup
disable_check_updates: false

# Time before an inactive ephemeral node is deleted?
ephemeral_node_inactivity_timeout: 30m

database:
  # Database type. Available options: sqlite, postgres
  # Please note that using Postgres is highly discouraged as it is only supported for legacy reasons.
  # All new development, testing and optimisations are done with SQLite in mind.
  type: sqlite

  # Enable debug mode. This setting requires the log.level to be set to "debug" or "trace".
  debug: false

  # GORM configuration settings.
  gorm:
    # Enable prepared statements.
    prepare_stmt: true

    # Enable parameterized queries.
    parameterized_queries: true

    # Skip logging "record not found" errors.
    skip_err_record_not_found: true

    # Threshold for slow queries in milliseconds.
    slow_threshold: 1000

  # SQLite config
  sqlite:
    path: /var/lib/headscale/db.sqlite

    # Enable WAL mode for SQLite. This is recommended for production environments.
    # https://www.sqlite.org/wal.html
    write_ahead_log: true

    # Maximum number of WAL file frames before the WAL file is automatically checkpointed.
    # https://www.sqlite.org/c3ref/wal_autocheckpoint.html
    # Set to 0 to disable automatic checkpointing.
    wal_autocheckpoint: 1000

  # # Postgres config
  # Please note that using Postgres is highly discouraged as it is only supported for legacy reasons.
  # See database.type for more information.
  # postgres:
  #   # If using a Unix socket to connect to Postgres, set the socket path in the 'host' field and leave 'port' blank.
  #   host: localhost
  #   port: 5432
  #   name: headscale
  #   user: foo
  #   pass: bar
  #   max_open_conns: 10
  #   max_idle_conns: 10
  #   conn_max_idle_time_secs: 3600

  #   # If other 'sslmode' is required instead of 'require(true)' and 'disabled(false)', set the 'sslmode' you need
  #   # in the 'ssl' field. Refers to https://www.postgresql.org/docs/current/libpq-ssl.html Table 34.1.
  #   ssl: false

### TLS configuration
#
## Let's encrypt / ACME
#
# headscale supports automatically requesting and setting up
# TLS for a domain with Let's Encrypt.
#
# URL to ACME directory
acme_url: https://acme-v02.api.letsencrypt.org/directory

# Email to register with ACME provider
acme_email: ""

# Domain name to request a TLS certificate for:
tls_letsencrypt_hostname: ""

# Path to store certificates and metadata needed by
# letsencrypt
# For production:
tls_letsencrypt_cache_dir: /var/lib/headscale/cache

# Type of ACME challenge to use, currently supported types:
# HTTP-01 or TLS-ALPN-01
# See: docs/ref/tls.md for more information
tls_letsencrypt_challenge_type: HTTP-01
# When HTTP-01 challenge is chosen, letsencrypt must set up a
# verification endpoint, and it will be listening on:
# :http = port 80
tls_letsencrypt_listen: ":http"

## Use already defined certificates:
tls_cert_path: ""
tls_key_path: ""

log:
  # Output formatting for logs: text or json
  format: text
  level: info

## Policy
# headscale supports Tailscale's ACL policies.
# Please have a look to their KB to better
# understand the concepts: https://tailscale.com/kb/1018/acls/
policy:
  # The mode can be "file" or "database" that defines
  # where the ACL policies are stored and read from.
  mode: file
  # If the mode is set to "file", the path to a
  # HuJSON file containing ACL policies.
  path: ""

## DNS
#
# headscale supports Tailscale's DNS configuration and MagicDNS.
# Please have a look to their KB to better understand the concepts:
#
# - https://tailscale.com/kb/1054/dns/
# - https://tailscale.com/kb/1081/magicdns/
# - https://tailscale.com/blog/2021-09-private-dns-with-magicdns/
#
# Please note that for the DNS configuration to have any effect,
# clients must have the `--accept-dns=true` option enabled. This is the
# default for the Tailscale client. This option is enabled by default
# in the Tailscale client.
#
# Setting _any_ of the configuration and `--accept-dns=true` on the
# clients will integrate with the DNS manager on the client or
# overwrite /etc/resolv.conf.
# https://tailscale.com/kb/1235/resolv-conf
#
# If you want stop Headscale from managing the DNS configuration
# all the fields under `dns` should be set to empty values.
dns:
  # Whether to use [MagicDNS](https://tailscale.com/kb/1081/magicdns/).
  magic_dns: true

  # Defines the base domain to create the hostnames for MagicDNS.
  # This domain _must_ be different from the server_url domain.
  # `base_domain` must be a FQDN, without the trailing dot.
  # The FQDN of the hosts will be
  # `hostname.base_domain` (e.g., _myhost.example.com_).
  base_domain: kliek

  # List of DNS servers to expose to clients.
  nameservers:
    global:
      # NextDNS (see https://tailscale.com/kb/1218/nextdns/).
      # "abc123" is example NextDNS ID, replace with yours.
      # - https://dns.nextdns.io/abc123

    # Split DNS (see https://tailscale.com/kb/1054/dns/),
    # a map of domains and which DNS server to use for each.
    split:
      {}
      # foo.bar.com:
      #   - 1.1.1.1
      # darp.headscale.net:
      #   - 1.1.1.1
      #   - 8.8.8.8

  # Set custom DNS search domains. With MagicDNS enabled,
  # your tailnet base_domain is always the first search domain.
  search_domains: []

  # Extra DNS records
  # so far only A and AAAA records are supported (on the tailscale side)
  # See: docs/ref/dns.md
  extra_records: []
  #   - name: "grafana.myvpn.example.com"
  #     type: "A"
  #     value: "100.64.0.3"
  #
  #   # you can also put it in one line
  #   - { name: "prometheus.myvpn.example.com", type: "A", value: "100.64.0.3" }
  #
  # Alternatively, extra DNS records can be loaded from a JSON file.
  # Headscale processes this file on each change.
  # extra_records_path: /var/lib/headscale/extra-records.json

# Unix socket used for the CLI to connect without authentication
# Note: for production you will want to set this to something like:
unix_socket: /var/run/headscale/headscale.sock
unix_socket_permission: "0770"
#
# headscale supports experimental OpenID connect support,
# it is still being tested and might have some bugs, please
# help us test it.
# OpenID Connect
oidc:
  only_start_if_oidc_is_available: true
  issuer: "https://idm.example.com/oauth2/openid/headscale"
  client_id: "headscale"
  client_secret: ""
  # Alternatively, set `client_secret_path` to read the secret from the file.
  # It resolves environment variables, making integration to systemd's
  # `LoadCredential` straightforward:
  # client_secret_path: "${CREDENTIALS_DIRECTORY}/oidc_client_secret"
  # client_secret and client_secret_path are mutually exclusive.

  # The amount of time from a node is authenticated with OpenID until it
  # expires and needs to reauthenticate.
  # Setting the value to "0" will mean no expiry.
  expiry: 180d

  # Use the expiry from the token received from OpenID when the user logged
  # in, this will typically lead to frequent need to reauthenticate and should
  # only been enabled if you know what you are doing.
  # Note: enabling this will cause `oidc.expiry` to be ignored.
  use_expiry_from_token: false
  # Customize the scopes used in the OIDC flow, defaults to "openid", "profile" and "email" and add custom query
  # parameters to the Authorize Endpoint request. Scopes default to "openid", "profile" and "email".

  scope: ["openid", "profile", "groups"]
  #  extra_params:
  #    domain_hint: example.com

#   # List allowed principal domains and/or users. If an authenticated user's domain is not in this list, the
#   # authentication request will be rejected.
#   allowed_domains:
#     - example.com
#   # Note: Groups from keycloak have a leading '/'
  allowed_groups:
    - headscale_users
    - headscale_users@idm.melijn.com
    - headscale_admins
#   allowed_users:
#     - alice@example.com
#
#   # Optional: PKCE (Proof Key for Code Exchange) configuration
#   # PKCE adds an additional layer of security to the OAuth 2.0 authorization code flow
#   # by preventing authorization code interception attacks
#   # See https://datatracker.ietf.org/doc/html/rfc7636
  pkce:
#     # Enable or disable PKCE support (default: false)
    enabled: false
#     # PKCE method to use:
#     # - plain: Use plain code verifier
#     # - S256: Use SHA256 hashed code verifier (default, recommended)
    method: S256
#
#   # Map legacy users from pre-0.24.0 versions of headscale to the new OIDC users
#   # by taking the username from the legacy user and matching it with the username
#   # provided by the OIDC. This is useful when migrating from legacy users to OIDC
#   # to force them using the unique identifier from the OIDC and to give them a
#   # proper display name and picture if available.
#   # Note that this will only work if the username from the legacy user is the same
#   # and there is a possibility for account takeover should a username have changed
#   # with the provider.
#   # Disabling this feature will cause all new logins to be created as new users.
#   # Note this option will be removed in the future and should be set to false
#   # on all new installations, or when all users have logged in with OIDC once.
#   map_legacy_users: true

# Logtail configuration
# Logtail is Tailscales logging and auditing infrastructure, it allows the control panel
# to instruct tailscale nodes to log their activity to a remote server.
logtail:
  # Enable logtail for this headscales clients.
  # As there is currently no support for overriding the log server in headscale, this is
  # disabled by default. Enabling this will make your clients send logs to Tailscale Inc.
  enabled: false

# Enabling this option makes devices prefer a random port for WireGuard traffic over the
# default static port 41641. This option is intended as a workaround for some buggy
# firewall devices. See https://tailscale.com/kb/1181/firewalls/ for more information.
randomize_client_port: false
Originally created by @ToxicMushroom on GitHub (Jan 8, 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 logging in for the first time with oidc I only got a display_name and no username/name set in headscale. This can be worked around currently by `docker exec headscale headscale users rename --identifier 1 -r merlijn` But that'd be inconvenient for future users so it should probably get resolved. ### Expected Behavior All the required user fields get set when logging in with oidc, - either by requiring certain claims are present in the idToken. - or by making the cli commands more flexible: by accepting user ids as an alternative. ### Steps To Reproduce 1. Setup OIDC (can see my config below) 2. Authenticate new user (My oidc resource server is ran on Kanidm, returned claims are also below) 3. List the user's fields (also below) ### Environment ```markdown - OS: Debian 12 - Headscale version: ghcr.io/juanfont/headscale:0.24.0-beta.2-debug - Tailscale version: 1.78.1 ``` ### Runtime environment - [X] Headscale is behind a (reverse) proxy - [X] Headscale runs in a container ### Anything else? `root@zungenbrecher:/opt/vpn_exit_node# docker exec headscale headscale users list -o json` ```json [ { "id": 1, "created_at": { "seconds": 1735582411, "nanos": 102993003 }, "display_name": "Merlijn", "provider_id": "oauth2urlthing", "provider": "oidc" } ] ``` <details> <summary>oidc claims for my user with "profile", "email", "groups" scopes</summary> ```json claims: { "sub": "2fa57e05-fcc9-43db-8ca6-a98602346aa5", "exp": 1736341021, "name": "Merlijn", "preferred_username": "merlijn@idm.melijn.com", "groups": [ "idm_all_persons@idm.melijn.com", "00000000-0000-0000-0000-000000000035", "idm_all_accounts@idm.melijn.com", "00000000-0000-0000-0000-000000000036", "poweruser@idm.melijn.com", "91f2f258-3122-4644-a860-cbfe2cce5b73", "seafile_users@idm.melijn.com", "1163f5cc-6dee-46c8-85db-fd635247c9bd", "friends@idm.melijn.com", "553b933b-0f01-432d-88a8-d69b182c4cf6", "xmpp_users@idm.melijn.com", "77b999f8-cd55-4a71-8133-ee9ec674e02f", "jellyfin_users@idm.melijn.com", "ef5a6995-759f-48fa-a4cf-262506f7712e", "melijn_admin@idm.melijn.com", "f5c60e0c-0562-438e-908b-f6182a9e1651", "jellyfin_admin@idm.melijn.com", "844abd6f-f2d9-4b61-9bec-6625e6cb3501", "mastodon_admin@idm.melijn.com", "4bc73263-b472-4fa8-87fe-ba3c5ffe2841", "mastodon_users@idm.melijn.com", "432f03b2-260a-4c16-8588-5fdabf805c01", "webdav_users@idm.melijn.com", "8141a6e0-0f66-4a3d-b287-550b5e4477dd", "git_users@idm.melijn.com", "d827b7e0-2a54-41a8-bb30-4fada22b9c4d", "immich_users@idm.melijn.com", "185f75f5-6527-47be-8058-9cf0978aa63f", "family@idm.melijn.com", "dbcb4f90-5451-4967-86f6-5faa2f94670b", "mealie_users@idm.melijn.com", "cbcb7793-f25b-48a1-93e2-d9593b70a151", "komga_users@idm.melijn.com", "292b042d-84db-4541-8f3c-465394efaae7", "mealie_admins@idm.melijn.com", "89239a93-efc6-4cca-bbfe-f1ba1bdf547f", "idm_people_self_name_write@idm.melijn.com", "00000000-0000-0000-0000-000000000048", "headscale_users@idm.melijn.com", "b0b1647e-a4d5-4e25-a211-3824e06fae8b", "headscale_admins@idm.melijn.com", "b367fe8e-2041-47ee-abec-af5a2fb230fb" ], "email": "redacted against spam bots", "email_verified": true } ``` </details> <details> <summary>config.yaml</summary> ```yaml --- # headscale will look for a configuration file named `config.yaml` (or `config.json`) in the following order: # # - `/etc/headscale` # - `~/.headscale` # - current working directory # The url clients will connect to. # Typically this will be a domain like: # # https://myheadscale.example.com:443 # server_url: https://headscale.example.com # Address to listen to / bind to on the server # # For production: # listen_addr: 0.0.0.0:8080 listen_addr: 0.0.0.0:8080 # Address to listen to /metrics, you may want # to keep this endpoint private to your internal # network # metrics_listen_addr: 127.0.0.1:9090 # Address to listen for gRPC. # gRPC is used for controlling a headscale server # remotely with the CLI # Note: Remote access _only_ works if you have # valid certificates. # # For production: # grpc_listen_addr: 0.0.0.0:50443 grpc_listen_addr: 127.0.0.1:50443 # Allow the gRPC admin interface to run in INSECURE # mode. This is not recommended as the traffic will # be unencrypted. Only enable if you know what you # are doing. grpc_allow_insecure: false # The Noise section includes specific configuration for the # TS2021 Noise protocol noise: # The Noise private key is used to encrypt the # traffic between headscale and Tailscale clients when # using the new Noise-based protocol. private_key_path: /var/lib/headscale/noise_private.key # List of IP prefixes to allocate tailaddresses from. # Each prefix consists of either an IPv4 or IPv6 address, # and the associated prefix length, delimited by a slash. # It must be within IP ranges supported by the Tailscale # client - i.e., subnets of 100.64.0.0/10 and fd7a:115c:a1e0::/48. # See below: # IPv6: https://github.com/tailscale/tailscale/blob/22ebb25e833264f58d7c3f534a8b166894a89536/net/tsaddr/tsaddr.go#LL81C52-L81C71 # IPv4: https://github.com/tailscale/tailscale/blob/22ebb25e833264f58d7c3f534a8b166894a89536/net/tsaddr/tsaddr.go#L33 # Any other range is NOT supported, and it will cause unexpected issues. prefixes: v4: 100.64.0.0/10 v6: fd7a:115c:a1e0::/48 # Strategy used for allocation of IPs to nodes, available options: # - sequential (default): assigns the next free IP from the previous given IP. # - random: assigns the next free IP from a pseudo-random IP generator (crypto/rand). allocation: sequential # DERP is a relay system that Tailscale uses when a direct # connection cannot be established. # https://tailscale.com/blog/how-tailscale-works/#encrypted-tcp-relays-derp # # headscale needs a list of DERP servers that can be presented # to the clients. derp: server: # If enabled, runs the embedded DERP server and merges it into the rest of the DERP config # The Headscale server_url defined above MUST be using https, DERP requires TLS to be in place enabled: false # Region ID to use for the embedded DERP server. # The local DERP prevails if the region ID collides with other region ID coming from # the regular DERP config. region_id: 999 # Region code and name are displayed in the Tailscale UI to identify a DERP region region_code: "headscale" region_name: "Headscale Embedded DERP" # Listens over UDP at the configured address for STUN connections - to help with NAT traversal. # When the embedded DERP server is enabled stun_listen_addr MUST be defined. # # For more details on how this works, check this great article: https://tailscale.com/blog/how-tailscale-works/ stun_listen_addr: "0.0.0.0:3478" # Private key used to encrypt the traffic between headscale DERP # and Tailscale clients. # The private key file will be autogenerated if it's missing. # private_key_path: /var/lib/headscale/derp_server_private.key # This flag can be used, so the DERP map entry for the embedded DERP server is not written automatically, # it enables the creation of your very own DERP map entry using a locally available file with the parameter DERP.paths # If you enable the DERP server and set this to false, it is required to add the DERP server to the DERP map using DERP.paths automatically_add_embedded_derp_region: true # For better connection stability (especially when using an Exit-Node and DNS is not working), # it is possible to optionally add the public IPv4 and IPv6 address to the Derp-Map using: ipv4: 1.2.3.4 ipv6: 2001:db8::1 # List of externally available DERP maps encoded in JSON urls: - https://controlplane.tailscale.com/derpmap/default # Locally available DERP map files encoded in YAML # # This option is mostly interesting for people hosting # their own DERP servers: # https://tailscale.com/kb/1118/custom-derp-servers/ # # paths: # - /etc/headscale/derp-example.yaml paths: [] # If enabled, a worker will be set up to periodically # refresh the given sources and update the derpmap # will be set up. auto_update_enabled: true # How often should we check for DERP updates? update_frequency: 24h # Disables the automatic check for headscale updates on startup disable_check_updates: false # Time before an inactive ephemeral node is deleted? ephemeral_node_inactivity_timeout: 30m database: # Database type. Available options: sqlite, postgres # Please note that using Postgres is highly discouraged as it is only supported for legacy reasons. # All new development, testing and optimisations are done with SQLite in mind. type: sqlite # Enable debug mode. This setting requires the log.level to be set to "debug" or "trace". debug: false # GORM configuration settings. gorm: # Enable prepared statements. prepare_stmt: true # Enable parameterized queries. parameterized_queries: true # Skip logging "record not found" errors. skip_err_record_not_found: true # Threshold for slow queries in milliseconds. slow_threshold: 1000 # SQLite config sqlite: path: /var/lib/headscale/db.sqlite # Enable WAL mode for SQLite. This is recommended for production environments. # https://www.sqlite.org/wal.html write_ahead_log: true # Maximum number of WAL file frames before the WAL file is automatically checkpointed. # https://www.sqlite.org/c3ref/wal_autocheckpoint.html # Set to 0 to disable automatic checkpointing. wal_autocheckpoint: 1000 # # Postgres config # Please note that using Postgres is highly discouraged as it is only supported for legacy reasons. # See database.type for more information. # postgres: # # If using a Unix socket to connect to Postgres, set the socket path in the 'host' field and leave 'port' blank. # host: localhost # port: 5432 # name: headscale # user: foo # pass: bar # max_open_conns: 10 # max_idle_conns: 10 # conn_max_idle_time_secs: 3600 # # If other 'sslmode' is required instead of 'require(true)' and 'disabled(false)', set the 'sslmode' you need # # in the 'ssl' field. Refers to https://www.postgresql.org/docs/current/libpq-ssl.html Table 34.1. # ssl: false ### TLS configuration # ## Let's encrypt / ACME # # headscale supports automatically requesting and setting up # TLS for a domain with Let's Encrypt. # # URL to ACME directory acme_url: https://acme-v02.api.letsencrypt.org/directory # Email to register with ACME provider acme_email: "" # Domain name to request a TLS certificate for: tls_letsencrypt_hostname: "" # Path to store certificates and metadata needed by # letsencrypt # For production: tls_letsencrypt_cache_dir: /var/lib/headscale/cache # Type of ACME challenge to use, currently supported types: # HTTP-01 or TLS-ALPN-01 # See: docs/ref/tls.md for more information tls_letsencrypt_challenge_type: HTTP-01 # When HTTP-01 challenge is chosen, letsencrypt must set up a # verification endpoint, and it will be listening on: # :http = port 80 tls_letsencrypt_listen: ":http" ## Use already defined certificates: tls_cert_path: "" tls_key_path: "" log: # Output formatting for logs: text or json format: text level: info ## Policy # headscale supports Tailscale's ACL policies. # Please have a look to their KB to better # understand the concepts: https://tailscale.com/kb/1018/acls/ policy: # The mode can be "file" or "database" that defines # where the ACL policies are stored and read from. mode: file # If the mode is set to "file", the path to a # HuJSON file containing ACL policies. path: "" ## DNS # # headscale supports Tailscale's DNS configuration and MagicDNS. # Please have a look to their KB to better understand the concepts: # # - https://tailscale.com/kb/1054/dns/ # - https://tailscale.com/kb/1081/magicdns/ # - https://tailscale.com/blog/2021-09-private-dns-with-magicdns/ # # Please note that for the DNS configuration to have any effect, # clients must have the `--accept-dns=true` option enabled. This is the # default for the Tailscale client. This option is enabled by default # in the Tailscale client. # # Setting _any_ of the configuration and `--accept-dns=true` on the # clients will integrate with the DNS manager on the client or # overwrite /etc/resolv.conf. # https://tailscale.com/kb/1235/resolv-conf # # If you want stop Headscale from managing the DNS configuration # all the fields under `dns` should be set to empty values. dns: # Whether to use [MagicDNS](https://tailscale.com/kb/1081/magicdns/). magic_dns: true # Defines the base domain to create the hostnames for MagicDNS. # This domain _must_ be different from the server_url domain. # `base_domain` must be a FQDN, without the trailing dot. # The FQDN of the hosts will be # `hostname.base_domain` (e.g., _myhost.example.com_). base_domain: kliek # List of DNS servers to expose to clients. nameservers: global: # NextDNS (see https://tailscale.com/kb/1218/nextdns/). # "abc123" is example NextDNS ID, replace with yours. # - https://dns.nextdns.io/abc123 # Split DNS (see https://tailscale.com/kb/1054/dns/), # a map of domains and which DNS server to use for each. split: {} # foo.bar.com: # - 1.1.1.1 # darp.headscale.net: # - 1.1.1.1 # - 8.8.8.8 # Set custom DNS search domains. With MagicDNS enabled, # your tailnet base_domain is always the first search domain. search_domains: [] # Extra DNS records # so far only A and AAAA records are supported (on the tailscale side) # See: docs/ref/dns.md extra_records: [] # - name: "grafana.myvpn.example.com" # type: "A" # value: "100.64.0.3" # # # you can also put it in one line # - { name: "prometheus.myvpn.example.com", type: "A", value: "100.64.0.3" } # # Alternatively, extra DNS records can be loaded from a JSON file. # Headscale processes this file on each change. # extra_records_path: /var/lib/headscale/extra-records.json # Unix socket used for the CLI to connect without authentication # Note: for production you will want to set this to something like: unix_socket: /var/run/headscale/headscale.sock unix_socket_permission: "0770" # # headscale supports experimental OpenID connect support, # it is still being tested and might have some bugs, please # help us test it. # OpenID Connect oidc: only_start_if_oidc_is_available: true issuer: "https://idm.example.com/oauth2/openid/headscale" client_id: "headscale" client_secret: "" # Alternatively, set `client_secret_path` to read the secret from the file. # It resolves environment variables, making integration to systemd's # `LoadCredential` straightforward: # client_secret_path: "${CREDENTIALS_DIRECTORY}/oidc_client_secret" # client_secret and client_secret_path are mutually exclusive. # The amount of time from a node is authenticated with OpenID until it # expires and needs to reauthenticate. # Setting the value to "0" will mean no expiry. expiry: 180d # Use the expiry from the token received from OpenID when the user logged # in, this will typically lead to frequent need to reauthenticate and should # only been enabled if you know what you are doing. # Note: enabling this will cause `oidc.expiry` to be ignored. use_expiry_from_token: false # Customize the scopes used in the OIDC flow, defaults to "openid", "profile" and "email" and add custom query # parameters to the Authorize Endpoint request. Scopes default to "openid", "profile" and "email". scope: ["openid", "profile", "groups"] # extra_params: # domain_hint: example.com # # List allowed principal domains and/or users. If an authenticated user's domain is not in this list, the # # authentication request will be rejected. # allowed_domains: # - example.com # # Note: Groups from keycloak have a leading '/' allowed_groups: - headscale_users - headscale_users@idm.melijn.com - headscale_admins # allowed_users: # - alice@example.com # # # Optional: PKCE (Proof Key for Code Exchange) configuration # # PKCE adds an additional layer of security to the OAuth 2.0 authorization code flow # # by preventing authorization code interception attacks # # See https://datatracker.ietf.org/doc/html/rfc7636 pkce: # # Enable or disable PKCE support (default: false) enabled: false # # PKCE method to use: # # - plain: Use plain code verifier # # - S256: Use SHA256 hashed code verifier (default, recommended) method: S256 # # # Map legacy users from pre-0.24.0 versions of headscale to the new OIDC users # # by taking the username from the legacy user and matching it with the username # # provided by the OIDC. This is useful when migrating from legacy users to OIDC # # to force them using the unique identifier from the OIDC and to give them a # # proper display name and picture if available. # # Note that this will only work if the username from the legacy user is the same # # and there is a possibility for account takeover should a username have changed # # with the provider. # # Disabling this feature will cause all new logins to be created as new users. # # Note this option will be removed in the future and should be set to false # # on all new installations, or when all users have logged in with OIDC once. # map_legacy_users: true # Logtail configuration # Logtail is Tailscales logging and auditing infrastructure, it allows the control panel # to instruct tailscale nodes to log their activity to a remote server. logtail: # Enable logtail for this headscales clients. # As there is currently no support for overriding the log server in headscale, this is # disabled by default. Enabling this will make your clients send logs to Tailscale Inc. enabled: false # Enabling this option makes devices prefer a random port for WireGuard traffic over the # default static port 41641. This option is intended as a workaround for some buggy # firewall devices. See https://tailscale.com/kb/1181/firewalls/ for more information. randomize_client_port: false ``` </details>
adam added the bugOIDC labels 2025-12-29 02:25:36 +01:00
adam closed this issue 2025-12-29 02:25:36 +01:00
adam commented 2025-12-29 02:25:36 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Jan 9, 2025):

which OIDC provider do you use? I noticed that Google for example does not provide a username. If the provider does not provide one, it will not be set.

@kradalby commented on GitHub (Jan 9, 2025): which OIDC provider do you use? I noticed that Google for example does not provide a username. If the provider does not provide one, it will not be set.
adam commented 2025-12-29 02:25:37 +01:00
Author
Owner
Copy Link

@ToxicMushroom commented on GitHub (Jan 9, 2025):

I use https://github.com/kanidm/kanidm

@ToxicMushroom commented on GitHub (Jan 9, 2025): I use https://github.com/kanidm/kanidm
adam commented 2025-12-29 02:25:37 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Jan 9, 2025):

Can you provide a the claim json as an example?

@kradalby commented on GitHub (Jan 9, 2025): Can you provide a the claim json as an example?
adam commented 2025-12-29 02:25:37 +01:00
Author
Owner
Copy Link

@ToxicMushroom commented on GitHub (Jan 9, 2025):

Can you provide a the claim json as an example?

It is in the original post under anything else ? in the oidc claims for my user with "profile", "email", "groups" scopes block

@ToxicMushroom commented on GitHub (Jan 9, 2025): > Can you provide a the claim json as an example? It is in the original post under `anything else ?` in the `oidc claims for my user with "profile", "email", "groups" scopes` block
adam commented 2025-12-29 02:25:37 +01:00
Author
Owner
Copy Link

@ToxicMushroom commented on GitHub (Jan 9, 2025):

I think I found the line here @kradalby ede4f97a16/hscontrol/types/users.go (L178)

The err that is checked does not seem to ever get printed.
I don't think my preferred_username passes the regex check in the FQDN function.

@ToxicMushroom commented on GitHub (Jan 9, 2025): I think I found the line here @kradalby https://github.com/juanfont/headscale/blob/ede4f97a16b0b2d357d3584431e9feb34d43fc89/hscontrol/types/users.go#L178 The err that is checked does not seem to ever get printed. I don't think my preferred_username passes the regex check in the FQDN function.
adam commented 2025-12-29 02:25:37 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Jan 9, 2025):

I suppose there should be a logging of that message, but it needs to pass that regex.

@kradalby commented on GitHub (Jan 9, 2025): I suppose there should be a logging of that message, but it needs to pass that regex.
adam commented 2025-12-29 02:25:37 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Jan 10, 2025):

What is the username not passing the regex, out of curiosity?

@kradalby commented on GitHub (Jan 10, 2025): What is the username not passing the regex, out of curiosity?
adam commented 2025-12-29 02:25:38 +01:00
Author
Owner
Copy Link

@ToxicMushroom commented on GitHub (Jan 10, 2025):

What is the username not passing the regex, out of curiosity?

merlijn@idm.melijn.com

I'm curious where the regex comes from tho, what purpose does it serve ?
But kanidm has the option to send the username without the domain part too so I'll configure it to do that.

@ToxicMushroom commented on GitHub (Jan 10, 2025): > What is the username not passing the regex, out of curiosity? `merlijn@idm.melijn.com` I'm curious where the regex comes from tho, what purpose does it serve ? But kanidm has the option to send the username without the domain part too so I'll configure it to do that.
adam commented 2025-12-29 02:25:38 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Jan 10, 2025):

historically it comes from when our magicdns implementation used the username, so it validates that it is DNS safe. Since this has been removed, it can be removed, I am just a bit cautious opening it completely yet, so keeping it strict initially and being conservative atm feels the best.

Allowing @ would be sensible tho, so I'll update the PR to allow that.

@kradalby commented on GitHub (Jan 10, 2025): historically it comes from when our magicdns implementation used the username, so it validates that it is DNS safe. Since this has been removed, it can be removed, I am just a bit cautious opening it completely yet, so keeping it strict initially and being conservative atm feels the best. Allowing @ would be sensible tho, so I'll update the PR to allow that.
adam commented 2025-12-29 02:25:38 +01:00
Author
Owner
Copy Link

@ToxicMushroom commented on GitHub (Jan 10, 2025):

ooh then it makes sense yeah :)

@ToxicMushroom commented on GitHub (Jan 10, 2025): ooh then it makes sense yeah :)
adam commented 2025-12-29 02:25:38 +01:00
Author
Owner
Copy Link

@suyashFSG commented on GitHub (Jan 18, 2025):

Hey @kradalby I am on v24.0 with AzureAD as OIDC provider and I am noticing that provider id is url instead of preferred_username

/ # headscale users list -o json
[
        {
                "id": 1,
                "created_at": {
                        "seconds": 1737170088,
                        "nanos": 221403948
                },
                "display_name": "FirstName LastName",
                "provider_id": "https://login.microsoftonline.com/<tenant-id>/v2.0/I-70OQnj3TogrNSfkZQqB3f7dGwyBWSm1dolHNKrMzQ",
                "provider": "oidc"
        }
]

On v23.0 headscale users list -o json outputs:

[
        {
                "id": "2",
                "name": "username_from_email",
                "created_at": {
                        "seconds": 1737172102,
                        "nanos": 212477758
                }
        }
]

v24.0 causes Tailscale client to show the url instead of username

@suyashFSG commented on GitHub (Jan 18, 2025): Hey @kradalby I am on v24.0 with AzureAD as OIDC provider and I am noticing that provider id is url instead of preferred_username ``` / # headscale users list -o json [ { "id": 1, "created_at": { "seconds": 1737170088, "nanos": 221403948 }, "display_name": "FirstName LastName", "provider_id": "https://login.microsoftonline.com/<tenant-id>/v2.0/I-70OQnj3TogrNSfkZQqB3f7dGwyBWSm1dolHNKrMzQ", "provider": "oidc" } ] ``` On v23.0 `headscale users list -o json` outputs: ``` [ { "id": "2", "name": "username_from_email", "created_at": { "seconds": 1737172102, "nanos": 212477758 } } ] ``` v24.0 causes Tailscale client to show the url instead of username
adam commented 2025-12-29 02:25:38 +01:00
Author
Owner
Copy Link

@suyashFSG commented on GitHub (Jan 18, 2025):

Tailscale client shows provider_id as well instead of name or display_name

Image

@suyashFSG commented on GitHub (Jan 18, 2025): Tailscale client shows `provider_id` as well instead of `name` or `display_name` ![Image](https://github.com/user-attachments/assets/dd9f3ad5-b71d-4a9e-9ec1-d512d8675282)
adam commented 2025-12-29 02:25:39 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Jan 19, 2025):

@suyashFSG

This happens when preferred username is not valid, and the email is not verified.

Can you send the OIDC claims json sent from azure? I don't have azure so I don't know what they send. Likely there is no username or it contains a invalid character and the email is not marked as verified.

The provider id looks as i expect it, and it would show up in the UI if there is nothing else.

@kradalby commented on GitHub (Jan 19, 2025): @suyashFSG This happens when preferred username is not valid, and the email is not verified. Can you send the OIDC claims json sent from azure? I don't have azure so I don't know what they send. Likely there is no username or it contains a invalid character and the email is not marked as verified. The provider id looks as i expect it, and it would show up in the UI if there is nothing else.
adam commented 2025-12-29 02:25:39 +01:00
Author
Owner
Copy Link

@malonzhao commented on GitHub (Jan 20, 2025):

Hi @kradalby, I meet the same problem that users don't always get a username and picture. I use keycloak as OIDC provider.

User's data in postgres.
Image

# headscale users list -o json
[
	{
		"id": 1,
		"created_at": {
			"seconds": 1737342473,
			"nanos": 327810000
		},
		"display_name": "Test System",
		"email": "test.system@example.org",
		"provider_id": "https://auth.example.org/realms/vpn/41a17f0c-4dab-4ed1-e409-62ea8b511476",
		"provider": "oidc"
	}
]

# config.yaml
...
oidc:
  only_start_if_oidc_is_available: true
  issuer: "https://auth.example.org/realms/vpn"
  client_id: "41a17f0c-4dab-4ed1-e409-62ea8b511476" #"gennerate client-id randly"
  client_secret: "MNOIfAQjezzZ5WbLraDzQf2iUTDJYaOO"
  #client_secret_path: "${CREDENTIALS_DIRECTORY}/oidc_client_secret"
  expiry: "180d"
  use_expiry_from_token: false
  scope: ["openid", "email", "groups", "profile"]
  extra_params:
    domain_hint: "auth.example.org"
  allowed_domains:
    - "example.org"
  allowed_groups: 
    - "/headscale"
  allowed_users: []
  pkce:
    enabled: true
    method: "S256"
...
@malonzhao commented on GitHub (Jan 20, 2025): Hi @kradalby, I meet the same problem that users don't always get a username and picture. I use keycloak as OIDC provider. User's data in postgres. <img width="1127" alt="Image" src="https://github.com/user-attachments/assets/dae831c4-0203-472b-baca-f0b5ef60dd8b" /> ``` # headscale users list -o json [ { "id": 1, "created_at": { "seconds": 1737342473, "nanos": 327810000 }, "display_name": "Test System", "email": "test.system@example.org", "provider_id": "https://auth.example.org/realms/vpn/41a17f0c-4dab-4ed1-e409-62ea8b511476", "provider": "oidc" } ] ``` ``` # config.yaml ... oidc: only_start_if_oidc_is_available: true issuer: "https://auth.example.org/realms/vpn" client_id: "41a17f0c-4dab-4ed1-e409-62ea8b511476" #"gennerate client-id randly" client_secret: "MNOIfAQjezzZ5WbLraDzQf2iUTDJYaOO" #client_secret_path: "${CREDENTIALS_DIRECTORY}/oidc_client_secret" expiry: "180d" use_expiry_from_token: false scope: ["openid", "email", "groups", "profile"] extra_params: domain_hint: "auth.example.org" allowed_domains: - "example.org" allowed_groups: - "/headscale" allowed_users: [] pkce: enabled: true method: "S256" ... ```
adam commented 2025-12-29 02:25:39 +01:00
Author
Owner
Copy Link

@suyashFSG commented on GitHub (Jan 20, 2025):

@kradalby Following is the accessToken returned by AzureAD:

{
  "aud": "00000003-0000-0000-c000-000000000000",
  "iss": "https://sts.windows.net/45xxxxxx-xxxx-xxxx-xxxx-326febxxxxxx/",
  "iat": 1737345412,
  "nbf": 1737345412,
  "exp": 1737349485,
  "acct": 0,
  "acr": "1",
  "": "AVQAq/8ZAAAA26OpiferaAOn10xxxxxxxxxxxxcC577BwI3kXwN0Gp4lET4IxWV3xxxxxxxxxxxx0dfCxqp+11zhIie12aWHjXVxtEDFBe4YISI0/YMo75I=",
  "amr": [
    "pwd",
    "mfa"
  ],
  "app_displayname": "Headscale",
  "appid": "79xxxxx-xxxx-xxxx-xxxx-892146xxxxxx",
  "appidacr": "1",
  "family_name": "XXXX",
  "given_name": "XXXXXX",
  "idtyp": "user",
  "ipaddr": "XX.175.110.XX",
  "name": "XXXX XXXX",
  "oid": "54xxxxxx-xxxx-xxxx-xxxx-ad7519xxxxxx",
  "platf": "3",
  "puid": "10032001D6AD2FE2",
  "rh": "1.AXUAXdg0Rfc11UifLDJv67ChfQMAAAAAAAAAwAAAAAAAAABcAQl1AA.",
  "scp": "email openid profile User.Read",
  "sid": "a94892b2-3ba9-4788-bef1-aa0b669be945",
  "sub": "MvKiiQxN35I2v4nx5MHMo4ChReGZXEYE51mWxcnuJmo",
  "tenant_region_scope": "NA",
  "tid": "4534d85d-35f7-48d5-9f2c-326febb0a17d",
  "unique_name": "user@domain.com",
  "upn": "user@domain.com",
  "uti": "OHp9JXrnyEibojjJSrIRAA",
  "ver": "1.0",
  "wids": [
    "62xxxxxx-xxxx-xxxx-xxxx-012177xxxxxx",
    "cfxxxxxx-xxxx-xxxx-xxxx-879624xxxxxx",
    "b7xxxxxx-xxxx-xxxx-xxxx-76b194xxxxxx"
  ],
  "xms_ftd": "UWEf3I8CHZ3xxxxxxxxx7Gow9xxxxxxxxxfmpVqactM",
  "xms_idrel": "1 6",
  "xms_st": {
    "sub": "I-70OQnj3TogrNSfkZQqB3f7dGwyBWSm1dolHNKrMzQ"
  },
  "xms_tcdt": 1602020081
}

Something I am noticing AzureAD does not include preferred_username in accesstoken and as for email_verified claim they are not included either.

ID Token includes preferred_username:

{
  "aud": "79xxxxxx-xxxx-xxxx-xxxx-892146xxxxxx",
  "iss": "https://login.microsoftonline.com//v2.0",
  "iat": 1737346441,
  "nbf": 1737346441,
  "exp": 1737350341,
  "aio": "AWQAm/8ZAAAABKne9EWr6ygVO2DbcRmoPIpRM819qqlP/mmK41AAWv/C2tVkld4+znbG8DaXFdLQa9jRUzokvsT7rt9nAT6Fg7QC+/ecDWsF5U+QX11f9Ox7ZkK4UAIWFcIXpuZZvRS7",
  "email": "user@domain.com",
  "name": "XXXXXX XXXX",
  "oid": "54c2323d-5052-4130-9588-ad751909003f",
  "preferred_username": "user@domain.com",
  "rh": "1.AXUAXdg0Rfc11UifLDJv67ChfSluoXmD9z1EmK-JIUYuSK9cAQl1AA.",
  "sid": "5250a0a2-0b4e-4e68-8652-b4e97866411d",
  "sub": "I-70OQnj3TogrNSfkZQqB3f7dGwyBWSm1dolHNKrMzQ",
  "tid": "<redacted>",
  "uti": "zAuXeEtMM0GwcTAcOsBZAA",
  "ver": "2.0"
}
@suyashFSG commented on GitHub (Jan 20, 2025): @kradalby Following is the accessToken returned by AzureAD: ``` { "aud": "00000003-0000-0000-c000-000000000000", "iss": "https://sts.windows.net/45xxxxxx-xxxx-xxxx-xxxx-326febxxxxxx/", "iat": 1737345412, "nbf": 1737345412, "exp": 1737349485, "acct": 0, "acr": "1", "": "AVQAq/8ZAAAA26OpiferaAOn10xxxxxxxxxxxxcC577BwI3kXwN0Gp4lET4IxWV3xxxxxxxxxxxx0dfCxqp+11zhIie12aWHjXVxtEDFBe4YISI0/YMo75I=", "amr": [ "pwd", "mfa" ], "app_displayname": "Headscale", "appid": "79xxxxx-xxxx-xxxx-xxxx-892146xxxxxx", "appidacr": "1", "family_name": "XXXX", "given_name": "XXXXXX", "idtyp": "user", "ipaddr": "XX.175.110.XX", "name": "XXXX XXXX", "oid": "54xxxxxx-xxxx-xxxx-xxxx-ad7519xxxxxx", "platf": "3", "puid": "10032001D6AD2FE2", "rh": "1.AXUAXdg0Rfc11UifLDJv67ChfQMAAAAAAAAAwAAAAAAAAABcAQl1AA.", "scp": "email openid profile User.Read", "sid": "a94892b2-3ba9-4788-bef1-aa0b669be945", "sub": "MvKiiQxN35I2v4nx5MHMo4ChReGZXEYE51mWxcnuJmo", "tenant_region_scope": "NA", "tid": "4534d85d-35f7-48d5-9f2c-326febb0a17d", "unique_name": "user@domain.com", "upn": "user@domain.com", "uti": "OHp9JXrnyEibojjJSrIRAA", "ver": "1.0", "wids": [ "62xxxxxx-xxxx-xxxx-xxxx-012177xxxxxx", "cfxxxxxx-xxxx-xxxx-xxxx-879624xxxxxx", "b7xxxxxx-xxxx-xxxx-xxxx-76b194xxxxxx" ], "xms_ftd": "UWEf3I8CHZ3xxxxxxxxx7Gow9xxxxxxxxxfmpVqactM", "xms_idrel": "1 6", "xms_st": { "sub": "I-70OQnj3TogrNSfkZQqB3f7dGwyBWSm1dolHNKrMzQ" }, "xms_tcdt": 1602020081 } ``` Something I am noticing AzureAD does not include `preferred_username` in accesstoken and as for `email_verified` claim they are not included either. ID Token includes preferred_username: ``` { "aud": "79xxxxxx-xxxx-xxxx-xxxx-892146xxxxxx", "iss": "https://login.microsoftonline.com//v2.0", "iat": 1737346441, "nbf": 1737346441, "exp": 1737350341, "aio": "AWQAm/8ZAAAABKne9EWr6ygVO2DbcRmoPIpRM819qqlP/mmK41AAWv/C2tVkld4+znbG8DaXFdLQa9jRUzokvsT7rt9nAT6Fg7QC+/ecDWsF5U+QX11f9Ox7ZkK4UAIWFcIXpuZZvRS7", "email": "user@domain.com", "name": "XXXXXX XXXX", "oid": "54c2323d-5052-4130-9588-ad751909003f", "preferred_username": "user@domain.com", "rh": "1.AXUAXdg0Rfc11UifLDJv67ChfSluoXmD9z1EmK-JIUYuSK9cAQl1AA.", "sid": "5250a0a2-0b4e-4e68-8652-b4e97866411d", "sub": "I-70OQnj3TogrNSfkZQqB3f7dGwyBWSm1dolHNKrMzQ", "tid": "<redacted>", "uti": "zAuXeEtMM0GwcTAcOsBZAA", "ver": "2.0" } ```
adam commented 2025-12-29 02:25:39 +01:00
Author
Owner
Copy Link

@GoodiesHQ commented on GitHub (Jan 20, 2025):

@suyashFSG how were you able to pull that information? headscale in debug mode? I am getting this same behavior with Azure. Even if I go add a username to the OIDC user (which has a blank user name and email), the username is ineffectual inside of ACLs. If I use the entire providerId URL in the ACL, it actually works, but is horrendously ugly.

@GoodiesHQ commented on GitHub (Jan 20, 2025): @suyashFSG how were you able to pull that information? headscale in debug mode? I am getting this same behavior with Azure. Even if I go add a username to the OIDC user (which has a blank user name and email), the username is ineffectual inside of ACLs. If I use the entire providerId URL in the ACL, it actually works, but is horrendously ugly.
adam commented 2025-12-29 02:25:40 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Jan 20, 2025):

I meet the same problem that users don't always get a username and picture. I use keycloak as OIDC provider.

@malonzhao please provide the ID Token JSON, I would not expect profile picture to be included in most OIDC, I would assume that your keycloak does not provide preferred_username.

ID Token includes preferred_username:

@suyashFSG I find it strange that the username is not included as the email for the ID Token one, but as the email is not verified, it will not be recorded. You need to get Azure to set the email_verified field.

I am also confused by the first payload you are showing, is that from a different system? are both AzureAD?

Please not that we do not aim to support all the quirks of all the different providers, we are aiming to support the base case, if your provider doesnt provide those fields, we likely wont be able to maintain it.

@kradalby commented on GitHub (Jan 20, 2025): > I meet the same problem that users don't always get a username and picture. I use keycloak as OIDC provider. @malonzhao please provide the ID Token JSON, I would not expect profile picture to be included in most OIDC, I would assume that your keycloak does not provide `preferred_username`. > ID Token includes preferred_username: @suyashFSG I find it strange that the username is not included as the email for the ID Token one, but as the email is not verified, it will not be recorded. You need to get Azure to set the `email_verified` field. I am also confused by the first payload you are showing, is that from a different system? are both AzureAD? Please not that we do not aim to support all the quirks of all the different providers, we are aiming to support the base case, if your provider doesnt provide those fields, we likely wont be able to maintain it.
adam commented 2025-12-29 02:25:40 +01:00
Author
Owner
Copy Link

@malonzhao commented on GitHub (Jan 20, 2025):

Thanks @kradalby , I think I've found the way to resolve this problem.

During debugging, I got a tip like "DBG Username service.system is not valid error="username contains invalid character: '.'".

I will try again after removing the "." character from the username

@malonzhao commented on GitHub (Jan 20, 2025): Thanks @kradalby , I think I've found the way to resolve this problem. During debugging, I got a tip like "DBG Username service.system is not valid error="username contains invalid character: '.'". I will try again after removing the "." character from the username
adam commented 2025-12-29 02:25:40 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Jan 20, 2025):

That is probably a bit strict, I will go over and ensure typical username chars are supported in a upcoming fix release: ., _, - and @ (already handled)

@kradalby commented on GitHub (Jan 20, 2025): That is probably a bit strict, I will go over and ensure typical username chars are supported in a upcoming fix release: `.`, `_`, `-` and `@` (already handled)
adam commented 2025-12-29 02:25:40 +01:00
Author
Owner
Copy Link

@suyashFSG commented on GitHub (Jan 20, 2025):

@kradalby Azure does not have option to add email_verified claim. A lot of apps that i have deployed that has OIDC support for both personal or enterprise lets us admins decide what claim we want to use for specific things.
What was the reason behind making the oidc config very restrictive on headscale. It would be awesome if claim override is an option for username, same with disabling email verified stuff.

I am also confused by the first payload you are showing, is that from a different system? are both AzureAD?

Both id token and access token are from same instance of azure and azure app. Azure provide 2 auth tokens when you request one (access an id tokens)

One more question, does headscale use access token or id token or combination of both?

@suyashFSG commented on GitHub (Jan 20, 2025): @kradalby Azure does not have option to add [email_verified claim](https://learn.microsoft.com/en-us/answers/questions/812672/microsoft-openid-connect-getting-verified-email). A lot of apps that i have deployed that has OIDC support for both personal or enterprise lets us admins decide what claim we want to use for specific things. What was the reason behind making the oidc config very restrictive on headscale. It would be awesome if claim override is an option for username, same with disabling email verified stuff. > I am also confused by the first payload you are showing, is that from a different system? are both AzureAD? Both id token and access token are from same instance of azure and azure app. Azure provide 2 auth tokens when you request one (access an id tokens) One more question, does headscale use access token or id token or combination of both?
adam commented 2025-12-29 02:25:41 +01:00
Author
Owner
Copy Link

@SamyDjemai commented on GitHub (Jan 21, 2025):

Hi @kradalby,

The v0.24 release breaks Headscale when used with an Okta OIDC integration, since:

As @suyashFSG mentioned, it would be best to be able to disable email_verified checking, for the OIDC providers who either don't provide it, or provide it unreliably

@SamyDjemai commented on GitHub (Jan 21, 2025): Hi @kradalby, The v0.24 release breaks Headscale when used with an Okta OIDC integration, since: - [email_verified is not a part of the User model within Okta](https://devforum.okta.com/t/get-email-verified-field-from-users-id-endpoint/24155/3) - our `preferred_username` field contains the user's email address, which contain some of the forbidden characters you mentioned (example: `firstname.lastname@company.com`) As @suyashFSG mentioned, it would be best to be able to disable `email_verified` checking, for the OIDC providers who either don't provide it, or provide it unreliably
adam commented 2025-12-29 02:25:41 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Jan 21, 2025):

Noted, please provide an example json payload from your okta, you can anonymise it a bit but preferably as normal as possible so I can write tests against it.

We will per now at least relax the username field, email is undecided.

@kradalby commented on GitHub (Jan 21, 2025): Noted, please provide an example json payload from your okta, you can anonymise it a bit but preferably as normal as possible so I can write tests against it. We will per now at least relax the username field, email is undecided.
adam commented 2025-12-29 02:25:41 +01:00
Author
Owner
Copy Link

@SamyDjemai commented on GitHub (Jan 21, 2025):

Here's the ID token:

{
  "sub": "00u7dr4qp7XXXXXXXXXX",
  "name": "Samy Djemai",
  "email": "samy.djemai@company.com",
  "ver": 1,
  "iss": "https://sso.company.com/oauth2/default",
  "aud": "0oa8neto4tXXXXXXXXXX",
  "iat": 1737455152,
  "exp": 1737458752,
  "jti": "ID.zzJz93koTunMKv5Bq-XXXXXXXXXXXXXXXXXXXXXXXXX",
  "amr": [
    "pwd"
  ],
  "idp": "00o42r3s2cXXXXXXXX",
  "nonce": "nonce",
  "preferred_username": "samy.djemai@company.com",
  "auth_time": 1000,
  "at_hash": "preview_at_hash"
}
@SamyDjemai commented on GitHub (Jan 21, 2025): Here's the ID token: ```json { "sub": "00u7dr4qp7XXXXXXXXXX", "name": "Samy Djemai", "email": "samy.djemai@company.com", "ver": 1, "iss": "https://sso.company.com/oauth2/default", "aud": "0oa8neto4tXXXXXXXXXX", "iat": 1737455152, "exp": 1737458752, "jti": "ID.zzJz93koTunMKv5Bq-XXXXXXXXXXXXXXXXXXXXXXXXX", "amr": [ "pwd" ], "idp": "00o42r3s2cXXXXXXXX", "nonce": "nonce", "preferred_username": "samy.djemai@company.com", "auth_time": 1000, "at_hash": "preview_at_hash" } ```
adam commented 2025-12-29 02:25:41 +01:00
Author
Owner
Copy Link

@Codelica commented on GitHub (Jan 23, 2025):

I see this was part of the release today (v0.24.1), but it seems one regex is still restricting email addresses for me:

# headscale version
v0.24.1

# headscale users rename --identifier 1 --new-name 'first.last@domain.com'
Cannot rename user: DNS segment should only be composed of lowercase ASCII letters numbers, hyphen and dots. first.last@domain.com doesn't comply with theses rules: invalid user name

# headscale users rename --identifier 1 --new-name 'first.lastdomain.com'
User renamed

It seem like it's getting hung up on the @ during the invalidCharsInUserRegex check ?

@Codelica commented on GitHub (Jan 23, 2025): I see this was part of the release today (v0.24.1), but it seems one regex is still restricting email addresses for me: ``` # headscale version v0.24.1 # headscale users rename --identifier 1 --new-name 'first.last@domain.com' Cannot rename user: DNS segment should only be composed of lowercase ASCII letters numbers, hyphen and dots. first.last@domain.com doesn't comply with theses rules: invalid user name # headscale users rename --identifier 1 --new-name 'first.lastdomain.com' User renamed ``` It seem like it's getting hung up on the `@` during the `invalidCharsInUserRegex` [check](https://github.com/kradalby/headscale/blob/adc084f20f843d7963c999764fa83939668d2d2c/hscontrol/util/dns.go#L24) ?
adam commented 2025-12-29 02:25:41 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Jan 23, 2025):

This regex is not being used, https://github.com/juanfont/headscale/blob/main/hscontrol/util/dns.go#L34 this function is validating it.

Currently this is the passing tests:
https://github.com/juanfont/headscale/blob/main/hscontrol/types/users_test.go#L79 which includes an email on that format.

@kradalby commented on GitHub (Jan 23, 2025): This regex is not being used, https://github.com/juanfont/headscale/blob/main/hscontrol/util/dns.go#L34 this function is validating it. Currently this is the passing tests: https://github.com/juanfont/headscale/blob/main/hscontrol/types/users_test.go#L79 which includes an email on that format.
adam commented 2025-12-29 02:25:41 +01:00
Author
Owner
Copy Link

@Codelica commented on GitHub (Jan 23, 2025):

But on rename user I think that regex is checked, no ?

@Codelica commented on GitHub (Jan 23, 2025): But on _rename_ user I think that regex is [checked](https://github.com/kradalby/headscale/blob/adc084f20f843d7963c999764fa83939668d2d2c/hscontrol/db/users.go#L97), no ?
adam commented 2025-12-29 02:25:42 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Jan 23, 2025):

oh yes, that should be an easy fix, if someone can take a look at that it would be greatly appreciated.

@kradalby commented on GitHub (Jan 23, 2025): oh yes, that should be an easy fix, if someone can take a look at that it would be greatly appreciated.
adam commented 2025-12-29 02:25:42 +01:00
Author
Owner
Copy Link

@n-hass commented on GitHub (Feb 3, 2025):

I don’t believe this is resolved on latest v0.24.2.

if a new user logs in from Google oauth using name@company.com.au, the user created is missing the ‘username’ field.

Output of headscale users ls -o json:

        {
                "id": 5,
                "created_at": {
                        "seconds": 1738545231,
                        "nanos": 419871190
                },
                "display_name": “Some Full Name",
                "email": “team@company.com.au",
                "provider_id": "https://accounts.google.com/123456789",
                "provider": "oidc",
                "profile_pic_url": "https://lh3.googleusercontent.com/a/abcdef"
        }

then trying headscale users rename -i 5 -r team@company.com.au results in: Cannot rename user: DNS segment should only be composed of lowercase ASCII letters numbers, hyphen and dots. team@company.com.au doesn't comply with theses rules: invalid user name, and the user is unchanged.

@n-hass commented on GitHub (Feb 3, 2025): I don’t believe this is resolved on latest v0.24.2. if a new user logs in from Google oauth using `name@company.com.au`, the user created is missing the ‘username’ field. Output of `headscale users ls -o json`: ``` { "id": 5, "created_at": { "seconds": 1738545231, "nanos": 419871190 }, "display_name": “Some Full Name", "email": “team@company.com.au", "provider_id": "https://accounts.google.com/123456789", "provider": "oidc", "profile_pic_url": "https://lh3.googleusercontent.com/a/abcdef" } ``` then trying `headscale users rename -i 5 -r team@company.com.au` results in: `Cannot rename user: DNS segment should only be composed of lowercase ASCII letters numbers, hyphen and dots. team@company.com.au doesn't comply with theses rules: invalid user name`, and the user is unchanged.
adam commented 2025-12-29 02:25:42 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Feb 3, 2025):

I don’t believe this is resolved on latest v0.24.2.

if a new user logs in from Google oauth using name@company.com.au, the user created is missing the ‘username’ field.

Google doesn’t provide a username, so it will be blank, you have to use the value assigned to the email for things like acl

then trying headscale users rename -i 5 -r team@company.com.au results in: Cannot rename user: DNS segment should only be composed of lowercase ASCII letters numbers, hyphen and dots. team@company.com.au doesn't comply with theses rules: invalid user name, and the user is unchanged.

You should not try to modify users managed by oidc as they will be overwritten on every login, this has been disabled for the next release.

@kradalby commented on GitHub (Feb 3, 2025): > I don’t believe this is resolved on latest v0.24.2. > > if a new user logs in from Google oauth using `name@company.com.au`, the user created is missing the ‘username’ field. Google doesn’t provide a username, so it will be blank, you have to use the value assigned to the email for things like acl > then trying `headscale users rename -i 5 -r team@company.com.au` results in: `Cannot rename user: DNS segment should only be composed of lowercase ASCII letters numbers, hyphen and dots. team@company.com.au doesn't comply with theses rules: invalid user name`, and the user is unchanged. You should not try to modify users managed by oidc as they will be overwritten on every login, this has been disabled for the next release.
adam commented 2025-12-29 02:25:42 +01:00
Author
Owner
Copy Link

@n-hass commented on GitHub (Feb 3, 2025):

Thank you for the clarification @kradalby, the usage regarding ACLs was my concern as I had thought it is strictly a username that needs to be used in ACLs.

@n-hass commented on GitHub (Feb 3, 2025): Thank you for the clarification @kradalby, the usage regarding ACLs was my concern as I had thought it is strictly a username that needs to be used in ACLs.
adam commented 2025-12-29 02:25:42 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Feb 3, 2025):

That’s fair. We are working on the docs, but it will resolve in the order of unique id from oidc, email then username.

@kradalby commented on GitHub (Feb 3, 2025): That’s fair. We are working on the docs, but it will resolve in the order of unique id from oidc, email then username.
adam commented 2025-12-29 02:25:43 +01:00
Author
Owner
Copy Link

@vdovhanych commented on GitHub (Feb 12, 2025):

Hey sorry to revive this closed issue. I have a question on this. When i update from 0.23.0 to 0.24.3 and want to do the migration do i also need to change the ACL rules to the email address instead of usernames if i use Google oidc and it does not provide the username property?

Will this mean that if i update my ACL the user won't have access until they go trough the new OIDC flow? Cause i will change it to the email property but user wont have it until he reauthenticates with oidc right?

@vdovhanych commented on GitHub (Feb 12, 2025): Hey sorry to revive this closed issue. I have a question on this. When i update from 0.23.0 to 0.24.3 and want to do the migration do i also need to change the ACL rules to the email address instead of usernames if i use Google oidc and it does not provide the username property? Will this mean that if i update my ACL the user won't have access until they go trough the new OIDC flow? Cause i will change it to the email property but user wont have it until he reauthenticates with oidc right?
adam commented 2025-12-29 02:25:43 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Feb 12, 2025):

Technically yes, but also there should not be a problem listing both username and email for a bit, not tested but think it could work

@kradalby commented on GitHub (Feb 12, 2025): Technically yes, but also there should not be a problem listing both username and email for a bit, not tested but think it could work
adam commented 2025-12-29 02:25:43 +01:00
Author
Owner
Copy Link

@ssentanoe commented on GitHub (Feb 13, 2025):

hi, similar with the previous question, since I'm also using google oidc which will produce blank on the username, do you have plan to update the nodes ls to also print the email? right now it is super hard to find nodes that belongs to a user that does not have username.

Edit:
I saw there is also -u, however it does not work with email

@ssentanoe commented on GitHub (Feb 13, 2025): hi, similar with the previous question, since I'm also using google oidc which will produce blank on the username, do you have plan to update the `nodes ls` to also print the email? right now it is super hard to find nodes that belongs to a user that does not have username. Edit: I saw there is also `-u`, however it does not work with email
adam commented 2025-12-29 02:25:43 +01:00
Author
Owner
Copy Link

@vdovhanych commented on GitHub (Feb 18, 2025):

Technically yes, but also there should not be a problem listing both username and email for a bit, not tested but think it could work

I just want to confirm that this approach works. For now, I will list both types of usernames and emails in the ACL until they all go through the new authentication flow. Thanks for the suggestion.

@vdovhanych commented on GitHub (Feb 18, 2025): > Technically yes, but also there should not be a problem listing both username and email for a bit, not tested but think it could work I just want to confirm that this approach works. For now, I will list both types of usernames and emails in the ACL until they all go through the new authentication flow. Thanks for the suggestion.
adam commented 2025-12-29 02:25:43 +01:00
Author
Owner
Copy Link

@Eric-ZhehanZ commented on GitHub (Mar 4, 2025):

How do I create a preauth key for email-only users? It doesn't seem to be possible right now.

@Eric-ZhehanZ commented on GitHub (Mar 4, 2025): How do I create a preauth key for email-only users? It doesn't seem to be possible right now.
adam commented 2025-12-29 02:25:43 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Mar 4, 2025):

How do I create a preauth key for email-only users? It doesn't seem to be possible right now.

Good point, can you create a new issue so we can track the effort to move everything to ID in the cli.

@kradalby commented on GitHub (Mar 4, 2025): > How do I create a preauth key for email-only users? It doesn't seem to be possible right now. Good point, can you create a new issue so we can track the effort to move everything to ID in the cli.
adam commented 2025-12-29 02:25:43 +01:00
Author
Owner
Copy Link

@seeleclover commented on GitHub (Mar 13, 2025):

Hey sorry to revive this closed issue. I am currently using Headscale v0.25.1 version, but I still encounter the issue of OIDC users don‘t get a username.

Environment

- OS: Debian 12
- Headscale version: ghcr.io/juanfont/headscale:0.25.1
- Tailscale version: 1.80.2
- OIDC provider: Casdoor

config.yaml of Headscale

oidc:
  only_start_if_oidc_is_available: true
  issuer: "https://oidc.example.com"
  client_id: "xxxxxxxx"
  client_secret: "xxxxxxxxxxxxxxxx"

  expiry: 180d

  use_expiry_from_token: false

  scope: ["openid", "profile", "email", "groups"]
  extra_params:
    response_type: code

oidc claims (accessToken returned by Casdoor)

{
  "sub": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "iss": "https://oidc.example.com/",
  "aud": "xxxxxxxxxxxx",
  "preferred_username": "user001",
  "name": "User001",
  "email": "user001@example.com",
  "email_verified": true,
  "picture": "https://cdn.casbin.org/img/casbin.svg",
  "groups": [
    "org1/department1",
    "org1/department2"
  ]
}

headscale users list

root@kvm-xxx:~# docker exec headscale headscale users list --output json
[
        {
                "id": 3,
                "created_at": {
                        "seconds": 1741787046,
                        "nanos": 645001909
                },
                "display_name": "user001",
                "provider_id": "https://oidc.example.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
                "provider": "oidc"
        }
]
@seeleclover commented on GitHub (Mar 13, 2025): Hey sorry to revive this closed issue. I am currently using Headscale v0.25.1 version, but I still encounter the issue of OIDC users don‘t get a username. Environment ``` - OS: Debian 12 - Headscale version: ghcr.io/juanfont/headscale:0.25.1 - Tailscale version: 1.80.2 - OIDC provider: Casdoor ``` `config.yaml` of Headscale ``` oidc: only_start_if_oidc_is_available: true issuer: "https://oidc.example.com" client_id: "xxxxxxxx" client_secret: "xxxxxxxxxxxxxxxx" expiry: 180d use_expiry_from_token: false scope: ["openid", "profile", "email", "groups"] extra_params: response_type: code ``` oidc claims (accessToken returned by Casdoor) ``` { "sub": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "iss": "https://oidc.example.com/", "aud": "xxxxxxxxxxxx", "preferred_username": "user001", "name": "User001", "email": "user001@example.com", "email_verified": true, "picture": "https://cdn.casbin.org/img/casbin.svg", "groups": [ "org1/department1", "org1/department2" ] } ``` headscale users list ``` root@kvm-xxx:~# docker exec headscale headscale users list --output json [ { "id": 3, "created_at": { "seconds": 1741787046, "nanos": 645001909 }, "display_name": "user001", "provider_id": "https://oidc.example.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "provider": "oidc" } ] ```
adam commented 2025-12-29 02:25:44 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Mar 13, 2025):

I've added an additional test and it seem to work as expected, please have a look at https://github.com/juanfont/headscale/pull/2474

@kradalby commented on GitHub (Mar 13, 2025): I've added an additional test and it seem to work as expected, please have a look at https://github.com/juanfont/headscale/pull/2474
adam commented 2025-12-29 02:25:44 +01:00
Author
Owner
Copy Link

@DevOpsPop commented on GitHub (Mar 21, 2025):

I've added an additional test and it seem to work as expected, please have a look at #2474

Headscale v0.25.1
the same problem

{
                "id": 6,
                "created_at": {
                        "seconds": 1742557032,
                        "nanos": 529540665
                },
                "display_name": "test",
                "email": "test@gmail.com",
                "provider_id": "https://accounts.google.com/",
                "provider": "oidc",
                "profile_pic_url": "https://example"
        }

can't login in tailscale client
log:

2025-03-21T11:30:31Z DBG tags provided by policy authorised_tags=[] node.id=5 unauthorised_tags=[]
2025-03-21T11:30:38Z DBG Redirecting to https://accounts.google.com/o/oauth2/v2/auth?client_id=43.apps.googleusercontent.com&nonce=jzng2&redirect_uri=https%3A%2F%2Fheadscale.dev%3A443%2Foidc%2Fcallback&response_type=code&scope=openid+profile+email&state=xBo6uWn0ZVL5z for authentication
2025-03-21T11:30:39Z DBG Username  is not valid error="username must be at least 2 characters long"
2025-03-21T11:30:39Z ERR http internal server error error="could not register node: node not found in registration cache" code=500
2025-03-21T11:36:54Z DBG tags provided by policy authorised_tags=[] node.id=5 unauthorised_tags=[]
@DevOpsPop commented on GitHub (Mar 21, 2025): > I've added an additional test and it seem to work as expected, please have a look at [#2474](https://github.com/juanfont/headscale/pull/2474) `Headscale v0.25.1` the same problem ``` { "id": 6, "created_at": { "seconds": 1742557032, "nanos": 529540665 }, "display_name": "test", "email": "test@gmail.com", "provider_id": "https://accounts.google.com/", "provider": "oidc", "profile_pic_url": "https://example" } ``` can't login in tailscale client log: ``` 2025-03-21T11:30:31Z DBG tags provided by policy authorised_tags=[] node.id=5 unauthorised_tags=[] 2025-03-21T11:30:38Z DBG Redirecting to https://accounts.google.com/o/oauth2/v2/auth?client_id=43.apps.googleusercontent.com&nonce=jzng2&redirect_uri=https%3A%2F%2Fheadscale.dev%3A443%2Foidc%2Fcallback&response_type=code&scope=openid+profile+email&state=xBo6uWn0ZVL5z for authentication 2025-03-21T11:30:39Z DBG Username is not valid error="username must be at least 2 characters long" 2025-03-21T11:30:39Z ERR http internal server error error="could not register node: node not found in registration cache" code=500 2025-03-21T11:36:54Z DBG tags provided by policy authorised_tags=[] node.id=5 unauthorised_tags=[] ```
adam commented 2025-12-29 02:25:44 +01:00
Author
Owner
Copy Link

@idefixcert commented on GitHub (Apr 3, 2025):

I have the problem in google oauth:
scope: ["openid", "profile", "email"]
the prefered_username is not set

My question is if I could contribute the following change:
-> https://github.com/juanfont/headscale/compare/main...idefixcert:headscale:oidc_username

@idefixcert commented on GitHub (Apr 3, 2025): I have the problem in google oauth: scope: ["openid", "profile", "email"] the prefered_username is not set My question is if I could contribute the following change: -> https://github.com/juanfont/headscale/compare/main...idefixcert:headscale:oidc_username
adam commented 2025-12-29 02:25:44 +01:00
Author
Owner
Copy Link

@malosaaa commented on GitHub (May 9, 2025):

Is this already solved in the future beta ?

@malosaaa commented on GitHub (May 9, 2025): Is this already solved in the future beta ?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label OIDC bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#901
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?