[Bug] Internal server error when logging in using Google OIDC

[adriangoransson]

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

Similar to #2465 which was closed.

An existing (since Headscale 0.23) tried to log in for the first time since upgrading to 0.25, without success.

2025-03-13T08:09:14Z ERR http internal server error error="creating or updating user: constraint failed: UNIQUE constraint failed: users.name (2067)" code=500
2025-03-13T08:09:24Z ERR user msg: invalid code error="could not exchange code for token: oauth2: \"invalid_grant\" \"Bad Request\"" code=403
2025-03-13T08:09:34Z ERR http internal server error error="creating or updating user: constraint failed: UNIQUE constraint failed: users.name (2067)" code=500
2025-03-13T08:10:07Z ERR http internal server error error="creating or updating user: constraint failed: UNIQUE constraint failed: users.name (2067)" code=500
2025-03-13T08:11:07Z ERR http internal server error error="creating or updating user: constraint failed: UNIQUE constraint failed: users.name (2067)" code=500

Even after destroying the user (along with the associated nodes and preauthkeys) and restarting headscale, the issue persists.

I tried to investigate how the OIDC handling has changed over the versions, but from what I could gather most issues seem to stem from the email having possibly changed? This has not happened in our case.

Expected Behavior

The current user should be migrated to the new format.

Steps To Reproduce

1. Setup a user with Google OIDC on Headscale 0.23.0.
2. Migrate to 0.24 and then 0.25
3. Try to reauthenticate

Environment

- OS: macOS 15.3.1
- Headscale version: 0.25.1
- Tailscale version: 1.80.2

Runtime environment

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

Anything else?

# config.yaml

map_legacy_users: true

oidc:
  only_start_if_oidc_is_available: true
  issuer: https://accounts.google.com
  client_id: <redacted>
  client_secret_path: /secrets/headscale/oidc_client_secret

  expiry: 180d
  use_expiry_from_token: false

  scope: ["openid", "profile", "email"]
  extra_params:
    domain_hint: <redacted>

  allowed_domains:
    - <redacted>

  strip_email_domain: true

Thank you for your dedicated work on Headscale!

[kradalby]

Can you provide a list of users in the database and their fields and the ones that try to login when you get the error?

I suspect that they might not have migrated from the old "user only" format to the new one, see the changelog for 0.24.

[adriangoransson]

Can you provide a list of users in the database and their fields and the ones that try to login when you get the error?

I suspect that they might not have migrated from the old "user only" format to the new one, see the changelog for 0.24.

Sure, here you go!
User 1 is our subnet router configured as a non-OIDC user. User 15 is an ordinary OIDC user, just with a special email.

sqlite> select * from users;
id | created_at                          | updated_at                          | deleted_at | name             | display_name     | email                     | provider_identifier | provider | profile_pic_url
 1 | 2024-03-08 22:00:05.052505772+00:00 | 2024-03-08 22:00:05.052505772+00:00 |            | pod-node         |                  |                           |                     |          |
 2 | 2024-03-08 22:01:43.602676781+00:00 | 2025-03-13 10:04:41.871021878+00:00 |            | adrian.goransson | Adrian Göransson | adrian.goransson@<domain> | <id_1>              | oidc     | <url_2>
 4 | 2024-03-14 13:19:43.923617972+00:00 | 2024-03-14 13:19:43.923617972+00:00 |            | <first>.<last>   |                  |                           |                     |          |
 5 | 2024-03-15 15:43:18.872487023+00:00 | 2024-03-15 15:43:18.872487023+00:00 |            | <first>.<last>   |                  |                           |                     |          |
 7 | 2024-05-30 07:32:14.825899374+00:00 | 2024-05-30 07:32:14.825899374+00:00 |            | <first>.<last>   |                  |                           |                     |          |
 8 | 2024-07-15 11:11:48.313729614+00:00 | 2024-07-15 11:11:48.313729614+00:00 |            | <first>.<last>   |                  |                           |                     |          |
 9 | 2024-08-26 07:41:05.647379266+00:00 | 2024-08-26 07:41:05.647379266+00:00 |            | <first>.<last>   |                  |                           |                     |          |
10 | 2024-08-27 09:37:05.68427993+00:00  | 2024-08-27 09:37:05.68427993+00:00  |            | <first>.<last>   |                  |                           |                     |          |
11 | 2024-09-25 08:05:59.81951107+00:00  | 2024-09-25 08:05:59.81951107+00:00  |            | <first>.<last>   |                  |                           |                     |          |
12 | 2024-10-16 12:02:24.530535501+00:00 | 2024-10-16 12:02:24.530535501+00:00 |            | <first>.<last>   |                  |                           |                     |          |
13 | 2024-11-05 05:32:40.270709176+00:00 | 2024-11-05 05:32:40.270709176+00:00 |            | <first>.<last>   |                  |                           |                     |          |
14 | 2024-12-17 09:32:19.148077663+00:00 | 2024-12-17 09:32:19.148077663+00:00 |            | <first>.<last>   |                  |                           |                     |          |
15 | 2024-12-20 08:11:36.352191756+00:00 | 2024-12-20 08:11:36.352191756+00:00 |            | <custom>         |                  |                           |                     |          |
16 | 2025-02-10 09:43:41.061294411+00:00 | 2025-02-10 09:43:41.061294411+00:00 |            | <first>.<last>   |                  |                           |                     |          |
17 | 2025-03-11 08:36:14.999339636+00:00 | 2025-03-11 08:36:14.999339636+00:00 |            |                  | <first> <last>   | <first>.<last>@<domain>   | <id_2>              | oidc     | <url_2>

