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

[Feature] OIDC "offboarding" #913

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

Originally created by @dibi-codes on GitHub (Jan 21, 2025).

Use case

I have the case that as soon as a user gets offboarded (e.g. disabled/blocked/deleted) from within oidc (EntraID) the tailnet access should be revoked as well.

Description

Automatically check whether a connecting user is still allowed to access the tailnet and expire the node if needed.

Contribution

  • I can write the design doc for this feature
  • I can contribute this feature

How can it be implemented?

From my perspective the simplest solution would be to implement a trigger to call EntraID everytime a node connects and check whether the users is still enabled or even member of the required group etc.

Originally created by @dibi-codes on GitHub (Jan 21, 2025). ### Use case I have the case that as soon as a user gets offboarded (e.g. disabled/blocked/deleted) from within oidc (EntraID) the tailnet access should be revoked as well. ### Description Automatically check whether a connecting user is still allowed to access the tailnet and expire the node if needed. ### Contribution - [ ] I can write the design doc for this feature - [ ] I can contribute this feature ### How can it be implemented? From my perspective the simplest solution would be to implement a trigger to call EntraID everytime a node connects and check whether the users is still enabled or even member of the required group etc.
adam added the enhancementstale labels 2025-12-29 02:25:54 +01:00
adam closed this issue 2025-12-29 02:25:54 +01:00
adam commented 2025-12-29 02:25:54 +01:00
Author
Owner
Copy Link

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

If there is a part of the OIDC standard that allows you to do this, we can have a look, but I have not come across it. If this is something that would have to be implemented on a per OIDC basis, it is not feasible.

I would propose using the API/CLI to make a script validating this for your provider checking the list and disabling any user that is no longer present in your system.

@kradalby commented on GitHub (Jan 22, 2025): If there is a part of the OIDC standard that allows you to do this, we can have a look, but I have not come across it. If this is something that would have to be implemented on a per OIDC basis, it is not feasible. I would propose using the API/CLI to make a script validating this for your provider checking the list and disabling any user that is no longer present in your system.
adam commented 2025-12-29 02:25:54 +01:00
Author
Owner
Copy Link

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

Something I have seen being used in such scenarios is using refresh token to achieve this. Let the user session be valid for as long as access token’s expiration and use refresh token after access token has expired to request new token. This will keep the user info up to date and if user is disabled/blocked/deleted then IDP should 403.

@suyashFSG commented on GitHub (Jan 28, 2025): Something I have seen being used in such scenarios is using refresh token to achieve this. Let the user session be valid for as long as access token’s expiration and use refresh token after access token has expired to request new token. This will keep the user info up to date and if user is disabled/blocked/deleted then IDP should 403.
adam commented 2025-12-29 02:25:55 +01:00
Author
Owner
Copy Link

@dibi-codes commented on GitHub (Jan 31, 2025):

@kradalby:
Got you, thanks. Unfortunately I'm not that into OIDC standards.
In terms of a script I think it would be nice to have something like a hook system that calls custom commands e.g. upon login.

@suyashFSG How did you implement this within headscale?

@dibi-codes commented on GitHub (Jan 31, 2025): @kradalby: Got you, thanks. Unfortunately I'm not that into OIDC standards. In terms of a script I think it would be nice to have something like a hook system that calls custom commands e.g. upon login. @suyashFSG How did you implement this within headscale?
adam commented 2025-12-29 02:25:55 +01:00
Author
Owner
Copy Link

@suyashFSG commented on GitHub (Feb 9, 2025):

@dibi-codes I have not implemented this within headscale, I was talking about how other applications that I have used makes use of refresh token for similar behavior

@suyashFSG commented on GitHub (Feb 9, 2025): @dibi-codes I have not implemented this within headscale, I was talking about how other applications that I have used makes use of refresh token for similar behavior
adam commented 2025-12-29 02:25:55 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (May 10, 2025):

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

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

@github-actions[bot] commented on GitHub (May 17, 2025):

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

@github-actions[bot] commented on GitHub (May 17, 2025): This issue was closed because it has been inactive for 14 days since being marked as stale.
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 enhancement stale
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#913
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?