[Bug] OIDC not working with Authentik > 2024.2? #699

Closed
opened 2025-12-29 02:22:18 +01:00 by adam · 49 comments
Owner

Originally created by @badsmoke on GitHub (Apr 29, 2024).

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

after updating to authentik 2024.4.1, the connection to headscale no longer works properly.

after a headscale restart, for example, the exit node no longer works.

I assume that this is the problem?

Starting with authentik 2024.2, applications only receive an access token. To receive a refresh token, both applications and authentik must be configured to request the offline_access scope. In authentik this can be done by selecting the offline_access Scope mapping in the provider settings.

I previously had an authentik smaller 2024, which ran without any problems

headscale_1        | 2024/04/29 13:43:32 http: response.WriteHeader on hijacked connection from github.com/juanfont/headscale/hscontrol.(*Headscale).NoiseUpgradeHandler (noise.go:84)
headscale_1        | 2024/04/29 13:43:32 http: response.Write on hijacked connection from fmt.Fprintln (print.go:305)
headscale_1        | 2024-04-29T13:43:36Z ERR noise upgrade failed error="noise handshake failed: decrypting machine key: chacha20poly1305: message authentication failed"
headscale_1        | 2024/04/29 13:43:36 http: response.WriteHeader on hijacked connection from github.com/juanfont/headscale/hscontrol.(*Headscale).NoiseUpgradeHandler (noise.go:84)
headscale_1        | 2024/04/29 13:43:36 http: response.Write on hijacked connection from fmt.Fprintln (print.go:305)

Expected Behavior

just like before :-D it should work

unfortunately I can no longer downgrade without further ado to test it further

Steps To Reproduce

  1. headscale set up so that oidc runs via authentik (< 2024)

  2. authentik update, which offline_access needs

  3. connect to headscale, works but exit node does not work (no internet)

  4. exit-node reauth, internet works again-> until the next headscale restart or a time?

Environment

- OS:ubuntu 22.04
- Headscale version: 0.23.0-alpha9
- Tailscale version: 1.64.0

Runtime environment

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

Anything else?

that's just a guess, but i updated authentik at the weekend and it hasn't worked since then

Originally created by @badsmoke on GitHub (Apr 29, 2024). ### 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 after updating to authentik 2024.4.1, the connection to headscale no longer works properly. after a headscale restart, for example, the exit node no longer works. I assume that this is the problem? `Starting with authentik 2024.2, applications only receive an access token. To receive a refresh token, both applications and authentik must be configured to request the offline_access scope. In authentik this can be done by selecting the offline_access Scope mapping in the provider settings.` I previously had an authentik smaller 2024, which ran without any problems ``` headscale_1 | 2024/04/29 13:43:32 http: response.WriteHeader on hijacked connection from github.com/juanfont/headscale/hscontrol.(*Headscale).NoiseUpgradeHandler (noise.go:84) headscale_1 | 2024/04/29 13:43:32 http: response.Write on hijacked connection from fmt.Fprintln (print.go:305) headscale_1 | 2024-04-29T13:43:36Z ERR noise upgrade failed error="noise handshake failed: decrypting machine key: chacha20poly1305: message authentication failed" headscale_1 | 2024/04/29 13:43:36 http: response.WriteHeader on hijacked connection from github.com/juanfont/headscale/hscontrol.(*Headscale).NoiseUpgradeHandler (noise.go:84) headscale_1 | 2024/04/29 13:43:36 http: response.Write on hijacked connection from fmt.Fprintln (print.go:305) ``` ### Expected Behavior just like before :-D it should work unfortunately I can no longer downgrade without further ado to test it further ### Steps To Reproduce 1. headscale set up so that oidc runs via authentik (< 2024) 2. authentik update, which offline_access needs 3. connect to headscale, works but exit node does not work (no internet) 4. exit-node reauth, internet works again-> until the next headscale restart or a time? ### Environment ```markdown - OS:ubuntu 22.04 - Headscale version: 0.23.0-alpha9 - Tailscale version: 1.64.0 ``` ### Runtime environment - [X] Headscale is behind a (reverse) proxy - [X] Headscale runs in a container ### Anything else? that's just a guess, but i updated authentik at the weekend and it hasn't worked since then
adam added the bugOIDC labels 2025-12-29 02:22:18 +01:00
adam closed this issue 2025-12-29 02:22:18 +01:00
Author
Owner

@yeyeoke commented on GitHub (May 4, 2024):

Same problem here!

@yeyeoke commented on GitHub (May 4, 2024): Same problem here!
Author
Owner

@badsmoke commented on GitHub (May 8, 2024):

are you sure? so it has something to do with the offlice_access scope.

here is an explanation

go-oidc also supports the scope

https://pkg.go.dev/github.com/coreos/go-oidc/v3/oidc

search for "offlice_access"

i have added the scope in the headscale config and authentik but it does not bring any noticeable change

@badsmoke commented on GitHub (May 8, 2024): are you sure? so it has something to do with the offlice_access scope. [here is an explanation](https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess) go-oidc also supports the scope https://pkg.go.dev/github.com/coreos/go-oidc/v3/oidc search for "offlice_access" i have added the scope in the headscale config and authentik but it does not bring any noticeable change
Author
Owner

@Ziomal12 commented on GitHub (May 8, 2024):

@badsmoke

are you sure? so it has something to do with the offlice_access scope.

here is an explanation

go-oidc also supports the scope

https://pkg.go.dev/github.com/coreos/go-oidc/v3/oidc

search for "offlice_access"

i have added the scope in the headscale config and authentik but it does not bring any noticeable change

Could you share your config and explain in more detail what you've done? I think I've also added that and no authentik login screen appears anyways.

