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 in user switching during OIDC authentication #539

New Issue
Closed
opened 2025-12-29 02:19:40 +01:00 by adam · 11 comments
adam commented 2025-12-29 02:19:40 +01:00
Owner
Copy Link

Originally created by @vsychov on GitHub (Aug 9, 2023).

Bug description

Hello,

I found an issue in headscale that seems like a bug to me.
As a user, I can't change the OIDC account I'm already authorized with. I'm trying to do it this way:

  1. login as user1
  2. logout, by: tailscale logout && tailscale down
  3. login as user2: tailscale up with the --login-server parameter. It redirects me to the OIDC authorization page (https://my-server.com/oidc/register/nodekey:XXXXXXX)

Upon successful authorization, I get an error in the web interface:
could not register machine, and in the app logs, there's also an error: ERR go/src/headscale/hscontrol/oidc.go:712 > could not register machine error="machine was previously registered with a different user"

The error seems to be here, where it's explicitly forbidden:
fb203a2e45/hscontrol/db/machine.go (L381-L386)

Originally created by @vsychov on GitHub (Aug 9, 2023). ## Bug description Hello, I found an issue in headscale that seems like a bug to me. As a user, I can't change the OIDC account I'm already authorized with. I'm trying to do it this way: 1. login as user1 2. logout, by: `tailscale logout && tailscale down` 3. login as user2: `tailscale up` with the `--login-server` parameter. It redirects me to the OIDC authorization page (`https://my-server.com/oidc/register/nodekey:XXXXXXX`) Upon successful authorization, I get an error in the web interface: `could not register machine`, and in the app logs, there's also an error: `ERR go/src/headscale/hscontrol/oidc.go:712 > could not register machine error="machine was previously registered with a different user"` The error seems to be here, where it's explicitly forbidden: https://github.com/juanfont/headscale/blob/fb203a2e454a9907d017ed3c61c7002ed3065977/hscontrol/db/machine.go#L381-L386
adam added the stalebugwell described ❤️ labels 2025-12-29 02:19:40 +01:00
adam closed this issue 2025-12-29 02:19:40 +01:00
adam commented 2025-12-29 02:19:41 +01:00
Author
Owner
Copy Link

@vsychov commented on GitHub (Aug 9, 2023):

@juanfont , @kradalby

@vsychov commented on GitHub (Aug 9, 2023): @juanfont , @kradalby
adam commented 2025-12-29 02:19:41 +01:00
Author
Owner
Copy Link

@vsychov commented on GitHub (Aug 14, 2023):

Same issue is #1310, bug was caused by changes from https://github.com/juanfont/headscale/pull/754

@vsychov commented on GitHub (Aug 14, 2023): Same issue is #1310, bug was caused by changes from https://github.com/juanfont/headscale/pull/754
adam commented 2025-12-29 02:19:41 +01:00
Author
Owner
Copy Link

@NetworkEngineer509 commented on GitHub (Sep 5, 2023):

Can confirm I am coming across this as well. I was just about to submit a bug report but came across this.

@NetworkEngineer509 commented on GitHub (Sep 5, 2023): Can confirm I am coming across this as well. I was just about to submit a bug report but came across this.
adam commented 2025-12-29 02:19:42 +01:00
Author
Owner
Copy Link

@micudaj commented on GitHub (Sep 21, 2023):

same for me. just had this as well

@micudaj commented on GitHub (Sep 21, 2023): same for me. just had this as well
adam commented 2025-12-29 02:19:42 +01:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Nov 15, 2023):

Any update on this?

@kolaente commented on GitHub (Nov 15, 2023): Any update on this?
adam commented 2025-12-29 02:19:42 +01:00
Author
Owner
Copy Link

@hannescl commented on GitHub (Nov 16, 2023):

This bug "hit" me as well yesterday...

@hannescl commented on GitHub (Nov 16, 2023): This bug "hit" me as well yesterday...
adam commented 2025-12-29 02:19:42 +01:00
Author
Owner
Copy Link

@benmehlman commented on GitHub (Mar 25, 2024):

I'm having a similar problem:

Headscale is installed and working (headscale v0.23.0-alpha5, on debian 12.4).

OIDC is set up using Google Workspace as the provider.
Connect tailscale client for linux, using my headscale server as the login-server. Copy/paste oidc url, authenticate as a google workspace user. Let's say "firstuser@mydomain.com". It authenticates successfully.

Install tailscale client for windows (1.6.2). Set registry values to point to my headscale server. Select Login from the tailscale client menu.. it does OIDC auth in the browser.. authenticate using SAME google user as before, it works.

Everything works as configured (nodes can see each other, subnet route works, and configured dns server is used).

(Amazing.. loving this.. thanks!).

Headscale shows two nodes up and one user, as expected.

Now I want to log out as my regular user and try logging in as a different user.. this is where the problem comes...
In the windows client, select my user.. then "Log out". It appears to log out and disconnect.

Tailscale prompts me to log in.. I click and the oidc page comes up. I select a DIFFERENT account in my workspace domain. I get the validation page from my headscale server "Reauthenticated as seconduser@mydomain.com, you can now close this window".

