bug(oidc): komodo fails to fetch user details from IdP user info endpoint #392

New Issue

GiteaMirror · 2025-10-31T15:10:39-05:00

GiteaMirror commented

2025-10-31 15:10:39 -05:00

Originally created by @Crowley723 on GitHub (May 28, 2025).

Komodo'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 Komodo, 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, or other identifier) instead of their email address, and have blank user info fields.

Steps to Reproduce:

Configure Authelia to act as an OIDC provider.
Configure Komodo as an OIDC client for Authelia.
Attempt login with Komodo.
See UUID instead of email once logged into Komodo.

Additional Information:
I believe this issue is the same one fixed by 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 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 endpoint. We provided a workaround 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.

Originally created by @Crowley723 on GitHub (May 28, 2025). Komodo'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 Komodo, 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, or other identifier) instead of their email address, and have blank user info fields. Steps to Reproduce: Configure Authelia to act as an OIDC provider. Configure Komodo as an OIDC client for Authelia. Attempt login with Komodo. See UUID instead of email once logged into Komodo. Additional Information: I believe this issue is the same one fixed by https://github.com/mealie-recipes/mealie/pull/5228 in Mealie. Per the [OIDC spec](https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims), 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](https://www.authelia.com/blog/we-are-now-openid-certified/)) 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 workaround](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.

GiteaMirror added the done label 2025-10-31 15:10:40 -05:00

GiteaMirror closed this issue

2025-10-31 15:10:40 -05:00

GiteaMirror commented

2025-10-31 15:10:40 -05:00

@mbecker20 commented on GitHub (Jun 8, 2025):

Thanks for pointing this out, it should be addressed in 1.18.2

@mbecker20 commented on GitHub (Jun 8, 2025): Thanks for pointing this out, it should be addressed in 1.18.2

GiteaMirror referenced this issue

2025-10-31 15:20:15 -05:00

[PR #392] [MERGED] docs: Typo #731

Sign in to join this conversation.