[Feature Request] Add subject in CustomOidcUserService as last fallback when no username can be created

[koalaeagle]

Describe the bug
When logging in via OIDC with an identity provider that doesn't return the given_name claim (like Dex), Reitti crashes with a NullPointerException at CustomOidcUserService.java:64. However, according to Reitti's documentation, user matching relies on preferred_username and name claims — given_name is not mentioned as a required or used claim. This suggests either a documentation/implementation mismatch, or the code is accessing a claim that shouldn't be part of the authentication flow.

To Reproduce
Steps to reproduce the behavior:

1. Configure Reitti to use OIDC authentication with Dex (or any provider that omits given_name)
2. Navigate to the Reitti login page
3. Click "Login" and authenticate through the OIDC provider
4. After successful authentication at the provider, the callback to /login/oauth2/code/oauth fails with HTTP 500

Expected behavior
Per the documentation, Reitti should successfully authenticate using preferred_username and name claims. The code should either:

• Not access given_name at all (if it's not needed), or
• Handle its absence gracefully if it is used for something undocumented

Screenshots
N/A

Desktop (please complete the following information):
N/A

Smartphone (please complete the following information):
N/A

Additional context
Stack trace:

java.lang.NullPointerException: Cannot invoke "String.toLowerCase()" because the return value of "org.springframework.security.oauth2.core.oidc.user.OidcUser.getGivenName()" is null
at com.dedicatedcode.reitti.config.CustomOidcUserService.loadUser(CustomOidcUserService.java:64)

Documentation discrepancy: The OIDC documentation states that Reitti uses:

• preferred_username for username assignment
• name for display name

But the crash indicates the code is attempting to use given_name, which is an optional OIDC claim that Dex (and other minimal providers) don't include. Could you clarify:

1. Is given_name actually used for something, or should the code be using preferred_username/name instead?
2. Should the documentation be updated to list given_name as required?
3. Or should the code be changed to stop using given_name entirely?

[dgraf-gh]

Hi @koalaeagle,

actually the code is trying to use the given name as last resort. It first checks the preferred username, then the email and finally if none of them is available it tries to use the givenName.

reitti/src/main/java/com/dedicatedcode/reitti/config/CustomOidcUserService.java

Line 54 in 4895e2f

if (preferredUsername == null) {

Do you have an idea what your provider returns. I never have heard of Dex.

I think it should be possible if all of them fail, we finally can go to the given subject. This should always be available.

[koalaeagle]

Hello @dgraf-gh,

I did a bit of debugging on the claims returned by dex. I found that what it returns is pretty minimal. sub, iss, aud, name being the most relevant. In my case name is usable, but I assume this could be first + last name in other cases, which is why it isn't ideal?

I was surprised that preferred_username was absent. I found out how to fix this in dex. In my case it is mapping from LDAP, and based on my username field of uid I set preferredUsernameAttr: uid per https://dexidp.io/docs/connectors/ldap/

I also figured out playing around with the claims and based on the ordering you mentioned, I likely could have resolved it by adding email to OIDC_SCOPE, as dex will return email address if included in the scope.

My issue is sorted, thanks for the info, it helped a lot!

For the purposes of this report, I think perhaps a last ditch fallback to using subject, as that will always be available (required). It may also be worth throwing in email to the default oidc scope if that is the second thing tried. Although, that is possibly subjective as it is not strictly required if preferred_username is included. Still, it may catch more edge cases as a default.

[dgraf-gh]

Hi @koalaeagle,

that is good that it helped resolve the issue on your side. Still a NPE is never good and I will add the subject as a last resort.