@Ziomal12 commented on GitHub (May 8, 2024): @badsmoke > are you sure? so it has something to do with the offlice_access scope. > > [here is an explanation](https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess) > > go-oidc also supports the scope > > https://pkg.go.dev/github.com/coreos/go-oidc/v3/oidc > > search for "offlice_access" > > i have added the scope in the headscale config and authentik but it does not bring any noticeable change Could you share your config and explain in more detail what you've done? I think I've also added that and no authentik login screen appears anyways.
Author
Owner

@sonroyaalmerol commented on GitHub (May 10, 2024):

Had this exact same problem. For authentik, you'd need an additional extra_params and include the offline_access scope. Make sure to actually include the scope in authentik OAuth2 provider side as well.

You would also need to set a Signing Key (you can use the self-signed one) for the OAuth2 provider of authentik to use RS256 for signing which I think is required for Headscale.

Here's a sample portion of the headscale config for the oidc:

oidc:
  ...
  scope:
    - openid
    - profile
    - email
    - offline_access
  extra_params:
    prompt: consent
@sonroyaalmerol commented on GitHub (May 10, 2024): Had this exact same problem. For authentik, you'd need an additional `extra_params` and include the `offline_access` scope. Make sure to actually include the scope in authentik OAuth2 provider side as well. You would also need to set a Signing Key (you can use the self-signed one) for the OAuth2 provider of authentik to use RS256 for signing which I think is required for Headscale. Here's a sample portion of the headscale config for the oidc: ``` oidc: ... scope: - openid - profile - email - offline_access extra_params: prompt: consent ```
Author
Owner

@badsmoke commented on GitHub (May 14, 2024):

everything went smoothly over the weekend, did it work for you too? @yeyeoke and @Ziomal12

then I would close this issue

@badsmoke commented on GitHub (May 14, 2024): everything went smoothly over the weekend, did it work for you too? @yeyeoke and @Ziomal12 then I would close this issue
Author
Owner

@julianq commented on GitHub (May 14, 2024):

@sonroyaalmerol @badsmoke I'm now having this exact issue.

My headscale config includes:

oidc:
  ...
  scope: ["openid", "profile", "email", "offline_access"]
  extra_params:
    prompt: consent

The OIDC provider on the Authentik side is using the self-signed certificate, not expired, and also has offline_access included in scope.

Keep getting: connect: connection refused

Any ideas?

@julianq commented on GitHub (May 14, 2024): @sonroyaalmerol @badsmoke I'm now having this exact issue. My headscale config includes: ``` oidc: ... scope: ["openid", "profile", "email", "offline_access"] extra_params: prompt: consent ``` The OIDC provider on the Authentik side is using the self-signed certificate, not expired, and also has offline_access included in scope. Keep getting: `connect: connection refused` Any ideas?
Author
Owner

@Ziomal12 commented on GitHub (May 14, 2024):

In docker logs headscale I see this error:

2024-05-14T16:24:40+02:00 WRN failed to set up OIDC provider, falling back to CLI based authentication error="creating OIDC provider from issuer config: Get \"https://example.com/application/o/headscale/.well-known/openid-configuration\": net/http: TLS handshake timeout"

The address is accessible through the URL with valid LE cert.

Here is my config.yaml:

oidc:
   only_start_if_oidc_is_available: false
   issuer: https://example.com/application/o/headscale/
   client_id: "headscale"
   client_secret: "*********************************"
   expiry: 0
   use_expiry_from_token: false
   scope: ["openid", "profile", "email", "offline_access"]
   extra_params:
     prompt: consent

In authentik provider config I have set singing key and the same scopes as in the config file.

@Ziomal12 commented on GitHub (May 14, 2024): In `docker logs headscale` I see this error: ``` 2024-05-14T16:24:40+02:00 WRN failed to set up OIDC provider, falling back to CLI based authentication error="creating OIDC provider from issuer config: Get \"https://example.com/application/o/headscale/.well-known/openid-configuration\": net/http: TLS handshake timeout" ``` The address is accessible through the URL with valid LE cert. Here is my config.yaml: ``` oidc: only_start_if_oidc_is_available: false issuer: https://example.com/application/o/headscale/ client_id: "headscale" client_secret: "*********************************" expiry: 0 use_expiry_from_token: false scope: ["openid", "profile", "email", "offline_access"] extra_params: prompt: consent ``` In authentik provider config I have set singing key and the same scopes as in the config file.
Author
Owner

@julianq commented on GitHub (May 14, 2024):

@Ziomal12 I think you and I are having the exact same problem. I cannot figure out why it's not connecting.

@julianq commented on GitHub (May 14, 2024): @Ziomal12 I think you and I are having the exact same problem. I cannot figure out why it's not connecting.
Author
Owner

@badsmoke commented on GitHub (May 14, 2024):

i have not extra params

oidc:
#   only_start_if_oidc_is_available: true
   only_start_if_oidc_is_available: true
   issuer: "https://auth.example.io/application/o/headscale-test/"
   client_id: "123123123123213"
   client_secret: "12123123123"


   expiry: 0

   scope: ["openid", "profile", "email", "offline_access"]

@badsmoke commented on GitHub (May 14, 2024): i have not extra params ``` oidc: # only_start_if_oidc_is_available: true only_start_if_oidc_is_available: true issuer: "https://auth.example.io/application/o/headscale-test/" client_id: "123123123123213" client_secret: "12123123123" expiry: 0 scope: ["openid", "profile", "email", "offline_access"] ```
Author
Owner

@julianq commented on GitHub (May 14, 2024):

@badsmoke extra_params seems to be mostly irrelevant, as i think the default is prompt: consent anyway. regardless, with or without extra_params I get the same error. What do you have for config on the authentik side?

