[Feature]: mpflanzer-allauth (OpenID Connect)

[TheRealGramdalf]

Description

I've been taking part in https://github.com/paperless-ngx/paperless-ngx/pull/5190 recently, which adds OpenID Connect support (also known as OIDC, Social Login or Oauth2.0) via django-allauth. Though this has yet to be merged, I figured it was worth opening an issue sooner rather than later.

I'm unfortunately not super experienced with how OpenID implementations in mobile apps work, so I'm afraid I won't be much help there - but I'm more than happy to do any bug testing needed, since I already have my paperless instance running off the PR.

[TheRealGramdalf]

Related: (Most issues with SSO should be solved once people migrate to direct OpenID integration instead of reverse proxy/HTTP header auth) https://github.com/astubenbord/paperless-mobile/issues/229 https://github.com/astubenbord/paperless-mobile/issues/240

[TheRealGramdalf]

There are preexisting libraries that could be used; a brief search brings the following results:

https://auth0.com/blog/get-started-with-flutter-authentication/ https://pub.dev/packages/openidconnect | Github https://pub.dev/packages/openid_client | Github

[astubenbord]

A problem I still see is that the OAuth flow requires to communicate with the app through a callback. This may be possible, but during compile time, the app has no way of knowing your individual host name. However, to my understanding, an app has to declare the domain names it can open in the app's manifest, therefore each user would have to build the app from source and provide their host name in the android manifest. If this should not be the case, please correct me, but this is my current (and also rather limited) understanding of how OAuth works in a mobile context.

[zjean]

The app can register a fixed scheme like paperless:// which the auth provider will redirect to. That will cause the call back to open the app. In this way a user doesn't have to compile the app

[astubenbord]

Good point, thanks for clarifying!

[TheRealGramdalf]

The upstream PR has been merged into the dev branch, but hasn't quite made it into a release released - is there any chance this could be implemented along a similar timeline, or is it relatively complicated?

Not to try and put pressure on anyone, it would just be nice to know whether I should wait for this feature or just use alternative methods for now.

[astubenbord]

I don't think I'll be able to implement this right now. I see how it is very useful and I'll eventually also implement it for my hosted services as well, but at the moment, the app still has a lot of bugs which I have to prioritize. If anyone is interested in implementing a solution, you are more than welcome to file a PR for this.

[beposec]

The URL recognition for paperless apps with OIDC login could be inspired by the Matrix protocol. With Matrix, the path of the OIDC provider (e.g. https://paperless.example.com/.well-known/paperless/oidc) is located on the domain in a .well-known directory.

https://areweoidcyet.com/client-implementation-guide/

[mentos1386]

Another potential ~solution~ workaround for this would be to use the api auth token (?). Instead of current form of "username & password" a form with "token" would could also be shown. That means that openid users can use the token authentication for now, until full openid flow is implemented.

I guess that the api auth token works even with openid enabled on paperless?

Something like this was proposed for the proxy auth method already, but in this case, it might actually work as there is no proxy involved to mess up the headers.

[AdmiralNemo]

Yes, it would be great if we could at least have the option to use an auth token directly instead of username and password. This is a fairly common pattern for applications protected by Authelia or other proxy-based authentication solutions, and I think it would work well enough here.

[gregistech]

Indeed, even a token based workaround would be great.

E: setting a password afterwards works too, but quite cumbersome.