Open the tailscale for Windows menu.. it shows that I'm connected NOT as "seconduser" but as "firstuser".. and this is indicated by the headscale admin as well. I'm connected again, but not as the user that I selected (and that appeared on the "Signed in via your OIDC provider" page....

LMK of any solution.. Thanks!

EDIT: If I delete the node from headscale then it works.. I am able to login as a different user.

PS: While I'm here, I'd like make a related suggestion: In the oidc code, I see that if a user is not found in the headscale database, a new user is inserted. The problem with this is that Google Workspace does not seem to support groups via oidc (for now). So it's not possible to use allowed_groups to control who can authenticate with headscale, everyone in the domain can do it and a user record will be created.. the only way to prevent that is to add an entry for every user under allowed_users in config.yaml.

What I would like to see is:

  1. A new oidc setting "autocreate_user". If set to true, the behavior is the same as now. If set to false, a "user not found" will cause an error message to be returned to the authenticating browser.
  2. A new oidc setting "autocreate_user_enabled", If set to true, new autocreated users.. if allowed by above, will be active immediately and the authentication will succeed. If false, the user will be created, but authentication will fail until their enabled status is changed to true (via command line or API).
  3. An "enabled" column would need to be added to the user table to support this.

Thanks!

(If you are interested in patches I'll make one.. I don't know Go.. but I know a lot of other languages.. it doesn't look too hard....)

@benmehlman commented on GitHub (Mar 25, 2024): I'm having a similar problem: Headscale is installed and working (headscale v0.23.0-alpha5, on debian 12.4). OIDC is set up using Google Workspace as the provider. Connect tailscale client for linux, using my headscale server as the login-server. Copy/paste oidc url, authenticate as a google workspace user. Let's say "firstuser@mydomain.com". It authenticates successfully. Install tailscale client for windows (1.6.2). Set registry values to point to my headscale server. Select Login from the tailscale client menu.. it does OIDC auth in the browser.. authenticate using SAME google user as before, it works. Everything works as configured (nodes can see each other, subnet route works, and configured dns server is used). (Amazing.. loving this.. thanks!). Headscale shows two nodes up and one user, as expected. Now I want to log out as my regular user and try logging in as a different user.. this is where the problem comes... In the windows client, select my user.. then "Log out". It appears to log out and disconnect. Tailscale prompts me to log in.. I click and the oidc page comes up. I select a DIFFERENT account in my workspace domain. I get the validation page from my headscale server "Reauthenticated as seconduser@mydomain.com, you can now close this window". Open the tailscale for Windows menu.. it shows that I'm connected NOT as "seconduser" but as "firstuser".. and this is indicated by the headscale admin as well. I'm connected again, but not as the user that I selected (and that appeared on the "Signed in via your OIDC provider" page.... LMK of any solution.. Thanks! EDIT: If I delete the node from headscale then it works.. I am able to login as a different user. PS: While I'm here, I'd like make a related suggestion: In the oidc code, I see that if a user is not found in the headscale database, a new user is inserted. The problem with this is that Google Workspace does not seem to support groups via oidc (for now). So it's not possible to use allowed_groups to control who can authenticate with headscale, everyone in the domain can do it and a user record will be created.. the only way to prevent that is to add an entry for every user under allowed_users in config.yaml. What I would like to see is: 1. A new oidc setting "autocreate_user". If set to true, the behavior is the same as now. If set to false, a "user not found" will cause an error message to be returned to the authenticating browser. 2. A new oidc setting "autocreate_user_enabled", If set to true, new autocreated users.. if allowed by above, will be active immediately and the authentication will succeed. If false, the user will be created, but authentication will fail until their enabled status is changed to true (via command line or API). 3. An "enabled" column would need to be added to the user table to support this. Thanks! (If you are interested in patches I'll make one.. I don't know Go.. but I know a lot of other languages.. it doesn't look too hard....)
adam commented 2025-12-29 02:19:42 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jun 24, 2024):

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

@github-actions[bot] commented on GitHub (Jun 24, 2024): This issue is stale because it has been open for 90 days with no activity.
adam commented 2025-12-29 02:19:42 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 1, 2024):

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

@github-actions[bot] commented on GitHub (Jul 1, 2024): This issue was closed because it has been inactive for 14 days since being marked as stale.
adam commented 2025-12-29 02:19:43 +01:00
Author
Owner
Copy Link

@W1BTR commented on GitHub (Aug 12, 2024):

Any updates on this? Just came across this too, need some way to switch between multiple users.

@W1BTR commented on GitHub (Aug 12, 2024): Any updates on this? Just came across this too, need **some** way to switch between multiple users.
adam commented 2025-12-29 02:19:43 +01:00
Author
Owner
Copy Link

@almereyda commented on GitHub (Aug 13, 2024):

One workaround I heard about was running multiple tailscaled daemons and scoping the client to either of them. In addition to tailscale0, you would be able to also setup tailscale1, tailscale2, tailscale…, tailscalen. Unfortunately I have not tested it myself.

@almereyda commented on GitHub (Aug 13, 2024): One workaround I heard about was running multiple `tailscaled` daemons and scoping the client to either of them. In addition to `tailscale0`, you would be able to also setup `tailscale1`, `tailscale2`, `tailscale…`, `tailscalen`. Unfortunately I have not tested it myself.
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 bug stale well described ❤️
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#539
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?