@julianq commented on GitHub (May 14, 2024): @badsmoke `extra_params` seems to be mostly irrelevant, as i think the default is `prompt: consent` anyway. regardless, with or without `extra_params` I get the same error. What do you have for config on the authentik side?
Author
Owner

@Ziomal12 commented on GitHub (May 14, 2024):

i have not extra params

oidc:
#   only_start_if_oidc_is_available: true
   only_start_if_oidc_is_available: true
   issuer: "https://auth.example.io/application/o/headscale-test/"
   client_id: "123123123123213"
   client_secret: "12123123123"


   expiry: 0

   scope: ["openid", "profile", "email", "offline_access"]

Removing extra_parms does not help. Here is my Authentik config for headscale provider:

obraz
obraz
obraz

@Ziomal12 commented on GitHub (May 14, 2024): > i have not extra params > > ``` > oidc: > # only_start_if_oidc_is_available: true > only_start_if_oidc_is_available: true > issuer: "https://auth.example.io/application/o/headscale-test/" > client_id: "123123123123213" > client_secret: "12123123123" > > > expiry: 0 > > scope: ["openid", "profile", "email", "offline_access"] > ``` Removing `extra_parms` does not help. Here is my Authentik config for headscale provider: ![obraz](https://github.com/juanfont/headscale/assets/126906166/0020a73f-218d-478f-b444-58ea35b72cb4) ![obraz](https://github.com/juanfont/headscale/assets/126906166/f33aa43c-27c0-4149-a394-1d8f31529a67) ![obraz](https://github.com/juanfont/headscale/assets/126906166/9ea18efc-f1c1-479c-8503-e92cc995189f)
Author
Owner

@julianq commented on GitHub (May 14, 2024):

@Ziomal12 exactly what I have

@julianq commented on GitHub (May 14, 2024): @Ziomal12 exactly what I have
Author
Owner

@Ziomal12 commented on GitHub (May 14, 2024):

@julianq What versions are you using?
I'm running Authentik 2024.4.2 and headscale v0.23.0-alpha11

@Ziomal12 commented on GitHub (May 14, 2024): @julianq What versions are you using? I'm running Authentik [2024.4.2](https://goauthentik.io/docs/releases/2024.4) and headscale [v0.23.0-alpha11](https://github.com/juanfont/headscale/releases/tag/v0.23.0-alpha11)
Author
Owner

@julianq commented on GitHub (May 14, 2024):

@Ziomal12 2024.4.2 on authentik, on headscale its whatever the latest release (ie non-alpha) is. I forget the build number I'll go look it up.

ETA: 0.22.3

@julianq commented on GitHub (May 14, 2024): @Ziomal12 2024.4.2 on authentik, on headscale its whatever the latest release (ie non-alpha) is. I forget the build number I'll go look it up. ETA: 0.22.3
Author
Owner

@badsmoke commented on GitHub (May 14, 2024):

I have the same config except for the redirect url, which is still very open with .*

@badsmoke commented on GitHub (May 14, 2024): I have the same config except for the redirect url, which is still very open with `.*`
Author
Owner

@julianq commented on GitHub (May 14, 2024):

@Ziomal12 Okay so I seem to have fixed it by putting Headscale and Authentik on the same VLAN (they were on separate VLANs before). I have no idea how this got borked since there were no config changes before it stopped working. I also explicitly allowed all traffic between the VLANs and it still didn't work, only when they were put on the same VLAN. I'll have to do some more digging as to why this happened, but for now, I'm just happy its working.

@julianq commented on GitHub (May 14, 2024): @Ziomal12 Okay so I seem to have fixed it by putting Headscale and Authentik on the same VLAN (they were on separate VLANs before). I have no idea how this got borked since there were no config changes before it stopped working. I also explicitly allowed all traffic between the VLANs and it still didn't work, only when they were put on the same VLAN. I'll have to do some more digging as to why this happened, but for now, I'm just happy its working.
Author
Owner

@Ziomal12 commented on GitHub (May 14, 2024):

@julianq Glad to hear that! Unfortunately I'm unable to do that as both services run on different machines. Hopefully there's a fix soon, not a workaround.

@Ziomal12 commented on GitHub (May 14, 2024): @julianq Glad to hear that! Unfortunately I'm unable to do that as both services run on different machines. Hopefully there's a fix soon, not a workaround.
Author
Owner

@julianq commented on GitHub (May 14, 2024):

@Ziomal12 Agreed.

@julianq commented on GitHub (May 14, 2024): @Ziomal12 Agreed.
Author
Owner

@julianq commented on GitHub (May 14, 2024):

For what it's worth, I removed offline_access from the scope and it's still working, so that's not a contributing factor here.

@julianq commented on GitHub (May 14, 2024): For what it's worth, I removed `offline_access` from the scope and it's still working, so that's not a contributing factor here.
Author
Owner

@julianq commented on GitHub (May 14, 2024):

@Ziomal12 This is an Authentik issue. Second service having authentication issues, which were fixed by moving the service on to the same VLAN as Authentik. I'll file a bug report there.

@julianq commented on GitHub (May 14, 2024): @Ziomal12 This is an Authentik issue. Second service having authentication issues, which were fixed by moving the service on to the same VLAN as Authentik. I'll file a bug report there.
Author
Owner

@SpiderD555 commented on GitHub (Jun 8, 2024):

Just made headscale work with Authentik.

Comparing to what Ziomal12 wrote:

i have not extra params

oidc:
#   only_start_if_oidc_is_available: true
   only_start_if_oidc_is_available: true
   issuer: "https://auth.example.io/application/o/headscale-test/"
   client_id: "123123123123213"
   client_secret: "12123123123"


   expiry: 0

   scope: ["openid", "profile", "email", "offline_access"]

I don't have "offline_access" scope, and expiry is set to 180d, my "allowed_groups:" is set to "headscale"
Moreover I had to set callback URL in Authentik to ".*", and my user is part of "headscale" group which is attached to the application definition. Moreover I don't have the "offline_access" mapping defined in Authentik
My Authentik version is currently 2024.4.2
Headscale version is v0.22.3

I guess the only bug on headscale side I see here is the invalid callback URL which Authentik complains about if I don't set "."
I tried the same with Keycloak, and I also had to set "
" there as redirect URL to make it work

@SpiderD555 commented on GitHub (Jun 8, 2024): Just made headscale work with Authentik. Comparing to what Ziomal12 wrote: > > i have not extra params > > ``` > > oidc: > > # only_start_if_oidc_is_available: true > > only_start_if_oidc_is_available: true > > issuer: "https://auth.example.io/application/o/headscale-test/" > > client_id: "123123123123213" > > client_secret: "12123123123" > > > > > > expiry: 0 > > > > scope: ["openid", "profile", "email", "offline_access"] > > ``` I don't have "offline_access" scope, and expiry is set to 180d, my "allowed_groups:" is set to "headscale" Moreover I had to set callback URL in Authentik to ".*", and my user is part of "headscale" group which is attached to the application definition. Moreover I don't have the "offline_access" mapping defined in Authentik My Authentik version is currently 2024.4.2 Headscale version is v0.22.3 I guess the only bug on headscale side I see here is the invalid callback URL which Authentik complains about if I don't set ".*" I tried the same with Keycloak, and I also had to set "*" there as redirect URL to make it work
Author
Owner

@masterwishx commented on GitHub (Jun 22, 2024):

So if we have 180 day Expiry, do we need offline_access?

@masterwishx commented on GitHub (Jun 22, 2024): So if we have 180 day Expiry, do we need offline_access?
Author
Owner

@grishio commented on GitHub (Nov 14, 2024):

I am on the latest version of authentik and all is well here with version v0.23.0. OIDC authentication works perfectly. Is this bug still valid?

@grishio commented on GitHub (Nov 14, 2024): I am on the latest version of authentik and all is well here with version v0.23.0. OIDC authentication works perfectly. Is this bug still valid?
Author
Owner

@B08Z commented on GitHub (Dec 17, 2024):

I am on the latest version of authentik and all is well here with version v0.23.0. OIDC authentication works perfectly. Is this bug still valid?

Could you provide your config both Authentik and headscale config (less keys and passwords)

That would be super helpful

@B08Z commented on GitHub (Dec 17, 2024): > I am on the latest version of authentik and all is well here with version v0.23.0. OIDC authentication works perfectly. Is this bug still valid? Could you provide your config both Authentik and headscale config (less keys and passwords) That would be super helpful
Author
Owner

@Ziomal12 commented on GitHub (Dec 17, 2024):

I need to apologise as I've figured out what's wrong (i think).
RN my best answer is that Headscale cannot connect to Authentik as Headscale is running on vps, that also serves as reverse proxy for Authentik (which runs on local machine). TBH I'm not sure why it worked before if that's the case. On fix to that could be to allow periodic check (instead of only on startup) to see if OIDC provider is available.

I'm not sure how i'd provide Authentik config but it's basically the stock one. As for headscale (v0.23.0) config:
config.yaml.txt

EDIT: Authentik's config posted here: https://github.com/juanfont/headscale/issues/1916#issuecomment-2110462525

@Ziomal12 commented on GitHub (Dec 17, 2024): I need to apologise as I've figured out what's wrong (i think). RN my best answer is that Headscale cannot connect to Authentik as Headscale is running on vps, that also serves as reverse proxy for Authentik (which runs on local machine). TBH I'm not sure why it worked before if that's the case. On fix to that could be to allow periodic check (instead of only on startup) to see if OIDC provider is available. I'm not sure how i'd provide Authentik config but it's basically the stock one. As for headscale (v0.23.0) config: [config.yaml.txt](https://github.com/user-attachments/files/18169536/config.yaml.txt) EDIT: Authentik's config posted here: https://github.com/juanfont/headscale/issues/1916#issuecomment-2110462525
Author
Owner

@masterwishx commented on GitHub (Dec 17, 2024):

I am on the latest version of authentik and all is well here with version v0.23.0. OIDC authentication works perfectly. Is this bug still valid?

Could you provide your config both Authentik and headscale config (less keys and passwords)

That would be super helpful

Posted here : https://github.com/juanfont/headscale/issues/2295#issuecomment-2547779529

@masterwishx commented on GitHub (Dec 17, 2024): > > I am on the latest version of authentik and all is well here with version v0.23.0. OIDC authentication works perfectly. Is this bug still valid? > > Could you provide your config both Authentik and headscale config (less keys and passwords) > > That would be super helpful Posted here : https://github.com/juanfont/headscale/issues/2295#issuecomment-2547779529
Author
Owner

@B08Z commented on GitHub (Dec 17, 2024):

I am on the latest version of authentik and all is well here with version v0.23.0. OIDC authentication works perfectly. Is this bug still valid?

Could you provide your config both Authentik and headscale config (less keys and passwords)

That would be super helpful

Posted here : https://github.com/juanfont/headscale/issues/2295#issuecomment-2547779529

Thank you this is really really helpful.

This is probably a very stupid question...and maybe more related to Authentik.
But when you say: headscale Users is that my uses of headscale (alice bob etc) just an arbitrary variable.

In the same vain do I need to create a user bob in Authentik that is in the headscale Users group?

Thanks in advance, and sorry for the stupid questions.

@B08Z commented on GitHub (Dec 17, 2024): > > > I am on the latest version of authentik and all is well here with version v0.23.0. OIDC authentication works perfectly. Is this bug still valid? > > > > Could you provide your config both Authentik and headscale config (less keys and passwords) > > > > That would be super helpful > > Posted here : https://github.com/juanfont/headscale/issues/2295#issuecomment-2547779529 Thank you this is really really helpful. This is probably a very stupid question...and maybe more related to Authentik. But when you say: headscale Users is that my uses of headscale (alice bob etc) just an arbitrary variable. In the same vain do I need to create a user bob in Authentik that is in the headscale Users group? Thanks in advance, and sorry for the stupid questions.
Author
Owner

@masterwishx commented on GitHub (Dec 17, 2024):

Yes but if you don't need group, you can use it without group I think

@masterwishx commented on GitHub (Dec 17, 2024): Yes but if you don't need group, you can use it without group I think
Author
Owner

@masterwishx commented on GitHub (Dec 17, 2024):

In the same vain do I need to create a user bob in Authentik that is in the headscale Users group?

It's Authentik group of users

@masterwishx commented on GitHub (Dec 17, 2024): > In the same vain do I need to create a user bob in Authentik that is in the headscale Users group? It's Authentik group of users
Author
Owner

@b4iterdev commented on GitHub (Jan 2, 2025):

I'm trying to setup OIDC with Authentik 2024.12.1 with the following oidc configuration: https://auth.b4iterdev.id.vn/application/o/headscale/.well-known/openid-configuration

on headscale config:

oidc:
  only_start_if_oidc_is_available: true
  issuer: "https://auth.b4iterdev.id.vn/application/o/headscale/"
  client_id: "reducted"
  client_secret: "reducted"
  
  expiry: 180d
  
  scope: ["openid", "profile", "email", "offline_access"]
  
  allowed_groups:
    - UF Players

Authentik redirect URIs:

Redirect URIs
strict: https://headscale.b4iterdev.net.eu.org/oidc/callback
strict: https://headscale.b4iterdev.net.eu.org/admin/oidc/callback

Preview with a test user:

{
    "iss": "https://auth.b4iterdev.id.vn/application/o/headscale/",
    "sub": "7",
    "aud": "zACdfDvfWqblpV5Agt2aq2kkFHNVe2wqsxzzNYZo",
    "exp": 1735823565,
    "iat": 1735821765,
    "auth_time": 1735821765,
    "acr": "goauthentik.io/providers/oauth2/default",
    "email": "",
    "email_verified": true,
    "name": "Test User",
    "given_name": "Test User",
    "preferred_username": "test",
    "nickname": "test",
    "groups": [
        "UF Players"
    ]
}

With only_start_if_oidc_is_available: true in place and observing logs, it does seems that headscale are able to contact with Authentik as it does send url to client for authentication, however I have this weird error:
image

Not sure if this is a Authentik bug or headscale one, but does anyone having the same issue as I am, or am I missing something ?

@b4iterdev commented on GitHub (Jan 2, 2025): I'm trying to setup OIDC with Authentik 2024.12.1 with the following oidc configuration: https://auth.b4iterdev.id.vn/application/o/headscale/.well-known/openid-configuration on headscale config: ``` oidc: only_start_if_oidc_is_available: true issuer: "https://auth.b4iterdev.id.vn/application/o/headscale/" client_id: "reducted" client_secret: "reducted" expiry: 180d scope: ["openid", "profile", "email", "offline_access"] allowed_groups: - UF Players ``` Authentik redirect URIs: ``` Redirect URIs strict: https://headscale.b4iterdev.net.eu.org/oidc/callback strict: https://headscale.b4iterdev.net.eu.org/admin/oidc/callback ``` Preview with a test user: ``` { "iss": "https://auth.b4iterdev.id.vn/application/o/headscale/", "sub": "7", "aud": "zACdfDvfWqblpV5Agt2aq2kkFHNVe2wqsxzzNYZo", "exp": 1735823565, "iat": 1735821765, "auth_time": 1735821765, "acr": "goauthentik.io/providers/oauth2/default", "email": "", "email_verified": true, "name": "Test User", "given_name": "Test User", "preferred_username": "test", "nickname": "test", "groups": [ "UF Players" ] } ``` With ```only_start_if_oidc_is_available: true``` in place and observing logs, it does seems that headscale are able to contact with Authentik as it does send url to client for authentication, however I have this weird error: ![image](https://github.com/user-attachments/assets/baa32566-d667-423d-a141-f5f2e7bc19f9) Not sure if this is a Authentik bug or headscale one, but does anyone having the same issue as I am, or am I missing something ?
Author
Owner

@badsmoke commented on GitHub (Jan 2, 2025):

what kind of crazy domain is that ;-)

