Login with other services

ghost commented 3 years ago

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 commented 3 years ago

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

lenaxia commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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:

Users attempts to visit Overseerr app
Redirected to Authelia (Authenticate user in Authelia)
(Transparent Redirected to Overseerr)
Authelia consent flow to grant access
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:

Users attempts to visit Overseerr app
Redirected to Authelia (Authenticate user in Authelia)
Redirected to Overseerr (Perform OIDC login)
Authelia consent flow to grant access
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:

chrome_2021-05-13_12-00-58 chrome_2021-05-13_12-01-09

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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:

Users attempts to visit Overseerr app

Redirected to Authelia (Authenticate user in Authelia)

Redirected to Overseerr (Perform OIDC login)

Authelia consent flow to grant access

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 commented 3 years ago

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 commented 3 years ago

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

stale[bot] commented 3 years ago

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 commented 3 years ago

I'll take a shot at implementing this

stale[bot] commented 3 years ago

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 commented 3 years ago

Still awaiting initial implementation.

stale[bot] commented 2 years ago

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 commented 2 years ago

I'd love to see this implemented!

pythcon commented 2 years ago

Any updates on LDAP?

stale[bot] commented 2 years ago

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 commented 2 years ago

Is there any update to this?

danshilm commented 2 years ago

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

stale[bot] commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

+1 for Authentik or Authelia support!

isrbaral commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.

tobz commented 1 year ago

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.

That argument doesn't hold water: Overseerr already has the concept of some routes being authenticated vs unauthenticated. Whether ForwardAuth or OIDC are used has no influence on this point.

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

ForwardAuth certainly does imply that something is doing the authentication as a sideband before every request that is proxied through Traefik (or whatever other reverse proxy solution is being used), so yes, an additional service must be up. It's not clear how this is particularly more disruptive, though.

If users are asking for ForwardAuth, they're accepting this fact. It's not like Overseerr is prescribing or bundling an all-in-one external authentication solution, so who cares if it's slightly more complicated for users? Those users are, again, implicitly agreeing to such complexity by asking for this feature.

In my case, I run Overseerr (and my ForwardAuth service) on Kubernetes, so the "complexity" of making my ForwardAuth service highly available to avoid disrupting during maintenance is literally as simple as changing a 1 to a 2. I'm not an expert here on self-hosted platforms, but I'd be willing to be it's not too much more difficult to do the same thing for other styles of setup, such as Docker Compose/Swarm, etc.

ikogan commented 1 year ago

I'd like to pipe in and say that LDAP authentication should absolutely not be the path for this. LDAP allows Overseerr to see and transmit the user's password to an upstream LDAP server. Nevermind that LDAP is a fairly dated option, especially on the web, OIDC and SAML are significantly more secure and flexible options.

With OIDC and SAML, Overseerr never sees the user's password and the entire authentication process happens within the authenticating tool (Authelia, Authentik, Google, whatever). This has several advantages:

MFA for free, with whatever the tool supports
RBAC within the tool
Advanced login features like security keys, fingerprints, geolocation restrictions, anything the tool supports
Login once in your browser and authenticate to all *arr or whatever apps
Robust user access policy, password reset, etc.

Effectively, you're handing off all user management tasks to a separate tool. While you get some of that with LDAP (single password + attributes, possibly password reset as well), you're missing a lot of other pieces. Literally the easiest way to get all of the features of OIDC or SAML without all of the work is simply implementing Proxy Auth. Lots of proxies support this. Here's a few:

There's tons. Making this secure on the Overseerr end is accomplished by:

Allow some sort of "trusted proxy" configuration item to be set, such that Overseerr will only accept the magic auth header (usually X-Remote-User) if the actual request is coming from an IP in this "trusted proxy" list.
Allow SSL to be required for any request that carries the header

You could then setup SSO in a Docker Compose by simply including a oauth2-proxy container and only expose the proxy and not Overseerr itself.

Proxy authentication can create a problem for non-browser based apps or API calls. You can configure most proxies so that certain URLs bypass the proxy (and you would ignore any auth header on those URLs). For things like mobile apps, if you don't want to use an embedded browser to login, you can allow users to generate API tokens that could be used in place of a password.

Also, as a reference, Ombi implements this and is one of the things making me consider Ombi over Overseerr, despite how much more advanced Overseerr is.

stale[bot] commented 1 year ago

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.

stale[bot] commented 1 year ago

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.

gravelfreeman commented 1 year ago

Where is this at? I'm setup with Authelia in my homelab and would really like to see Overseer support it.

Casuallynoted commented 1 year ago

Using Authentik atm and would also love to see this.

obsidiangroup commented 1 year ago

Using Authentik atm and would also love to see this.

What continues to baffle me is, @ankarhem created PR 2792 that adds OIDC support, that I have been using with Authentik since October. I know @sct said there were changes to the login happening from #2792 but doesn't look like any work has been done there in awhile either.

I haven't attempted to apply the changes from #2792 to the latest stable version. Might try sometime today.

darylf commented 8 months ago

There hasn't been any activity in this thread since September 2023. As an Authelia user, I'm hoping to integrate it with Overseer, much to the same way as the other *arr apps. Are there any plans to move forward with this implementation?

lenaxia commented 8 months ago

I took over the OIDC effort, and have completed and rebased Ankarhem's work which now enables authelia for Overseerr. You can see the PR here: #3746

For the time being, until @sct merges my PR, you can pull the image here:

docker pull ghcr.io/lenaxia/overseerr-oidc:oidc-support

gravelfreeman commented 8 months ago

I took over the OIDC effort, and have completed and rebased Ankarhem's work which now enables authelia for Overseerr. You can see the PR here: #3746

For the time being, until @sct merges my PR, you can pull the image here:

docker pull ghcr.io/lenaxia/overseerr-oidc:oidc-support

Wow! Thank you so much, this is some great news!

obsidiangroup commented 8 months ago

@lenaxia I've been using @ankarhem version for quite some time with no issues with authentik. I quickly pulled your version (after backing up configs) and pointed to my backup config. Everything works perfectly as before. May I make a suggestion? Since most IDP's have a logout url, maybe add an option to enter the iDP's Logout URL. That way when a user logs out of Overseerr, it will also log them out (or prompt them) of the IDP.

Otherwise, thank you for taking on the work. Glad can now run a recent version of Overseerr :)

marlowleon commented 7 months ago

@lenaxia I've been using @ankarhem version for quite some time with no issues with authentik. I quickly pulled your version (after backing up configs) and pointed to my backup config. Everything works perfectly as before. May I make a suggestion? Since most IDP's have a logout url, maybe add an option to enter the iDP's Logout URL. That way when a user logs out of Overseerr, it will also log them out (or prompt them) of the IDP.

Otherwise, thank you for taking on the work. Glad can now run a recent version of Overseerr :)

Im having some difficult on Authentik, getting Error "{"message":"Unexpected token < in JSON at position 3"}" I have the Client and secrete added, Not to sure what to put for the domain

lenaxia commented 7 months ago

@marlowleon you can see a sample config here for authentik: https://github.com/sct/overseerr/pull/2792#issuecomment-1876673942 and in the following comment too.

marlowleon commented 7 months ago

@marlowleon you can see a sample config here for authentik: #2792 (comment) and in the following comment too.

Thanks! Actually i got it to work and its wonderful

stale[bot] commented 5 months ago

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.