Login with other services

Description

Is your feature request related to a problem? If so, please provide a clear and concise description of the problem. E.g., "I'm always frustrated when [...]."

I have some family members who I would like to give access to but will probably result in me being constantly asked for their password. Adding support for providers like auth0 would allow me to enable sending a code via sms or email for them to enter on the page to login as an authentication method which would work better than a link if the web app is added to their home screen.

Desired Behavior

Allow a third party authentication service like auth0 to either login directly to the web app similar to plex or using SSO from a reverse proxy.

Additional Context

[danshilm]

There was already an issue similar to this: #332 but it was closed by the stale bot.

[lenaxia]

There's also this issue: #1555

I'd make an argument here again for the implementing Forward Authentication. Because it'd also give us LDAP support for free since, for example, Authelia would handle it.

To summarize my response from the othe rissue, Forward Authentication is not a security risk as it is a well accepted way of authenticating applications, as can bee seen in Grafana (https://grafana.com/docs/grafana/latest/auth/auth-proxy/).

Also, Forward Auth supports the core mission of Overseerr by enabling people to safely present Overseerr to other users, over the open internet in a safe manner. This would be done by placing Overseerr behind a reverse proxy like Traefik, and allowing the reverse proxy to handle authentication through a service like Authelia. This means that a security issue in Overseerr isn't a critical failure that would risk exposing my entire network to an intruder. Instead my attack surface is still limited to just Authelia and Traefik.

The Traefik forward auth docs: https://doc.traefik.io/traefik/middlewares/forwardauth/
The Authalia documentation on Forward Authentication: https://www.authelia.com/docs/community/using-remote-user-header-for-sso-with-jira.html

Authelia supports LDAP, Yubikeys, Duo, and other 2 factor authentication, so you're really getting all of this stuff for free when you support forward auth.

[sct]

There's also this issue: #1555

I'd make an argument here again for the implementing Forward Authentication. Because it'd also give us LDAP support for free since, for example, Authelia would handle it.

To summarize my response from the othe rissue, Forward Authentication is not a security risk as it is a well accepted way of authenticating applications, as can bee seen in Grafana (https://grafana.com/docs/grafana/latest/auth/auth-proxy/).

Also, Forward Auth supports the core mission of Overseerr by enabling people to safely present Overseerr to other users, over the open internet in a safe manner. This would be done by placing Overseerr behind a reverse proxy like Traefik, and allowing the reverse proxy to handle authentication through a service like Authelia. This means that a security issue in Overseerr isn't a critical failure that would risk exposing my entire network to an intruder. Instead my attack surface is still limited to just Authelia and Traefik.

The Traefik forward auth docs: https://doc.traefik.io/traefik/middlewares/forwardauth/
The Authalia documentation on Forward Authentication: https://www.authelia.com/docs/community/using-remote-user-header-for-sso-with-jira.html

Authelia supports LDAP, Yubikeys, Duo, and other 2 factor authentication, so you're really getting all of this stuff for free when you support forward auth.

Great response. Thanks. I will look into getting something worked out for this.

[nightah]

Authelia dev here, I recall seeing some commentary on Discord that the team (I think it was @TheCatLady) would likely prefer to wait for OAuth/OIDC prior to implementing support for external authentication, not sure if that stance has particularly changed or not but we now have OIDC support in beta with Authelia.

In terms of documentation on Authelia's side to support header based authentication I would probably point the team to the following location:

https://www.authelia.com/docs/deployment/supported-proxies/#how-can-the-backend-be-aware-of-the-authenticated-users

As @lenaxia has already pointed out Grafana is a great example of an application which supports this type of authentication mechanism and likely is a lower barrier to implement support for. However, if we're being idealistic and looking to avoid technical debt (if it can really be viewed as that) OIDC might be a better long term approach.

[lenaxia]

@nightah I'm not as familiar with OIDC, but from my experience, OIDC requires, in this case, Overseerr to be exposed at the front end and it just momentarily redirects to the OIDC provider for auth. Is that an incorrect understanding?

My main concern is that, with OIDC, would any part of Overseerr (or other applications) be exposed prior to authentication being achieved? If that's not the case then I'm okay with going straight to OIDC as opposed to through forward auth. However if any part of a backend application is exposed prior to auth, that is a non-starter.

[nightah]

The flow broadly is very much the same if you're looking at utilising OIDC with Authelia infront.
There could be some qualify of life changes that the Overseerr developers may look to implement like automatic login if an OIDC provider is present/configured, Grafana for example can be configured like this.

To give you a view of the flow here's an example flow if Overseerr supported OIDC and the user was configured with the appropriate access to the Overseerr within Authelia's ACLs and assuming that Overseerr implemented auto-login:

1. Users attempts to visit Overseerr app
2. Redirected to Authelia (Authenticate user in Authelia)
3. (Transparent Redirected to Overseerr)
4. Authelia consent flow to grant access
5. Redirect to Overseerr (As authenticated user)

When I say transparent redirect you would see the browser forward to Overseerr for a brief second but it would eventually redirect straight back to Authelia for the consent flow.

If auto-login wasn't turned on/implemented you would have a very similar flow just not a transparent redirect, it would require user intervention to execute the consent/login flow:

1. Users attempts to visit Overseerr app
2. Redirected to Authelia (Authenticate user in Authelia)
3. Redirected to Overseerr (Perform OIDC login)
4. Authelia consent flow to grant access
5. Redirect to Overseerr (As authenticated user)

Steps 3 and 4 are represented with Grafana as an example below and the consent/login flow is enacted as soon as the user clicks "Sign in with Authelia" in Grafana:

The consent flow is also only executed once unless the user explicitly logs out of Overseerr because back-channel logout currently isn't implemented and is due in beta3.

I hope this helps clear up any confusion and apologies if this is somewhat derailing the issue.

[lenaxia]

@nightah My biggest concern for this is that as you show, the grafana login page is presented before any authentication occurs. Meaning a bad actor now has access to the service before any identity verification has occurred. This concern isn't unique to just Overseerr, but applies to any OIDC enabled application. In the forward auth case, Authelia and Traefik are the only things accessible prior to authentication occurring, meaning they are the primary points that need to be hardened. While things behind them can be a little softer.

In the OIDC case, even the backends now need to be hardened. If for instance, a back end application has a security bug that allows bypass of their login page, it completely defeats the purpose of even having OIDC. Which means now I need to ensure all my OIDC enabled applications need to have hardened login pages, in addition to ensuring hardening of Authelia and Traefik.

What is the OIDC solution to this dilemma?

(I also apologize for derailing, I just feel that forward auth, while it has its own problems, is much more secure when exposed to the broader internet than OIDC is)

[nightah]

@lenaxia my apologies perhaps my explanation wasn't clear but the screenshots I provided above are explicitly for Step 3 and 4 in the no auto-login flow.

To give you a view of the flow here's an example flow if Overseerr supported OIDC and the user was configured with the appropriate access to the Overseerr within Authelia's ACLs and assuming that Overseerr implemented auto-login

Step 1/2 in both of the above flows will always redirect to Authelia first and require the user to be authenticated before moving to any of the other subsequent steps.

[lenaxia]

Thanks for the clarification nightah. At this point this is purely for my education, so I appreciate you humoring me.

Just to make sure I understand, we have 3 scenarios: Forward Auth, OIDC with Auto Login and OIDC without Auto Login.

From a user perspective in all three cases, the first thing users will see is the Authelia login page.

From there it differs.

In Forward Auth, once Authelia is cleared, the user is directed to the backend service (e.g. Grafana) without any further interaction.

In the OIDC with Auto Login, after Authelia, users are directed to a consent page where they Accept the Permissions Request, then they are directed to Overseerr.

In OIDC without Auto Login, after Authelia, users are directed to the backend application (Grafana's) login page to login a second time via "Sign In with Authelia" button. They are then directed to the consent page where they Accept Permissions Request, and then finally directed to Overseerr. This has the added extra step of requiring a second login.

So specifically in the Auto Login case, users only have one additional action, which is the consent page. And without Auto Login, they have two additional actions, a second login page and then OIDC consent page.

Is this understanding correct?

If so, definitely implementing Auto Login is a must, it makes little sense for users to be forced to login twice. Under what scenario would a developer choose to not implement Auto Login?

[nightah]

Your summation is correct @lenaxia.

In terms of your last question I think it's a matter of balancing time, effort and complexity to implement.

[TheCatLady]

If auto-login wasn't turned on/implemented you would have a very similar flow just not a transparent redirect, it would require user intervention to execute the consent/login flow:

1. Users attempts to visit Overseerr app
2. Redirected to Authelia (Authenticate user in Authelia)
3. Redirected to Overseerr (Perform OIDC login)
4. Authelia consent flow to grant access
5. Redirect to Overseerr (As authenticated user)

Steps 3 and 4 are represented with Grafana as an example below and the consent/login flow is enacted as soon as the user clicks "Sign in with Authelia" in Grafana:

This is exactly how Plex OAuth works with Overseerr right now, so I think this flow would be a good fit for Overseerr once Authelia OIDC support is more mature and out of beta.

[nightah]

Another reason why auto-login needs to be explicitly enabled/configured is if there are multiple OAuth login sources, so let's say OIDC was implemented and users could authenticate with Authelia or Plex.

I believe the same caveat exists with Grafana that auto-login can only be enabled if there's a single OIDC/OAuth login source.

[acortelyou]

+1 for forward auth so we can light up organizr SSO.