but the redirect url looks correct

headscale.domain.tld//oidc/callback , try it with regex

regex: https://headscale.b4iterdev.net.eu.org/.*

@badsmoke commented on GitHub (Jan 2, 2025): what kind of crazy domain is that ;-) but the redirect url looks correct headscale.domain.tld//oidc/callback , try it with regex regex: `https://headscale.b4iterdev.net.eu.org/.*`
Author
Owner

@b4iterdev commented on GitHub (Jan 2, 2025):

what kind of crazy domain is that ;-)

Free domain lol, I have a better one but I'd prefer using that domain for now

regex: https://headscale.b4iterdev.net.eu.org/.*

I tried but it still gave me the same error, worth to note that I also setup OIDC on /admin/oidc/callback and it worked flawlessly

@b4iterdev commented on GitHub (Jan 2, 2025): > what kind of crazy domain is that ;-) > Free domain lol, I have a better one but I'd prefer using that domain for now > regex: https://headscale.b4iterdev.net.eu.org/.* I tried but it still gave me the same error, worth to note that I also setup OIDC on /admin/oidc/callback and it worked flawlessly
Author
Owner

@b4iterdev commented on GitHub (Jan 2, 2025):

I do compare the rediect url and realise that headscale redirect url does contain :443 as in headscale server url config, which lead to authentik returned as invalid url.
With that resolved I can now login, but I'm getting:
Authenticated as , you can now close this window.
Also I realised that I have to reauthenicate every time tailscale get disconnected, any ideas how to resolve this ?

