I think it's probably a misconfiguration on my end, but after trying different settings that work for other clients with no luck, I'm reporting this in case someone knows what's going on..
Originally created by @polamoros on GitHub (May 4, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/671
I think it's probably a misconfiguration on my end, but after trying different settings that work for other clients with no luck, I'm reporting this in case someone knows what's going on..
My authelia client configuration
```
- client_id: 'pangolin'
client_name: 'Pangolin'
client_secret: '$argon2id$v=ENCODED_STRING'
public: false
authorization_policy: 'two_factor'
redirect_uris:
- 'https://sub.my_domain.com/auth/idp/1/oidc/callback'
scopes:
- 'openid'
- 'profile'
- 'email'
userinfo_signed_response_alg: 'none'
token_endpoint_auth_method: 'client_secret_basic'
```
Identity Provider config in Pangolin
<img width="1250" alt="Image" src="https://github.com/user-attachments/assets/625e69f3-60a0-4175-8445-0c863ee4b05c" />
I keep getting `User identifier not found in the ID token`
<img width="481" alt="Image" src="https://github.com/user-attachments/assets/44fadff9-267a-452a-985a-718c2252abaa" />
and Pangolin logs
```
2025-05-04T20:13:48.822Z [debug]: {"data":{"valid":true},"success":true,"error":false,"message":"Access allowed","status":200}
```
Changing Identifier Path to preferred_username worked for me in Authentik.
<!-- gh-comment-id:2849404265 -->
@seamon67 commented on GitHub (May 4, 2025):
Changing Identifier Path to preferred_username worked for me in Authentik.
@arunabh-hazarika thanks! I tested this already with no luck.. thanks anyways :)
<!-- gh-comment-id:2849406940 -->
@polamoros commented on GitHub (May 4, 2025):
@arunabh-hazarika thanks! I tested this already with no luck.. thanks anyways :)
@boomam Curious - if you add a trailing slash to the URLs, do you see any difference?
<!-- gh-comment-id:2849748800 -->
@miloschwartz commented on GitHub (May 5, 2025):
@boomam Curious - if you add a trailing slash to the URLs, do you see any difference?
@boomam Curious - if you add a trailing slash to the URLs, do you see any difference?
Yes, but only a different error -
There was a problem connecting to Authelia. Please contact your administrator.
An error occurred
<!-- gh-comment-id:2851422996 -->
@boomam commented on GitHub (May 5, 2025):
> [@boomam](https://github.com/boomam) Curious - if you add a trailing slash to the URLs, do you see any difference?
Yes, but only a different error -
```
There was a problem connecting to Authelia. Please contact your administrator.
An error occurred
```
We will log the full token to debug logs in the next version so this is stuff is easier to debug for the first time.
<!-- gh-comment-id:2852504624 -->
@miloschwartz commented on GitHub (May 5, 2025):
If you're still getting the user identifier not found in the token error then it's likely there is no claim for `email` available at the path. This seems to be a list of claims for Authelia: https://www.authelia.com/integration/openid-connect/openid-connect-1.0-claims/
We will log the full token to debug logs in the next version so this is stuff is easier to debug for the first time.
Can you expand your Authelia theory in more detail please?
Are you saying that perhaps Pangolin require a custom claims profile?
<!-- gh-comment-id:2852516968 -->
@boomam commented on GitHub (May 5, 2025):
Can you expand your Authelia theory in more detail please?
Are you saying that perhaps Pangolin require a custom claims profile?
I don't know why this wouldn't be included in the claims with Authelia though.
<!-- gh-comment-id:2852536830 -->
@miloschwartz commented on GitHub (May 5, 2025):
If the Identifier Path is set to email, then the email has to be available like below:
```json
{
...
"email": "user@example.com"
}
```
You can test this with JMESPath [here](https://jmespath.org/).
I don't know why this wouldn't be included in the claims with Authelia though.
Ordinary it would/does, it's a common claim type.
I'll check configs and compare, as I know some OIDC clients (ironically, Cloudflare...) needed a custom claims profile.
I'll let you know what I find as it would be worth adding a known working config to the docs, if it indeed an Authelia issue.
<!-- gh-comment-id:2852560904 -->
@boomam commented on GitHub (May 5, 2025):
Ordinary it would/does, it's a common claim type.
I'll check configs and compare, as I know some OIDC clients (ironically, Cloudflare...) needed a custom claims profile.
I'll let you know what I find as it would be worth adding a known working config to the docs, if it indeed an Authelia issue.
@miloschwartz i've tested with a custom claims profile, along with ensuring that 'email' was part of the scope in Authelia - the issue remains.
<!-- gh-comment-id:2856095839 -->
@boomam commented on GitHub (May 6, 2025):
@miloschwartz i've tested with a custom claims profile, along with ensuring that 'email' was part of the scope in Authelia - the issue remains.
@james-d-elliott commented on GitHub (May 6, 2025):
This is caused due to authelia implementing claims hydration in the conformant way where claims only exist in the appropriate place. Since Pangolin does not use the implicit flow solely returning an ID Token the ID Token, and Pangolin is not requesting the claims be present in the ID Token, these claims shouldn't be present in the ID Token and should instead be retrieved using the Access Token from the UserInfo Endpoint.
Please feel free to take a look at a Blog Article (specifically claims availability) for a mid level explanation on all of these nuances with the spec which will assist with resolving this bug. We have a formal workaround for clients that do not properly support the spec documented here which has been confirmed to work in this instance.
<!-- gh-comment-id:2856395974 -->
@james-d-elliott commented on GitHub (May 6, 2025):
This is caused due to authelia implementing claims hydration in the conformant way where claims only exist in the appropriate place. Since Pangolin does not use the implicit flow solely returning an ID Token the ID Token, and Pangolin is not requesting the claims be present in the ID Token, these claims shouldn't be present in the ID Token and should instead be retrieved using the Access Token from the UserInfo Endpoint.
Please feel free to take a look at a [Blog Article](https://www.authelia.com/blog/technical-openid-connect-1.0-nuances/) (specifically claims availability) for a mid level explanation on all of these nuances with the spec which will assist with resolving this bug. We have a formal workaround for clients that do not properly support the spec documented [here](https://www.authelia.com/integration/openid-connect/openid-connect-1.0-claims/#restore-functionality-prior-to-claims-parameter) which has been confirmed to work in this instance.
@james-d-elliott Thanks for jumping in here. Will look at those resources and see what I can do, but glad there is a temporary work around.
<!-- gh-comment-id:2856828910 -->
@miloschwartz commented on GitHub (May 7, 2025):
@james-d-elliott Thanks for jumping in here. Will look at those resources and see what I can do, but glad there is a temporary work around.
@james-d-elliott commented on GitHub (May 7, 2025):
No worries, let me know if I can clarify anything. It is rough but fairly sure it'll make sense. One thing not noted is Authelia supports requesting just the openid scope and extending the claims in the ID Token via the claims parameter provided the client registration permits the client to request a scope that has access to the requested claim.
<!-- gh-comment-id:2856840864 -->
@james-d-elliott commented on GitHub (May 7, 2025):
No worries, let me know if I can clarify anything. It is rough but fairly sure it'll make sense. One thing not noted is Authelia supports requesting just the `openid` scope and extending the claims in the ID Token via the claims parameter provided the client registration permits the client to request a scope that has access to the requested claim.
@miloschwartz
Forgot to come back to this last night - the new claims profile did actually work, but as it was a configmap change (in my case) it didn't apply to the active pods running Authelia. A daemonset restart resolved that.
For others having the issue, there is a new guide on the Authelia doc site that covers the steps to resolve.
<!-- gh-comment-id:2858409511 -->
@boomam commented on GitHub (May 7, 2025):
@miloschwartz
Forgot to come back to this last night - the new claims profile did actually work, but as it was a configmap change (in my case) it didn't apply to the active pods running Authelia. A daemonset restart resolved that.
For others having the issue, there is a new guide on the [Authelia doc site](https://www.authelia.com/integration/openid-connect/pangolin/) that covers the steps to resolve.
My role mapping path is contains(groups, 'admins') && 'Admin' || 'Member' and org path contains(groups, 'users') which normally would cover it.
Any help would be appreciated.
Thanks!
<!-- gh-comment-id:2907088174 -->
@C8opmBM commented on GitHub (May 24, 2025):
Hello and I don't know if this has been fixed, I tried all combinations, provisioning on/off, somehow I'm getting this error every time:
`TypeError: contains() expected argument 1 to be type string,array but received type null instead.`
My authelia users are like these:
```
users:
superuser:
disabled: false
displayname: "my name"
password: "$argon2id$v=....
email: hello@email.net
groups:
- 'admins'
- 'users'
```
My role mapping path is `contains(groups, 'admins') && 'Admin' || 'Member'` and org path `contains(groups, 'users')` which normally would cover it.
Any help would be appreciated.
Thanks!
My guess is this is related to the shape of the token not being what you expect. Maybe the groups key is null/undefined at the expected location?
You can try to inspect the payload by setting Pangolin's log level to debug and trying to log in with the IdP with auto provision on. It should print the payload to the logs.
<!-- gh-comment-id:2908323280 -->
@miloschwartz commented on GitHub (May 26, 2025):
My guess is this is related to the shape of the token not being what you expect. Maybe the `groups` key is null/undefined at the expected location?
You can try to inspect the payload by setting Pangolin's log level to debug and trying to log in with the IdP with auto provision on. It should print the payload to the logs.
Somehow it cannot assign the role based on groups:
2025-05-26T09:06:48.204Z [debug]: ID token {"idToken":"eyJhb...fe83uc"}
2025-05-26T09:06:48.204Z [debug]: ID token claims {"claims":{"amr":["pwd","kba","otp","mfa"],"at_hash":"qMXhrk6lV6ZWxUCaPjaIsQ","aud":["pangolin"],"auth_time":1748250807,"azp":"pangolin","exp":1748254410,"iat":1748250810,"iss":"https://auth.myvps.com","jti":"272bf0cb-1fc2-480b-b7bb-dc9ed96a3117","sub":"45916a27-455a-4864-be34-368ba5fab178"}}
2025-05-26T09:06:48.205Z [debug]: User identifier {"userIdentifier":"45916a27-455a-4864-be34-368ba5fab178"}
2025-05-26T09:06:48.205Z [debug]: User email {"email":null}
2025-05-26T09:06:48.205Z [debug]: User name {"name":null}
2025-05-26T09:06:48.209Z [debug]: Hydrated Org Mapping {"hydratedOrgMapping":"contains(groups, 'users')"}
2025-05-26T09:06:48.210Z [error]: TypeError: contains() expected argument 1 to be type string,array but received type null instead.
Stack: Error: TypeError: contains() expected argument 1 to be type string,array but received type null instead.
at Runtime._validateArgs (/app/node_modules/jmespath/jmespath.js:1257:23)
at Runtime.callFunction (/app/node_modules/jmespath/jmespath.js:1214:12)
at TreeInterpreter.visit (/app/node_modules/jmespath/jmespath.js:1068:35)
at TreeInterpreter.search (/app/node_modules/jmespath/jmespath.js:866:23)
at Object.search (/app/node_modules/jmespath/jmespath.js:1665:26)
at gg (file:///app/dist/server.mjs:31:140897)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
What I managed to do is to set the default role mapping 'Admin' and organization mapping 'myorg' and this way I'm provisioned with an Admin (with a long uuid username as described in https://github.com/fosrl/pangolin/issues/762).
So there's no way to autoselect the role based on the groups within Authelia (at least in my case) and the username and email are not fetched. Still, I'm glad I made it work so far. Thanks.
2025-05-26T09:23:04.208Z [debug]: ID token {"idToken":"eyJhbGci...xe3Ok"}
2025-05-26T09:23:04.208Z [debug]: ID token claims {"claims":{"amr":["pwd","kba","otp","mfa"],"at_hash":"kZLES32mI0__l0Mqp4dWyA","aud":["pangolin"],"auth_time":1748251783,"azp":"pangolin","exp":1748255387,"iat":1748251787,"iss":"https://auth.myvps.com","jti":"ed111739-e46c-4fa9-b66b-3a7698f3a972","sub":"45916a27-455a-4864-be34-368ba5fab178"}}
2025-05-26T09:23:04.209Z [debug]: User identifier {"userIdentifier":"45916a27-455a-4864-be34-368ba5fab178"}
2025-05-26T09:23:04.209Z [debug]: User email {"email":null}
2025-05-26T09:23:04.209Z [debug]: User name {"name":null}
2025-05-26T09:23:04.217Z [debug]: Hydrated Org Mapping {"hydratedOrgMapping":"'myorg'"}
2025-05-26T09:23:04.218Z [debug]: Extraced Org ID {"orgId":"myorg"}
2025-05-26T09:23:04.218Z [debug]: Role Mapping {"roleMapping":"'Admin'"}
<!-- gh-comment-id:2909088671 -->
@C8opmBM commented on GitHub (May 26, 2025):
Somehow it cannot assign the role based on groups:
```
2025-05-26T09:06:48.204Z [debug]: ID token {"idToken":"eyJhb...fe83uc"}
2025-05-26T09:06:48.204Z [debug]: ID token claims {"claims":{"amr":["pwd","kba","otp","mfa"],"at_hash":"qMXhrk6lV6ZWxUCaPjaIsQ","aud":["pangolin"],"auth_time":1748250807,"azp":"pangolin","exp":1748254410,"iat":1748250810,"iss":"https://auth.myvps.com","jti":"272bf0cb-1fc2-480b-b7bb-dc9ed96a3117","sub":"45916a27-455a-4864-be34-368ba5fab178"}}
2025-05-26T09:06:48.205Z [debug]: User identifier {"userIdentifier":"45916a27-455a-4864-be34-368ba5fab178"}
2025-05-26T09:06:48.205Z [debug]: User email {"email":null}
2025-05-26T09:06:48.205Z [debug]: User name {"name":null}
2025-05-26T09:06:48.209Z [debug]: Hydrated Org Mapping {"hydratedOrgMapping":"contains(groups, 'users')"}
2025-05-26T09:06:48.210Z [error]: TypeError: contains() expected argument 1 to be type string,array but received type null instead.
Stack: Error: TypeError: contains() expected argument 1 to be type string,array but received type null instead.
at Runtime._validateArgs (/app/node_modules/jmespath/jmespath.js:1257:23)
at Runtime.callFunction (/app/node_modules/jmespath/jmespath.js:1214:12)
at TreeInterpreter.visit (/app/node_modules/jmespath/jmespath.js:1068:35)
at TreeInterpreter.search (/app/node_modules/jmespath/jmespath.js:866:23)
at Object.search (/app/node_modules/jmespath/jmespath.js:1665:26)
at gg (file:///app/dist/server.mjs:31:140897)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
```
What I managed to do is to set the default role mapping 'Admin' and organization mapping 'myorg' and this way I'm provisioned with an Admin (with a long uuid username as described in https://github.com/fosrl/pangolin/issues/762).
So there's no way to autoselect the role based on the groups within Authelia (at least in my case) and the username and email are not fetched. Still, I'm glad I made it work so far. Thanks.
```
2025-05-26T09:23:04.208Z [debug]: ID token {"idToken":"eyJhbGci...xe3Ok"}
2025-05-26T09:23:04.208Z [debug]: ID token claims {"claims":{"amr":["pwd","kba","otp","mfa"],"at_hash":"kZLES32mI0__l0Mqp4dWyA","aud":["pangolin"],"auth_time":1748251783,"azp":"pangolin","exp":1748255387,"iat":1748251787,"iss":"https://auth.myvps.com","jti":"ed111739-e46c-4fa9-b66b-3a7698f3a972","sub":"45916a27-455a-4864-be34-368ba5fab178"}}
2025-05-26T09:23:04.209Z [debug]: User identifier {"userIdentifier":"45916a27-455a-4864-be34-368ba5fab178"}
2025-05-26T09:23:04.209Z [debug]: User email {"email":null}
2025-05-26T09:23:04.209Z [debug]: User name {"name":null}
2025-05-26T09:23:04.217Z [debug]: Hydrated Org Mapping {"hydratedOrgMapping":"'myorg'"}
2025-05-26T09:23:04.218Z [debug]: Extraced Org ID {"orgId":"myorg"}
2025-05-26T09:23:04.218Z [debug]: Role Mapping {"roleMapping":"'Admin'"}
```
<!-- gh-comment-id:2910972008 -->
@miloschwartz commented on GitHub (May 27, 2025):
Based on these claims from your logs, there is no groups key in the payload:
```json
{
"claims": {
"amr": [
"pwd",
"kba",
"otp",
"mfa"
],
"at_hash": "kZLES32mI0__l0Mqp4dWyA",
"aud": [
"pangolin"
],
"auth_time": 1748251783,
"azp": "pangolin",
"exp": 1748255387,
"iat": 1748251787,
"iss": "https://auth.myvps.com",
"jti": "ed111739-e46c-4fa9-b66b-3a7698f3a972",
"sub": "45916a27-455a-4864-be34-368ba5fab178"
}
}
```
Thanks @miloschwartz
I don't know if there's anything to do at my end, as I'm using the standard User / Password File configuration template in authelia, which does include groups key.
<!-- gh-comment-id:2911428651 -->
@C8opmBM commented on GitHub (May 27, 2025):
Thanks @miloschwartz
I don't know if there's anything to do at my end, as I'm using the standard [User / Password File](https://www.authelia.com/reference/guides/passwords/#yaml-format) configuration template in authelia, which does include `groups` key.
@james-d-elliott commented on GitHub (May 27, 2025):
The ID Token only containing those claims is a completely expected behavior. An escape hatch exists in Authelia for the purpose of working around clients which don't handle this part of the spec correctly as described here and here (actual link).
The fundamental issue is that no claims have been requested (i.e. authorization claims parameter) to be present in the ID Token. The only available claims are accessible are via the Access Token scope (i.e. authorization scope parameter), which is not being utilized at the designated UserInfo endpoint to obtain the claims, where these claims should be expected to be present in a scenario that doesn't use the claims parameter, and is not an Implicit Flow resulting in solely and ID Token (i.e. no Access Token).
OpenID Connect Clients use scope values, as defined in Section 3.3 of OAuth 2.0 [RFC6749], to specify what access privileges are being requested for Access Tokens. The scopes associated with Access Tokens determine what resources will be available when they are used to access OAuth 2.0 protected endpoints. Protected Resource endpoints MAY perform different actions and return different information based on the scope values and other parameters used when requesting the presented Access Token.
The Claims requested by the profile, email, address, and phone scope values are returned from the UserInfo Endpoint, as described in Section 5.3.2, when a response_type value is used that results in an Access Token being issued. However, when no Access Token is issued (which is the case for the response_type value id_token), the resulting Claims are returned in the ID Token.
<!-- gh-comment-id:2911537319 -->
@james-d-elliott commented on GitHub (May 27, 2025):
The ID Token only containing those claims is a completely expected behavior. An escape hatch exists in Authelia for the purpose of working around clients which don't handle this part of the spec correctly as described [here](https://github.com/fosrl/pangolin/issues/671#issuecomment-2856395974) and [here](https://github.com/fosrl/pangolin/issues/671#issuecomment-2858409511) ([actual link](https://www.authelia.com/integration/openid-connect/openid-connect-1.0-claims/#restore-functionality-prior-to-claims-parameter)).
The fundamental issue is that no claims have been requested (i.e. authorization `claims` parameter) to be present in the ID Token. The only available claims are accessible are via the Access Token scope (i.e. authorization `scope` parameter), which is not being utilized at the designated UserInfo endpoint to obtain the claims, where these claims should be expected to be present in a scenario that doesn't use the `claims` parameter, and is not an Implicit Flow resulting in solely and ID Token (i.e. no Access Token).
From [5.4. Requesting Claims using Scope Values](https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims):
> OpenID Connect Clients use scope values, as defined in Section 3.3 of [OAuth 2.0](https://openid.net/specs/openid-connect-core-1_0.html#RFC6749) [RFC6749], to specify what access privileges are being requested for Access Tokens. The scopes associated with Access Tokens determine what resources will be available when they are used to access OAuth 2.0 protected endpoints. Protected Resource endpoints MAY perform different actions and return different information based on the scope values and other parameters used when requesting the presented Access Token.
> The Claims requested by the profile, email, address, and phone scope values are returned from the UserInfo Endpoint, as described in [Section 5.3.2](https://openid.net/specs/openid-connect-core-1_0.html#UserInfoResponse), when a response_type value is used that results in an Access Token being issued. However, when no Access Token is issued (which is the case for the response_type value id_token), the resulting Claims are returned in the ID Token.
I'm sorry, maybe I want a bit much and understand to little... I managed to setup pangolin and authelia. I understand that pangolin is not utilizing the claims with OIDC to spec and that causes some problems. Now I use the "sub" claim to ID users, which of course leads to the users having incomprehensible names. up until here, I think I understand what happens.
What I dont understand is how to work around this and get a readable name from authelia in pangolin.
Can someone help me out with some instructions?
<!-- gh-comment-id:2927517628 -->
@momsi commented on GitHub (Jun 1, 2025):
I'm sorry, maybe I want a bit much and understand to little... I managed to setup pangolin and authelia. I understand that pangolin is not utilizing the claims with OIDC to spec and that causes some problems. Now I use the "sub" claim to ID users, which of course leads to the users having incomprehensible names. up until here, I think I understand what happens.
What I dont understand is how to work around this and get a readable name from authelia in pangolin.
Can someone help me out with some instructions?
@github-actions[bot] commented on GitHub (Jun 16, 2025):
This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
<!-- gh-comment-id:2974797452 -->
@github-actions[bot] commented on GitHub (Jun 16, 2025):
This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
@github-actions[bot] commented on GitHub (Jun 30, 2025):
This issue has been automatically closed due to inactivity. If you believe this is still relevant, please open a new issue with up-to-date information.
<!-- gh-comment-id:3017344926 -->
@github-actions[bot] commented on GitHub (Jun 30, 2025):
This issue has been automatically closed due to inactivity. If you believe this is still relevant, please open a new issue with up-to-date information.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @polamoros on GitHub (May 4, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/671
I think it's probably a misconfiguration on my end, but after trying different settings that work for other clients with no luck, I'm reporting this in case someone knows what's going on..
My authelia client configuration
Identity Provider config in Pangolin
I keep getting
User identifier not found in the ID tokenand Pangolin logs
@seamon67 commented on GitHub (May 4, 2025):
Changing Identifier Path to preferred_username worked for me in Authentik.
@polamoros commented on GitHub (May 4, 2025):
@arunabh-hazarika thanks! I tested this already with no luck.. thanks anyways :)
@boomam commented on GitHub (May 5, 2025):
Same issue here, using the following settings -
@miloschwartz commented on GitHub (May 5, 2025):
@boomam Curious - if you add a trailing slash to the URLs, do you see any difference?
@boomam commented on GitHub (May 5, 2025):
Yes, but only a different error -
@boomam commented on GitHub (May 5, 2025):
Yes.
@miloschwartz commented on GitHub (May 5, 2025):
If you're still getting the user identifier not found in the token error then it's likely there is no claim for
emailavailable at the path. This seems to be a list of claims for Authelia: https://www.authelia.com/integration/openid-connect/openid-connect-1.0-claims/We will log the full token to debug logs in the next version so this is stuff is easier to debug for the first time.
@boomam commented on GitHub (May 5, 2025):
Can you expand your Authelia theory in more detail please?
Are you saying that perhaps Pangolin require a custom claims profile?
@miloschwartz commented on GitHub (May 5, 2025):
If the Identifier Path is set to email, then the email has to be available like below:
You can test this with JMESPath here.
I don't know why this wouldn't be included in the claims with Authelia though.
@boomam commented on GitHub (May 5, 2025):
Ordinary it would/does, it's a common claim type.
I'll check configs and compare, as I know some OIDC clients (ironically, Cloudflare...) needed a custom claims profile.
I'll let you know what I find as it would be worth adding a known working config to the docs, if it indeed an Authelia issue.
@boomam commented on GitHub (May 6, 2025):
@miloschwartz i've tested with a custom claims profile, along with ensuring that 'email' was part of the scope in Authelia - the issue remains.
@james-d-elliott commented on GitHub (May 6, 2025):
This is caused due to authelia implementing claims hydration in the conformant way where claims only exist in the appropriate place. Since Pangolin does not use the implicit flow solely returning an ID Token the ID Token, and Pangolin is not requesting the claims be present in the ID Token, these claims shouldn't be present in the ID Token and should instead be retrieved using the Access Token from the UserInfo Endpoint.
Please feel free to take a look at a Blog Article (specifically claims availability) for a mid level explanation on all of these nuances with the spec which will assist with resolving this bug. We have a formal workaround for clients that do not properly support the spec documented here which has been confirmed to work in this instance.
@miloschwartz commented on GitHub (May 7, 2025):
@james-d-elliott Thanks for jumping in here. Will look at those resources and see what I can do, but glad there is a temporary work around.
@james-d-elliott commented on GitHub (May 7, 2025):
No worries, let me know if I can clarify anything. It is rough but fairly sure it'll make sense. One thing not noted is Authelia supports requesting just the
openidscope and extending the claims in the ID Token via the claims parameter provided the client registration permits the client to request a scope that has access to the requested claim.@boomam commented on GitHub (May 7, 2025):
@miloschwartz
Forgot to come back to this last night - the new claims profile did actually work, but as it was a configmap change (in my case) it didn't apply to the active pods running Authelia. A daemonset restart resolved that.
For others having the issue, there is a new guide on the Authelia doc site that covers the steps to resolve.
@AstralDestiny commented on GitHub (May 22, 2025):
Well the Calvary has arrived.
@C8opmBM commented on GitHub (May 24, 2025):
Hello and I don't know if this has been fixed, I tried all combinations, provisioning on/off, somehow I'm getting this error every time:
TypeError: contains() expected argument 1 to be type string,array but received type null instead.My authelia users are like these:
My role mapping path is
contains(groups, 'admins') && 'Admin' || 'Member'and org pathcontains(groups, 'users')which normally would cover it.Any help would be appreciated.
Thanks!
@miloschwartz commented on GitHub (May 26, 2025):
My guess is this is related to the shape of the token not being what you expect. Maybe the
groupskey is null/undefined at the expected location?You can try to inspect the payload by setting Pangolin's log level to debug and trying to log in with the IdP with auto provision on. It should print the payload to the logs.
@C8opmBM commented on GitHub (May 26, 2025):
Somehow it cannot assign the role based on groups:
What I managed to do is to set the default role mapping 'Admin' and organization mapping 'myorg' and this way I'm provisioned with an Admin (with a long uuid username as described in https://github.com/fosrl/pangolin/issues/762).
So there's no way to autoselect the role based on the groups within Authelia (at least in my case) and the username and email are not fetched. Still, I'm glad I made it work so far. Thanks.
@miloschwartz commented on GitHub (May 27, 2025):
Based on these claims from your logs, there is no groups key in the payload:
@C8opmBM commented on GitHub (May 27, 2025):
Thanks @miloschwartz
I don't know if there's anything to do at my end, as I'm using the standard User / Password File configuration template in authelia, which does include
groupskey.@james-d-elliott commented on GitHub (May 27, 2025):
The ID Token only containing those claims is a completely expected behavior. An escape hatch exists in Authelia for the purpose of working around clients which don't handle this part of the spec correctly as described here and here (actual link).
The fundamental issue is that no claims have been requested (i.e. authorization
claimsparameter) to be present in the ID Token. The only available claims are accessible are via the Access Token scope (i.e. authorizationscopeparameter), which is not being utilized at the designated UserInfo endpoint to obtain the claims, where these claims should be expected to be present in a scenario that doesn't use theclaimsparameter, and is not an Implicit Flow resulting in solely and ID Token (i.e. no Access Token).From 5.4. Requesting Claims using Scope Values:
@momsi commented on GitHub (Jun 1, 2025):
I'm sorry, maybe I want a bit much and understand to little... I managed to setup pangolin and authelia. I understand that pangolin is not utilizing the claims with OIDC to spec and that causes some problems. Now I use the "sub" claim to ID users, which of course leads to the users having incomprehensible names. up until here, I think I understand what happens.
What I dont understand is how to work around this and get a readable name from authelia in pangolin.
Can someone help me out with some instructions?
@github-actions[bot] commented on GitHub (Jun 16, 2025):
This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
@github-actions[bot] commented on GitHub (Jun 30, 2025):
This issue has been automatically closed due to inactivity. If you believe this is still relevant, please open a new issue with up-to-date information.