fosrl / fosrl/pangolin

bug: OIDC authentication fails to fetch user details from UserInfo endpoint

Open
#762 10 comments 3 reactions 1 assignee Claimed by @oschwartz10612 View on GitHub
needs investigating potential bug
Dominant language
TypeScript
Stars
22.8k
Forks
783
Avg merge
1d 11h
Merged PRs (30d)
47

Description

Pangolin's OIDC authentication implementation only uses claims from the ID token and does not fetch additional user details from the provider's UserInfo endpoint when required claims are missing.

**Expected Behavior:**
When authenticating via OIDC, users should see their email address and full name in Pangolin, regardless of which claims the provider includes in the ID token.

**Actual Behavior:**
Users authenticated through OIDC providers that don't include email/name/groups claims in the ID token (like Authelia 4.39+) appear with their `sub` claim (UUID) instead of their email address, and have blank name fields.

**Steps to Reproduce:**
1. Configure Authelia to act as an OIDC provider.
2. Configure Pangolin as an OIDC client for Authelia.
3. Attempt login with Pangolin.
4. See UUID instead of email once logged into Pangolin.

**Additional Information:**
I believe this issue is the same one fixed by [this pr](https://github.com/mealie-recipes/mealie/pull/5228) in Mealie.

Per the OIDC spec, it is not required for OIDC providers to return anything except for [specific claims](https://openid.net/specs/openid-connect-core-1_0.html#IDToken) in the id_token given to the client after authentication. As such, if the client expects info about the user (such as email, username, etc) they may have to fetch said info from the provider's user info endpoint.

In the recent update for authelia (4.39), we stopped including this information (to achieve OIDC certification) by default which requires some clients to use the [UserInfo](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) endpoint. We [provided a way](https://www.authelia.com/integration/openid-connect/openid-connect-1.0-claims/#restore-functionality-prior-to-claims-parameter) for admins to continue using the old method but this is a band-aid fix.

**Possible Solution:**
As can be seen in the mealie pr, this should be a fairly straight forward fix, if the returned token doesn't contain the required information about the user, fetch it from the UserInfo endpoint instead.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.