Login with other services

[ghost]

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: https://github.com/sct/overseerr/issues/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.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ankarhem]

I'll take a shot at implementing this

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[726a67]

Still awaiting initial implementation.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[j21w91]

I'd love to see this implemented!

[pythcon]

Any updates on LDAP?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[pythcon]

Is there any update to this?

[danshilm]

No updates for now. This issue wil be updated whenever there's any.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[obsidiangroup]

I know this is an older thread, but all the talk was with using Authelia, but what about Authentik?

It supports multiple types of providers (LDAP, OAuth2/OpenID), etc plus it already has support ffor Plex OAuth as a method of signin. If Overseerr could directly integrate with Authentik (and not force the use of Plex authenticate), Authentik could then handle authentication.

[anschein]

I know this is an older thread, but all the talk was with using Authelia, but what about Authentik?

It supports multiple types of providers (LDAP, OAuth2/OpenID), etc plus it already has support ffor Plex OAuth as a method of signin. If Overseerr could directly integrate with Authentik (and not force the use of Plex authenticate), Authentik could then handle authentication.

I'm using overseer for my family and friends,and I'm tired to set their emails and accounts in sooo many services,If overseerr can have a ldap to link my ldap provider that would be very nice.

[enigmaoftech]

+1 for Authentik or Authelia support!

[isrbaral]

I know this is an older thread, but all the talk was with using Authelia, but what about Authentik?

It supports multiple types of providers (LDAP, OAuth2/OpenID), etc plus it already has support ffor Plex OAuth as a method of signin. If Overseerr could directly integrate with Authentik (and not force the use of Plex authenticate), Authentik could then handle authentication.

I believe the plan would be to add LDAP authentication which would allow both authelia and authentik.

[lenaxia]

I want to revisit this issue and unequivocally state that I would prefer forward auth over OIDC now that I have a better understanding of the details (and after having run OIDC at home for some time).

Forward auth is not only superior but easier, simpler and more secure.

Pros:

• It does not expose ANY part of the service until auth has been completed, reducing attack surface unlike OIDC which does
• It does not require extra steps (such as consent) for users, it is very natural for what people are used to
• It actually performs as SSO, unlike OIDC which requires consent before acting like SSO and can be confusing for people who aren't familiar with that model
• It is far simpler than OIDC, which requires multiple endpoints and handshakes, which isn't really necessary for self hosters
• It is easier to configure, requiring only a few headers to be defined as opposed to apis
• It can be backed by either LDAP or build in user dir, and when backed by LDAP, then the auth frontend will always be in sync with the local user directory
• Way easier to debug than OIDC

Cons:

• It requires a trust model that isn't enforceable (local access over LAN is always priviledged, so no docker ports or k8s services), but we're not dealing with national secrets here

I honestly have not found any other cons, especially when compared to OIDC.

[hrenard]

Hi !

I agree with the idea that forward auth is simpler to implement, but I don't think it's superior. So, I'll try to add some nuance.

• It does not expose ANY part of the service until auth has been completed, reducing attack surface unlike OIDC which does.

This can also be viewed as a con because you may want api endpoints or healthcheck endpoint to be reachable anonymously from outside. So it's a little more complex for the self-hoster.

• It does not require extra steps (such as consent) for users, it is very natural for what people are used to.
• It actually performs as SSO, unlike OIDC which requires consent before acting like SSO and can be confusing for people who aren't familiar with that model

If the frontend directly redirects to the oidc flow and your idp supports implicit consent like authelia, then you get the same behavior.

With forward auth, the service must be up for every request. Maintenance is a little more disruptive.

In the end, I'm happy with forward auth, but I prefer relying on standards.