@b4iterdev commented on GitHub (Jan 2, 2025): I do compare the rediect url and realise that headscale redirect url does contain :443 as in headscale server url config, which lead to authentik returned as invalid url. With that resolved I can now login, but I'm getting: ```Authenticated as , you can now close this window.``` Also I realised that I have to reauthenicate every time tailscale get disconnected, any ideas how to resolve this ?
Author
Owner

@badsmoke commented on GitHub (Jan 2, 2025):

great, yes you dont need the port in the server_url

the rest of the oidc settings looks good for me

Are there any noticeable headscale logs?

@badsmoke commented on GitHub (Jan 2, 2025): great, yes you dont need the port in the server_url the rest of the oidc settings looks good for me Are there any noticeable headscale logs?
Author
Owner

@b4iterdev commented on GitHub (Jan 2, 2025):

headscale logs indicated that nodes are registered successfully, but only that, I don't get anything related to username, also running headscale users list give me a list with a user that has empty name.

@b4iterdev commented on GitHub (Jan 2, 2025): headscale logs indicated that nodes are registered successfully, but only that, I don't get anything related to username, also running ```headscale users list``` give me a list with a user that has empty name.
Author
Owner

@b4iterdev commented on GitHub (Jan 2, 2025):

Might worth to mention, after authenticate and connected to tailnet, in tailscale menu
image