• My user seems to have been migrated correctly. I logged out and logged back in using the Tailscale client shortly after updating Headscale.
• Users 4-16 are OIDC, but haven't reauthenticated yet.
• User 17 used to be ID 3, but a new user was created upon reauthentication (after upgrading to 0.24 and then 0.25) so we destroyed the old one.

Note that the provider_identifier for me and user 17 are different. I don't know if they should be.

[adriangoransson]

Just tried two things:

Reauth

Reauthenticated user 4 (not that the id matters I guess 😅) and encountered an internal server error again.

2025-03-17T12:55:36Z INF home/runner/work/headscale/headscale/hscontrol/poll.go:634 > node has disconnected, mapSession: 0xc000564480, chan: 0xc0000af8f0 node=<name>s-MacBook-Pro node.id=9 omitPeers=false readOnly=false stream=true
2025-03-17T12:55:38Z ERR http internal server error error="creating or updating user: constraint failed: UNIQUE constraint failed: users.name (2067)" code=500

However, shutting down Tailscale and starting it again worked, so the previous key still seems valid. The output of headscale users list is unchanged, though I haven't verified the database.

2025-03-17T12:56:21Z INF home/runner/work/headscale/headscale/hscontrol/poll.go:634 > node has connected, mapSession: 0xc000003e00, chan: 0xc0000ae9a0 node=<name>s-MacBook-Pro node.id=9 omitPeers=false readOnly=false stream=true

Registered new user

Registered a user who has never logged in to Headscale previously. They have a unique first and last name, so there should be no such collisions.

2025-03-17T12:59:15Z ERR http internal server error error="creating or updating user: constraint failed: UNIQUE constraint failed: users.name (2067)" code=500
2025-03-17T12:59:23Z ERR user msg: invalid code error="could not exchange code for token: oauth2: \"invalid_grant\" \"Bad Request\"" code=403
2025-03-17T12:59:36Z ERR http internal server error error="creating or updating user: constraint failed: UNIQUE constraint failed: users.name (2067)" code=500```

[SeaweedbrainCY]

I have the same issue. Even adding new users is creating this behavior. Does anyone has any hint on this ? Any workaround ?
In this state, headscale 0.25 is just unusable

[SeaweedbrainCY]

For those having the same issue, I managed to solve the user creation error :

My issue was that even with the migration flag on, my users had a user.name empty,

> headscale users list
ID | Name    | Username          | Email                                 | Created
1  |         | <redacted>        |                                       | 2024-04-24 03:37:43
2  |         | <redacted>        |                                       | 2024-04-25 19:20:32
3  |         | <redacted>        |                                       | 2024-04-28 16:01:08
5  |         | <redacted>        |                                       | 2024-05-04 15:11:28
6  |         | <redacted>        |                                       | 2024-05-04 16:30:55
7  |         | <redacted>        |                                       | 2024-12-13 12:36:51

and most importantly, my OIDC provider was returning an empty username to headscale (I am using authelia).
The UNIQUE constraint were then failing on creating a new user with users.name equals to ''.

After digging into the code of headscale, I found that the name (in the DB) is mapped with the username sent by the OIDC provider. And after adjusting the scopes in authelia, allowing profile and username I managed to create a new user account, with a valid Name, a Username and Email.

Bottom line : Destroying and recreating user is possible, but you have to ensure that you're allowing headscale to fetch the user username to avoid duplication of empty value.

It's working for v0.24 and 0.25

[Subito]

I'm facing the same problem. I tried the solution mentioned in #2505: https://www.authelia.com/integration/openid-connect/openid-connect-1.0-claims/#restore-functionality-prior-to-claims-parameter, but using the claims_policy just gives me the same error. Not using the claims_policy lets me login, but without a proper username.

After the successful login the username field is empty and I get successfully authenticated as https://auth.example.org/{long-uid} in the app. Afterwards it shows this URL instead of the username and none of my other devices.

The resulting "user" in the table looks like this:

id  created_at                          updated_at                           deleted_at  name  display_name  email  provider_identifier                                           provider  profile_pic_url
--  ----------------------------------  -----------------------------------  ----------  ----  ------------  -----  ------------------------------------------------------------  --------  ---------------
12  2025-04-08 17:38:38.82871823+02:00  2025-04-08 17:42:38.837385594+02:00                                         https://auth.{redacted}/4735db7e-eaed-4722-a3da-44b9d65df5e3  oidc

None of the other users (all use oidc) have the provider-field set.

Using Authelia 4.39.1 and Headscale 0.25.1 might be related to #2516?