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

API key support #76

New Issue
Closed
opened 2025-12-29 01:21:45 +01:00 by adam · 4 comments
adam commented 2025-12-29 01:21:45 +01:00
Owner
Copy Link

Originally created by @kradalby on GitHub (Nov 12, 2021).

Originally assigned to: @kradalby on GitHub.

We need to add support for creating, storing and authorising API keys.

We have support for gRPC and HTTP but we currently make all requests end in a failed authorisation.

This issue requires:

  • a new mode for storing api keys
  • Understanding best practice for storing keys
    • Keys should be stored salted and encrypted (a leaked db should be useless)
  • Support for expiring keys
  • Convenience functions to check the key
  • Enable in grpc interceptor
  • Enable in http auth
Originally created by @kradalby on GitHub (Nov 12, 2021). Originally assigned to: @kradalby on GitHub. We need to add support for creating, storing and authorising API keys. We have support for gRPC and HTTP but we currently make all requests end in a failed authorisation. This issue requires: - [ ] a new mode for storing api keys - [ ] Understanding best practice for storing keys - Keys should be stored salted and encrypted (a leaked db should be useless) - [ ] Support for expiring keys - [ ] Convenience functions to check the key - [ ] Enable in grpc interceptor - [ ] Enable in http auth
adam added the enhancement label 2025-12-29 01:21:45 +01:00
adam closed this issue 2025-12-29 01:21:45 +01:00
adam commented 2025-12-29 01:21:46 +01:00
Author
Owner
Copy Link

@ItalyPaleAle commented on GitHub (Nov 13, 2021):

If I could make a suggestion, have you considered relying on OAuth2 and JWTs? I really love it when apps allow me to re-use the same accounts :)

Pro:

  • Standard-based
  • Authentication+authorization become someone else's problem - some of your requirements get solved automatically (such as safely storing keys, expiring keys, etc)
    • Corollary: depending on the auth server, and this can offer additional things such as 2FA.
  • Users can re-use existing credentials
  • Different OAuth flows can be used to authenticate/authorize users and applications (other machines)

Cons:

  • Adds a dependency on an external service. This can be self-hosted (Keycloak, Hydra...) but for most users it may be more convenient to use an external OIDC provider (such as Auth0, Azure AD, Okta, Google Apps)
@ItalyPaleAle commented on GitHub (Nov 13, 2021): If I could make a suggestion, have you considered relying on OAuth2 and JWTs? I really love it when apps allow me to re-use the same accounts :) Pro: - Standard-based - Authentication+authorization become someone else's problem - some of your requirements get solved automatically (such as safely storing keys, expiring keys, etc) - Corollary: depending on the auth server, and this can offer additional things such as 2FA. - Users can re-use existing credentials - Different OAuth flows can be used to authenticate/authorize users and applications (other machines) Cons: - Adds a dependency on an external service. This can be self-hosted (Keycloak, Hydra...) but for most users it may be more convenient to use an external OIDC provider (such as Auth0, Azure AD, Okta, Google Apps)
adam commented 2025-12-29 01:21:47 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Nov 14, 2021):

We have started to add oidc in the unreleased version on main, while it is suitable for node registration for now. I don't think it is suitable for the CLI use case to begin with, I don't think we can assume that most users have a oidc provider to rely on.

In general, I am not sure if the CLI should rely on any other service than headscale for auth. Most services I can think of would have OAuth and regular, old school API tokens as far as I can remember (github, dockerhub, etc)

That said, I am very much for expanding the auth for http and grpc with OAuth2 etc in the future.

But I might miss somethings, so happy to be enlightened.

@kradalby commented on GitHub (Nov 14, 2021): We have started to add oidc in the unreleased version on `main`, while it is suitable for node registration for now. I don't think it is suitable for the CLI use case to begin with, I don't think we can assume that most users have a oidc provider to rely on. In general, I am not sure if the CLI should rely on any other service than headscale for auth. Most services I can think of would have OAuth _and_ regular, old school API tokens as far as I can remember (github, dockerhub, etc) That said, I am very much for _expanding_ the auth for `http` and `grpc` with OAuth2 etc in the future. But I might miss somethings, so happy to be enlightened.
adam commented 2025-12-29 01:21:47 +01:00
Author
Owner
Copy Link

@ohdearaugustin commented on GitHub (Nov 18, 2021):

I would also be in favor for not relying on an external service. As for hydra and keycloak they are not easy to operate for everyone. So classical API tokens are in my opinion necessary to make this feature more accessible for users.

So I'm rather with @kradalby opinion on that one.

The other implementation are a nice to have and if you already have an infrastructure for it.

@ohdearaugustin commented on GitHub (Nov 18, 2021): I would also be in favor for not relying on an external service. As for hydra and keycloak they are not easy to operate for everyone. So classical API tokens are in my opinion necessary to make this feature more accessible for users. So I'm rather with @kradalby opinion on that one. The other implementation are a nice to have and if you already have an infrastructure for it.
adam commented 2025-12-29 01:21:48 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Feb 13, 2022):

This feature has been implemented in #306, please feel free to give it a try.

@kradalby commented on GitHub (Feb 13, 2022): This feature has been implemented in #306, please feel free to give it a try.
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
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#76
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?