@b4iterdev commented on GitHub (Jan 2, 2025): Might worth to mention, after authenticate and connected to tailnet, in tailscale menu ![image](https://github.com/user-attachments/assets/e443465a-d1bd-4319-9aa1-06523b8e2cc1)
Author
Owner

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

Have you got any further?

which headscale version are you actually using?

@badsmoke commented on GitHub (Jan 9, 2025): Have you got any further? which headscale version are you actually using?
Author
Owner

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

Have you got any further?

I actually solved that, the reason is that it require the user to have a email present, which initally I don't have, by adding email on Authentik it can login now

@b4iterdev commented on GitHub (Jan 9, 2025): > Have you got any further? I actually solved that, the reason is that it require the user to have a email present, which initally I don't have, by adding email on Authentik it can login now
Author
Owner

@javito1081 commented on GitHub (Apr 21, 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

after updating to authentik 2024.4.1, the connection to headscale no longer works properly.

after a headscale restart, for example, the exit node no longer works.

I assume that this is the problem?

Starting with authentik 2024.2, applications only receive an access token. To receive a refresh token, both applications and authentik must be configured to request the offline_access scope. In authentik this can be done by selecting the offline_access Scope mapping in the provider settings.

I previously had an authentik smaller 2024, which ran without any problems

headscale_1        | 2024/04/29 13:43:32 http: response.WriteHeader on hijacked connection from github.com/juanfont/headscale/hscontrol.(*Headscale).NoiseUpgradeHandler (noise.go:84)
headscale_1        | 2024/04/29 13:43:32 http: response.Write on hijacked connection from fmt.Fprintln (print.go:305)
headscale_1        | 2024-04-29T13:43:36Z ERR noise upgrade failed error="noise handshake failed: decrypting machine key: chacha20poly1305: message authentication failed"
headscale_1        | 2024/04/29 13:43:36 http: response.WriteHeader on hijacked connection from github.com/juanfont/headscale/hscontrol.(*Headscale).NoiseUpgradeHandler (noise.go:84)
headscale_1        | 2024/04/29 13:43:36 http: response.Write on hijacked connection from fmt.Fprintln (print.go:305)

Expected Behavior

just like before :-D it should work

unfortunately I can no longer downgrade without further ado to test it further

Steps To Reproduce

  1. headscale set up so that oidc runs via authentik (< 2024)
  2. authentik update, which offline_access needs
  3. connect to headscale, works but exit node does not work (no internet)
  4. exit-node reauth, internet works again-> until the next headscale restart or a time?

Environment

  • OS:ubuntu 22.04
  • Headscale version: 0.23.0-alpha9
  • Tailscale version: 1.64.0

Runtime environment

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

Anything else?

that's just a guess, but i updated authentik at the weekend and it hasn't worked since then

Hi, im trying to setup headscale with authentik but so far i havent been able to, whenever i try to start the headscale server i get an error saying:

headscale | 2025-04-20T22:38:43Z FTL home/runner/work/headscale/headscale/cmd/headscale/cli/serve.go:24 > Error initializing error="creating OIDC provider from issuer config: 404 Not Found

could u post a brief explanation of how u did it?

@javito1081 commented on GitHub (Apr 21, 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 > after updating to authentik 2024.4.1, the connection to headscale no longer works properly. > > after a headscale restart, for example, the exit node no longer works. > > I assume that this is the problem? > > `Starting with authentik 2024.2, applications only receive an access token. To receive a refresh token, both applications and authentik must be configured to request the offline_access scope. In authentik this can be done by selecting the offline_access Scope mapping in the provider settings.` > > I previously had an authentik smaller 2024, which ran without any problems > > ``` > headscale_1 | 2024/04/29 13:43:32 http: response.WriteHeader on hijacked connection from github.com/juanfont/headscale/hscontrol.(*Headscale).NoiseUpgradeHandler (noise.go:84) > headscale_1 | 2024/04/29 13:43:32 http: response.Write on hijacked connection from fmt.Fprintln (print.go:305) > headscale_1 | 2024-04-29T13:43:36Z ERR noise upgrade failed error="noise handshake failed: decrypting machine key: chacha20poly1305: message authentication failed" > headscale_1 | 2024/04/29 13:43:36 http: response.WriteHeader on hijacked connection from github.com/juanfont/headscale/hscontrol.(*Headscale).NoiseUpgradeHandler (noise.go:84) > headscale_1 | 2024/04/29 13:43:36 http: response.Write on hijacked connection from fmt.Fprintln (print.go:305) > ``` > > ### Expected Behavior > just like before :-D it should work > > unfortunately I can no longer downgrade without further ado to test it further > > ### Steps To Reproduce > 1. headscale set up so that oidc runs via authentik (< 2024) > 2. authentik update, which offline_access needs > 3. connect to headscale, works but exit node does not work (no internet) > 4. exit-node reauth, internet works again-> until the next headscale restart or a time? > > ### Environment > - OS:ubuntu 22.04 > - Headscale version: 0.23.0-alpha9 > - Tailscale version: 1.64.0 > ### Runtime environment > * [x] Headscale is behind a (reverse) proxy[x] Headscale runs in a container > > ### Anything else? > that's just a guess, but i updated authentik at the weekend and it hasn't worked since then Hi, im trying to setup headscale with authentik but so far i havent been able to, whenever i try to start the headscale server i get an error saying: `headscale | 2025-04-20T22:38:43Z FTL home/runner/work/headscale/headscale/cmd/headscale/cli/serve.go:24 > Error initializing error="creating OIDC provider from issuer config: 404 Not Found` could u post a brief explanation of how u did it?
Author
Owner

@javito1081 commented on GitHub (Apr 21, 2025):

Had this exact same problem. For authentik, you'd need an additional extra_params and include the offline_access scope. Make sure to actually include the scope in authentik OAuth2 provider side as well.

You would also need to set a Signing Key (you can use the self-signed one) for the OAuth2 provider of authentik to use RS256 for signing which I think is required for Headscale.

Here's a sample portion of the headscale config for the oidc:

oidc:
  ...
  scope:
    - openid
    - profile
    - email
    - offline_access
  extra_params:
    prompt: consent

which url did u set for the issuer? could u post a brief explanation of how u set headscale up with authentik?

@javito1081 commented on GitHub (Apr 21, 2025): > Had this exact same problem. For authentik, you'd need an additional `extra_params` and include the `offline_access` scope. Make sure to actually include the scope in authentik OAuth2 provider side as well. > > You would also need to set a Signing Key (you can use the self-signed one) for the OAuth2 provider of authentik to use RS256 for signing which I think is required for Headscale. > > Here's a sample portion of the headscale config for the oidc: > > ``` > oidc: > ... > scope: > - openid > - profile > - email > - offline_access > extra_params: > prompt: consent > ``` which url did u set for the issuer? could u post a brief explanation of how u set headscale up with authentik?
Author
Owner

@javito1081 commented on GitHub (Apr 21, 2025):

So i manage to finally get it working, at least headscale is now up, but when i go to https://headscale.mydomain.com i just get a 404 screen, i dont get to the authentik login page, i feel im missing something i just dont know what it is, im using ngnix proxy manager for headscale and i dont have anything setup on the advanced tab, dont know if i have to or not

@javito1081 commented on GitHub (Apr 21, 2025): So i manage to finally get it working, at least headscale is now up, but when i go to https://headscale.mydomain.com i just get a 404 screen, i dont get to the authentik login page, i feel im missing something i just dont know what it is, im using ngnix proxy manager for headscale and i dont have anything setup on the advanced tab, dont know if i have to or not
Author
Owner

@nblock commented on GitHub (Apr 21, 2025):

[..] but when i go to https://headscale.mydomain.com i just get a 404 screen, i dont get to the authentik login page

The tailscale client will redirect you to its login page when you register a new client.

@nblock commented on GitHub (Apr 21, 2025): > [..] but when i go to https://headscale.mydomain.com i just get a 404 screen, i dont get to the authentik login page The tailscale client will redirect you to its login page when you register a new client.
Author
Owner

@javito1081 commented on GitHub (Apr 21, 2025):

ya i got it working now hehe, i realize that when the clients log in for the first time is when they get the redirection site to log in, after that if im already logged in, i get a 404 :-)

@javito1081 commented on GitHub (Apr 21, 2025): ya i got it working now hehe, i realize that when the clients log in for the first time is when they get the redirection site to log in, after that if im already logged in, i get a 404 :-)
Author
Owner

@javito1081 commented on GitHub (Apr 22, 2025):

[..] but when i go to https://headscale.mydomain.com i just get a 404 screen, i dont get to the authentik login page

The tailscale client will redirect you to its login page when you register a new client.

have you manage to get the allowed_groups working? i created a group in the authentik interface and put that grp into the config but everyone is still able to authenticate, its not stopping anyone from doing it

config.yaml

#   # Note: Groups from keycloak have a leading '/'
   allowed_groups:
     - VPN
@javito1081 commented on GitHub (Apr 22, 2025): > > [..] but when i go to https://headscale.mydomain.com i just get a 404 screen, i dont get to the authentik login page > > The tailscale client will redirect you to its login page when you register a new client. have you manage to get the allowed_groups working? i created a group in the authentik interface and put that grp into the config but everyone is still able to authenticate, its not stopping anyone from doing it config.yaml ``` # # Note: Groups from keycloak have a leading '/' allowed_groups: - VPN ```
Author
Owner

@masterwishx commented on GitHub (Apr 22, 2025):

[..] but when i go to https://headscale.mydomain.com i just get a 404 screen, i dont get to the authentik login page

The tailscale client will redirect you to its login page when you register a new client.

have you manage to get the allowed_groups working? i created a group in the authentik interface and put that grp into the config but everyone is still able to authenticate, its not stopping anyone from doing it

config.yaml

#   # Note: Groups from keycloak have a leading '/'
   allowed_groups:
     - VPN

What your config in authentik for this group?

@masterwishx commented on GitHub (Apr 22, 2025): > > > [..] but when i go to https://headscale.mydomain.com i just get a 404 screen, i dont get to the authentik login page > > > > > > The tailscale client will redirect you to its login page when you register a new client. > > have you manage to get the allowed_groups working? i created a group in the authentik interface and put that grp into the config but everyone is still able to authenticate, its not stopping anyone from doing it > > config.yaml > > ``` > # # Note: Groups from keycloak have a leading '/' > allowed_groups: > - VPN > ``` What your config in authentik for this group?
Author
Owner

@javito1081 commented on GitHub (Apr 22, 2025):

[..] but when i go to https://headscale.mydomain.com i just get a 404 screen, i dont get to the authentik login page

The tailscale client will redirect you to its login page when you register a new client.

have you manage to get the allowed_groups working? i created a group in the authentik interface and put that grp into the config but everyone is still able to authenticate, its not stopping anyone from doing it
config.yaml

#   # Note: Groups from keycloak have a leading '/'
   allowed_groups:
     - VPN

What your config in authentik for this group?

Only thing i did on authentik for this was to create a group and fill it with users, didn't do anything else, is there something aditional i should be doing?

@javito1081 commented on GitHub (Apr 22, 2025): > > > > [..] but when i go to https://headscale.mydomain.com i just get a 404 screen, i dont get to the authentik login page > > > > > > > > > The tailscale client will redirect you to its login page when you register a new client. > > > > > > have you manage to get the allowed_groups working? i created a group in the authentik interface and put that grp into the config but everyone is still able to authenticate, its not stopping anyone from doing it > > config.yaml > > ``` > > # # Note: Groups from keycloak have a leading '/' > > allowed_groups: > > - VPN > > ``` > > What your config in authentik for this group? Only thing i did on authentik for this was to create a group and fill it with users, didn't do anything else, is there something aditional i should be doing?
Author
Owner

@masterwishx commented on GitHub (Apr 22, 2025):

[..] but when i go to https://headscale.mydomain.com i just get a 404 screen, i dont get to the authentik login page

The tailscale client will redirect you to its login page when you register a new client.

have you manage to get the allowed_groups working? i created a group in the authentik interface and put that grp into the config but everyone is still able to authenticate, its not stopping anyone from doing it
config.yaml

#   # Note: Groups from keycloak have a leading '/'
   allowed_groups:
     - VPN

What your config in authentik for this group?

Only thing i did on authentik for this was to create a group and fill it with users, didn't do anything else, is there something aditional i should be doing?

Sure you need to link group to oidc of headscale login

@masterwishx commented on GitHub (Apr 22, 2025): > > > > > [..] but when i go to https://headscale.mydomain.com i just get a 404 screen, i dont get to the authentik login page > > > > > > > > > > > > The tailscale client will redirect you to its login page when you register a new client. > > > > > > > > > have you manage to get the allowed_groups working? i created a group in the authentik interface and put that grp into the config but everyone is still able to authenticate, its not stopping anyone from doing it > > > config.yaml > > > ``` > > > # # Note: Groups from keycloak have a leading '/' > > > allowed_groups: > > > - VPN > > > ``` > > > > > > What your config in authentik for this group? > > Only thing i did on authentik for this was to create a group and fill it with users, didn't do anything else, is there something aditional i should be doing? Sure you need to link group to oidc of headscale login
Author
Owner

@javito1081 commented on GitHub (Apr 22, 2025):

[..] but when i go to https://headscale.mydomain.com i just get a 404 screen, i dont get to the authentik login page

The tailscale client will redirect you to its login page when you register a new client.

have you manage to get the allowed_groups working? i created a group in the authentik interface and put that grp into the config but everyone is still able to authenticate, its not stopping anyone from doing it
config.yaml

#   # Note: Groups from keycloak have a leading '/'
   allowed_groups:
     - VPN

What your config in authentik for this group?

Only thing i did on authentik for this was to create a group and fill it with users, didn't do anything else, is there something aditional i should be doing?

Sure you need to link group to oidc of headscale login

How do it do that?

@javito1081 commented on GitHub (Apr 22, 2025): > > > > > > [..] but when i go to https://headscale.mydomain.com i just get a 404 screen, i dont get to the authentik login page > > > > > > > > > > > > > > > The tailscale client will redirect you to its login page when you register a new client. > > > > > > > > > > > > have you manage to get the allowed_groups working? i created a group in the authentik interface and put that grp into the config but everyone is still able to authenticate, its not stopping anyone from doing it > > > > config.yaml > > > > ``` > > > > # # Note: Groups from keycloak have a leading '/' > > > > allowed_groups: > > > > - VPN > > > > ``` > > > > > > > > > What your config in authentik for this group? > > > > > > Only thing i did on authentik for this was to create a group and fill it with users, didn't do anything else, is there something aditional i should be doing? > > Sure you need to link group to oidc of headscale login How do it do that?
Author
Owner

@masterwishx commented on GitHub (Apr 23, 2025):

Image

@masterwishx commented on GitHub (Apr 23, 2025): ![Image](https://github.com/user-attachments/assets/a1f46461-e007-43b0-bb78-f7eeca086493)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#699