OAuth2.0/OIDC implementation

[EnricoBilla]

Hi!

I think that the proposal in #33 to implement OAuth2.0/OIDC is great, for this reason I started looking into it a bit more but before committing any code I'd like to discuss the implementation with you.

Backend-wise I was thinking to add the client id, secret and discovery endpoint as environment variables. The discovery endpoint should be exposed through the API to the mobile application to know where to perform the authentication.
Every API call then should verify with the auth provider that the token is still valid for the user.

App-wise it would require a little bit more work to do, but I found the flutter_appauth package that should abstract the authentication login client side.

I'd like to get some feedback from you! Hope to be able to implement it 😃

[alextran1502]

Hi @EnricoBilla,

For this feature, I was considering finding an OAuth2.0/OIDC provider that has a docker container image to run with the whole stack, that would make the implementation easier. I am also leaning toward having the server as the single source of truth, the client app should be dumb and has to ask the server for every request (For the current version, it is checking the access token for every request).

The OAuth2.0/OIDC should be the service to provide the functionality that we need, not storing any data from the app. It keeps the app simple, easier to maintain, and presents options to the user to opt in or not.

[EnricoBilla]

Yes of course there are a lot of changes to do.

I wouldn't include the OIDC provider in the docker compose stack, because OAuth providers are meant for Single Sign On and many people are already running their own.
For example I'm currently using Authentik, but many others may be using Authelia/Keycloak/etc...

The provider won't make any difference in the actual implementation cause they all "speak" OpenID Connect and the API is standardized.

The check of the access token for every request would still be there tho, maybe I didn't understand correctly what you meant.

[alextran1502]

I see, I haven't worked with OIDC before so I only have some general ideas of how it works.

I assume your implementation plan would let the user choose to opt-in with OIDC or use the basic authentication feature of the app, correct? The reason for the question is that a lot of users of the app is not tech-savvy, so I want to include that user group as well

The check of the access token for every request would still be there tho, maybe I didn't understand correctly what you meant.

I was just confirming with you that we have the mechanism of validating every request.

[EnricoBilla]

Yes my idea is like that. Actually I started writing some code, mostly as a test, on dev/oauth2. Won't be an easy task because there's a lot of things to understand and learn but that's the reason I'm doing it!

I've added a flag that let the user enable OIDC (opt-in), if OIDC is enabled then the user can optionally disable the basic authentication (leaving both auth types working at the same time or OIDC only). I don't know if that's the best approach, what would you do?

All the code I wrote until now should be backward compatible, meaning that Immich would continue working fine with actual configurations.

I was just confirming with you that we have the mechanism of validating every request.

Okay! Since OIDC requires a call to the authentication server for every validation, I was thinking to cache the validation result for a short period of time so that, during the backup process, the verification doesn't introduce a lot of latency.

[EnricoBilla]

Little update to this, I didn't have much time in the last days but I managed to write almost all the necessary code for the backend to work.
The only problem is that I don't understand how the AuthGuard works in NestJS and I cannot get it to call the validate() in my custom strategy.
I would appreciate so much if anybody that knows NestJS could give me some hints on where to look!

For reference, I'm working on https://github.com/EnricoBilla/immich/tree/dev/oauth2-validation

[alextran1502]

Hey, this comment was lost in my email feed.

If you look into the folder server/src/middlewares you can see the implementation of the interceptor for custom guard functions. By adding your own middleware, you can create a decorator i.e @UseGuards(OAuth) to trigger before navigating to the route.

[EnricoBilla]

Hi thanks for the reply!
Yes I did see how you created the JWT AuthGuard, the problem here is that I cannot get it to call the validate() function inside my custom Strategy.
I'm learning a lot while doing this, I hope to have it working at some point in the future haha

[uhthomas]

Fixed by #884 and #990.