OAuth login incorrectly loading user or associating account

[Ralms]

The bug

Hi everyone,

I've been configuring Immich to use Azure B2C as its OAuth identity provider.
I've run into an issue which I don't think its intended as is concerning.
Essentially, after login, Immich attempts to load whatever profile has OAuth linked, even if the user is not the same, the email is not the same, etc.
The point that with a test account, it logged in into my administrator account. (different names, email addresses, etc).
Leaving me to believe that some checks are missing in the code, but I could be wrong.

Right now, after login, the callback receives the following attributes on top of the access token: sub (contains a guid that I'm not sure what refers to), email, given_name, family_name.

Login performed on a Web Browser at the computer, not the mobile app.

Is Immich expecting more attributes to be able to do the account matching?

The OS that Immich Server is running on

Ubuntu 24.04.1 LTS

Version of Immich Server

v1.123.0

Version of Immich Mobile App

1.125.5

Platform with the issue

• Server
• Web
• Mobile

Your docker-compose.yml content

Default docker compose from the documentation with Traefik added via labels.

Your .env content

IMMICH_VERSION=release

Reproduction steps

1. Integrate Azure B2C on OAuth configuration.
   This requires a custom policy in Azure B2C due to the requirement of user_info.
   The main fields that I think might be relevant are:

• ISSUER URL: https://.b2clogin.com///v2.0/.well-known/openid-configuration
• SCOPE: openid email profile <My App Registration ID, required by B2C>
• SIGNING ALGORITHM: RS256
• PROFILE SIGNING ALGORITHM: none

2. Perform the normal login via OAuth
3. Login is successful and wrong profile is loaded and grated access.

Relevant log output

Additional information

Please note that I had a different OAuth profiler previously and changed it via the configuration.
As such, the existing 2 users had OAuth linked from the previous setup, however, from the email alone it should not match, let alone other details such as the issuer.

Initially, when I logged in for the first time with Azure B2C, it went to my user B, where after doing Unlink OAuth, caused the login to load User A (the admin account).

Lastly, I have "Auto Register" set to Off and the user email that is coming from OAuth doesn't have a matching user in Immich.

[btilford]

I'm getting something similar except users that have already signed up get put into a oauth loop saying "Current user already exists but is linked to another account."

[PrzemekSkw]

Hello, did You fix that?

[jrasm91]

The first time you login it matches on email and then saves the sub, which is used on future requests. Changing oauth providers without nulling out previously saved subs will lead to behavior like this.

[Ralms]

And in no place of the OpenID Connect spec it says: "Just accept whatever they throw at you, as long as it comes from the configured issuer".

In fact, 5.3.2 of OpenID Connect Core:
"Due to the possibility of token substitution attacks (see Section 16.11), the UserInfo Response is not guaranteed to be about the End-User identified by the sub (subject) element of the ID Token. The sub Claim in the UserInfo Response MUST be verified to exactly match the sub Claim in the ID Token; if they do not match, the UserInfo Response values MUST NOT be used."

If the sub Claim doesn't even exist, Immich is not only not validating it exists, but also not doing this check, as both would fail.

Either way, I will focus more on a fix, than this absurd idea that any application in 2025 should blindly accept a mal formed token not meeting spec (or that doesn't meet its requirements as in this case) and allow a login.

[jrasm91]

#15967 should prevent weird behavior due to a missing sub.

[jrasm91]

We use https://github.com/panva/openid-client which should be compliant to that specification. Can you verify that your issue is actually due to a missing/invalid sub? If so, can you create an issue with the client library?

[Ralms]

#15967 should prevent weird behavior due to a missing sub.

Thank you.

We use https://github.com/panva/openid-client which should be compliant to that specification. Can you verify that your issue is actually due to a missing/invalid sub? If so, can you create an issue with the client library?

yeah, I will validate it.
I also wanna double check the reliance of Immich on the email claim, which technically is optional.

Btw, for context, I'm using Azure B2C as the identity provider, which supports custom policies, allowing me to effectively control every detail of a token or endpoints. The template policies don't take into consideration strict OpenID Connect clients, and that is why it is returning the tokens without the sub claim, it was threating it as just a standard JWT token and sending back instead ObjectId (essentially the sub in this directory).

I will report back any findings I get.
Thanks.

[Ralms]

First test, I can confirm that it now properly blocked the login.
On UI side I got "Failed to finish oauth", on server logs it hit the new check and threw error "Unexpected profile response. no 'sub'".

I will now fix my B2C custom policy to have it return sub and lets see how it behaves.