github-starred/pangolin
2
0
Fork 0
mirror of https://github.com/fosrl/pangolin.git synced 2026-05-21 17:20:36 -05:00
Code Issues 860 Packages Projects Releases 74 Wiki Activity

[GH-ISSUE #671] Issue Setting Up Authelia as OIDC Provider #10322

New Issue
Closed
opened 2026-05-06 13:33:24 -05:00 by GiteaMirror · 25 comments
GiteaMirror commented 2026-05-06 13:33:24 -05:00
Owner
Copy Link

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
Image

I keep getting User identifier not found in the ID token
Image

and Pangolin logs

2025-05-04T20:13:48.822Z [debug]: {"data":{"valid":true},"success":true,"error":false,"message":"Access allowed","status":200}
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} ```
GiteaMirror added the stale label 2026-05-06 13:33:25 -05:00
GiteaMirror commented 2026-05-06 13:33:26 -05:00
Author
Owner
Copy Link

@seamon67 commented on GitHub (May 4, 2025):

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.
GiteaMirror commented 2026-05-06 13:33:26 -05:00
Author
Owner
Copy Link

@polamoros commented on GitHub (May 4, 2025):

@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 :)
GiteaMirror commented 2026-05-06 13:33:26 -05:00
Author
Owner
Copy Link

@boomam commented on GitHub (May 5, 2025):

Same issue here, using the following settings -

<!-- gh-comment-id:2849737867 --> @boomam commented on GitHub (May 5, 2025): Same issue here, using the following settings - - Client ID = XXXX - Client Secret = YYYY - Authorization URL = https://authelia.domain.com/api/oidc/authorization - Token URL = https://authelia.domain.com/api/oidc/token - Identifer Path = preferred_username - Email Path = email - Name Path = name - Scopes = openid profile email
GiteaMirror commented 2026-05-06 13:33:26 -05:00
Author
Owner
Copy Link

@miloschwartz commented on GitHub (May 5, 2025):

@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?
GiteaMirror commented 2026-05-06 13:33:27 -05:00
Author
Owner
Copy Link

@boomam commented on GitHub (May 5, 2025):

@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 ```
GiteaMirror commented 2026-05-06 13:33:27 -05:00
Author
Owner
Copy Link

@boomam commented on GitHub (May 5, 2025):

Yes.

<!-- gh-comment-id:2851871613 --> @boomam commented on GitHub (May 5, 2025): Yes.
GiteaMirror commented 2026-05-06 13:33:27 -05:00
Author
Owner
Copy Link

@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.

<!-- 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.
GiteaMirror commented 2026-05-06 13:33:27 -05:00
Author
Owner
Copy Link

@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?

<!-- 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?
GiteaMirror commented 2026-05-06 13:33:28 -05:00
Author
Owner
Copy Link

@miloschwartz commented on GitHub (May 5, 2025):

If the Identifier Path is set to email, then the email has to be available like below:

{
  ...
  "email": "user@example.com"
}

You can test this with JMESPath here.

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.
GiteaMirror commented 2026-05-06 13:33:28 -05:00
Author
Owner
Copy Link

@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.

<!-- 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.
GiteaMirror commented 2026-05-06 13:33:29 -05:00
Author
Owner
Copy Link

@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.

<!-- 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.
GiteaMirror commented 2026-05-06 13:33:29 -05:00
Author
Owner
Copy Link

@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.
GiteaMirror commented 2026-05-06 13:33:30 -05:00
Author
Owner
Copy Link

@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.

<!-- 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.
GiteaMirror commented 2026-05-06 13:33:30 -05:00
Author
Owner
Copy Link

@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.
GiteaMirror commented 2026-05-06 13:33:31 -05:00
Author
Owner
Copy Link

@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.

<!-- 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.
GiteaMirror commented 2026-05-06 13:33:31 -05:00
Author
Owner
Copy Link

@AstralDestiny commented on GitHub (May 22, 2025):

Well the Calvary has arrived.

<!-- gh-comment-id:2899796530 --> @AstralDestiny commented on GitHub (May 22, 2025): Well the Calvary has arrived.
GiteaMirror commented 2026-05-06 13:33:32 -05:00
Author
Owner
Copy Link

@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!

<!-- 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!
GiteaMirror commented 2026-05-06 13:33:34 -05:00
Author
Owner
Copy Link

@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.

<!-- 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.
GiteaMirror commented 2026-05-06 13:33:36 -05:00
Author
Owner
Copy Link

@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'"}

Image

<!-- 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'"} ``` ![Image](https://github.com/user-attachments/assets/b05621f2-11b1-4bdb-8e0a-b451ba32a4ac)
GiteaMirror commented 2026-05-06 13:33:37 -05:00
Author
Owner
Copy Link

@miloschwartz commented on GitHub (May 27, 2025):

Based on these claims from your logs, there is no groups key in the payload:

{
    "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"
    }
}
<!-- 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" } } ```
GiteaMirror commented 2026-05-06 13:33:38 -05:00
Author
Owner
Copy Link

@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 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.
GiteaMirror commented 2026-05-06 13:33:38 -05:00
Author
Owner
Copy Link

@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).

From 5.4. Requesting Claims using Scope Values:

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.
GiteaMirror commented 2026-05-06 13:33:38 -05:00
Author
Owner
Copy Link

@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?

<!-- 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?
GiteaMirror commented 2026-05-06 13:33:39 -05:00
Author
Owner
Copy Link

@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.
GiteaMirror commented 2026-05-06 13:33:40 -05:00
Author
Owner
Copy Link

@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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
api
authentication
bug
config
dependencies
docker
documentation
enhancement
good first issue
help wanted
Improvement
Look Into
needs investigating
networking
new feature
non-critical bug
potential bug
pull-request
Mirrored from GitHub Pull Request
 question
reverse proxy
Security
stale
ui
wontfix
No Label stale
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/pangolin#10322
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?