SSO OpenID

[sydlexius 264]

7 hours ago, softworkz said:

No it isn't.

There is.

The whole principle of security would fall apart when the identity server wouldn't be able to ensure the identity of the SP, which is done by validation of dns name and cert. 

Not to mention it simply violates the basic principal of "never trust the client" (as true in infosec as it is in game development).  Some products may have failed this by poor implementation, but never by such a supposed architectural design as having a client be a main-in-the-middle between the app and auth servers.

[softworkz 4495]

@sydlexius Very true. It's not an easy subject to understand and going into details is out of the scope of this conversation - hence my brief response and hence I like your high-level answer which is on-point. In many diagrams, you can see that the data is always going in a circle between the involved parties and what's also part of the protocols is the concept of callbacks, where one party makes a request to the other and the other doesn't respond to the request directly, but instead "calls back" to the registered endpoint of the initiator (using DNS and SSL validation) to mitigate any spoofing attempts.
 

3 hours ago, sydlexius said:

Some products may have failed this by poor implementation

Not just that: If somebody says they have done or seen an implementation which does differently, then it's not OIDC/OAuth.

Edited February 23, 2024 by softworkz

[Mutex001 1]

I do this as part of my job.   I know OIDC, OAuth2 and SAML extremely well.  

You are simply incorrect.   The OAuth provider does not validate the DNS location or certificate for the authenticating application.   It knows where to send the authentication response (authorization code) based on a redirect_uri configured when the application is registered with the OAuth provider.   This redirect uri can be http, https, or a custom private URI scheme (for mobile apps).   

The OIDC provider never needs to communicate directly with the application.   Communication is typically done through the browser.   

You can read about the typical flow here:

https://www.oauth.com/oauth2-servers/server-side-apps/example-flow/

There are two requests from the app to the OAuth provider....a redirect of the browser to the OAuth provider /authorize endpoint, and a POST request to the OAuth providers /token endpoint after the OAuth provider responds.    The OAuth provider responds to the /authorize request by redirecting the browser back to the applications redirect uri.    As mentioned, this redirect URI can be http or https or a custom scheme.    

Edited February 23, 2024 by Mutex001

[Mutex001 1]

5 hours ago, sydlexius said:

Not to mention it simply violates the basic principal of "never trust the client" (as true in infosec as it is in game development).  Some products may have failed this by poor implementation, but never by such a supposed architectural design as having a client be a main-in-the-middle between the app and auth servers.

It would, but the OAuth spec requires that the authenticating application be pre-registered with the OAuth provider with a specific redirect uri where the authentication response is sent (via the browser).    That redirect URI may or may not be SSL, that is entirely up to the application owner.

 

[Mutex001 1]

1 hour ago, softworkz said:

@sydlexius Very true. It's not an easy subject to understand and going into details is out of the scope of this conversation - hence my brief response and hence I like your high-level answer which is on-point. In many diagrams, you can see that the data is always going in a circle between the involved parties and what's also part of the protocols is the concept of callbacks, where one party makes a request to the other and the other doesn't respond to the request directly, but instead "calls back" to the registered endpoint of the initiator (using DNS and SSL validation) to mitigate any spoofing attempts.
 

Not just that: If somebody says they have done or seen an implementation which does differently, then it's not OIDC/OAuth.

The "call back" to the registered endpoint of the initiator is through the browser, not through direct DNS/SSL validation by the OAuth provider (other than standard DNS and optional SSL performed by the browser).   This leaves the implementation of how that callback is handled entirely in the control of the application owner.  

You can see a typical /authorize response from the OAuth provider in the OIDC spec itself:

https://openid.net/specs/openid-connect-core-1_0.html#AuthResponse

 HTTP/1.1 302 Found
  Location: https://client.example.org/cb?
    code=SplxlOBeZQQYbYS6WxSbIA
    &state=af0ifjsldkj

This is an HTTP 302 response...i.e. a browser redirect.    This is an instruction to the browser to redirect to the application with the authorization code.   There is no need for SSL validation or DNS resolution on the part of the OAuth provider as the browser will already do this (assuming the application uses an HTTPS redirect URI)

P.S.
Sorry about the number and forcefulness of my responses, but this is literally my job.   I'm fairly zealous about authentication and authentication protocols.  

Edited February 23, 2024 by Mutex001

[softworkz 4495]

After looking it up, you are right: The spec doesn't mandate it explicitly.

But it's a de-facto standard. None of the reputable SSO service providers will allow you to register without a DNS name and SSL in place. And doing differently is not a secure setup.

So that doesn't change anything about it.

[softworkz 4495]

7 minutes ago, Mutex001 said:

The "call back" to the registered endpoint of the initiator is through the browser, not through direct DNS/SSL validation by the OAuth provider (other than standard DNS and optional SSL performed by the browser).   This leaves the implementation of how that callback is handled entirely in the control of the application owner.  

You can see a typical /authorize response from the OAuth provider in the OIDC spec itself:

https://openid.net/specs/openid-connect-core-1_0.html#AuthResponse

 HTTP/1.1 302 Found
  Location: https://client.example.org/cb?
    code=SplxlOBeZQQYbYS6WxSbIA
    &state=af0ifjsldkj

This is an HTTP 302 response...i.e. a browser redirect.    This is an instruction to the browser to redirect to the application with the authorization code.   There is no need for SSL validation or DNS resolution on the part of the OAuth provider as the browser will already do this (assuming the application uses an HTTPS redirect URI)

P.S.
Sorry about the number and forcefulness of my responses, but this is literally my job.   I'm fairly zealous about authentication and authentication protocols.  

No need to excuse.

I see now where the misunderstanding comes from. What you are describing is not the kind of flow how it would be implemented in case of Emby server. In our case, an external identity  provider would not be the primary authority for controlling access to Emby server in regular operation. Instead, external identities would be mapped to internal Emby user accounts. The identity provider would only be used to perform the initial authentication which, after which the Emby authentication method will be used as normal. In that kind of flow, the identity server calls back into Emby Server.

[Mutex001 1]

1 hour ago, softworkz said:

No need to excuse.

I see now where the misunderstanding comes from. What you are describing is not the kind of flow how it would be implemented in case of Emby server. In our case, an external identity  provider would not be the primary authority for controlling access to Emby server in regular operation. Instead, external identities would be mapped to internal Emby user accounts. The identity provider would only be used to perform the initial authentication which, after which the Emby authentication method will be used as normal. In that kind of flow, the identity server calls back into Emby Server.

The only backchannel request flow where the OAuth server talks directly to an app (that I know of) are the CIBA PING and PUSH flows.   In this case, authentication happens asynchronously, potentially on another device, and the OAuth provider sends a notification to the app once authentication completes.   Yes, in this case the app typically needs to be public and SSL.

CIBA is quite uncommon in the OIDC world though, and complete overkill for Emby...it is only really common in banking/financial apps for call center/user verification purposes.

If I were to implement OIDC for Emby, I would do it just like any server-side web application.

e.g. For browser-based Emby:

1. User configures their personal Emby app at their favorite OAuth provider.   Their app may need to be SSL, but it does not need to be public or even have a CA-signed certificate as long as their browser will trust the SSL cert.  

2. User enters the app registration information (client id, client secret and OAuth provider URLs) from (1) into an Emby configuration screen.

3. When the user hits Emby the first time, Emby server determines they are not logged in, and redirects the user to the /authorize endpoint of the OIDC provider from (1), with the client id from (2)

4. OIDC provider authenticates the user, and returns an authorization code by redirecting to a (new) Emby OIDC redirect endpoint

5. Emby uses the client id and client secret from (2) to exchange the authorization code for OIDC tokens from the OIDC provider

6. Emby validates/decodes the identity token and matches the authenticated user to an existing Emby user by email address

7. Emby generates a session for the matched user.   

In this case, anyone would be able to authenticate at the OIDC provider, but only preconfigured Emby users would be authorized to access Emby or obtain an Emby session.   

 

[softworkz 4495]

12 minutes ago, Mutex001 said:

User configures their personal Emby app at their favorite OAuth provider.   Their app may need to be SSL, but it does not need to be public or even have a CA-signed certificate as long as their browser will trust the SSL cert.  

• We are not talking about browsers only.
• It needs to work for all Emby clients
• Many clients are closed systems (TVs, set-top boxes) where you can't change trusted root certs
  Also it adds unnecessary complication when every user needs to mess around with root certs on each device where they want to use an Emby app
• Which "favorite OAuth provider" allows non-SSL URLs for registration?

[softworkz 4495]

17 minutes ago, Mutex001 said:

Emby validates/decodes the identity token and matches the authenticated user to an existing Emby user by email address

No. The association needs to be made explicitly. Simply matching by e-mail address is not a safe way.

[ados8000 17]

I think it's appropriate to assume and mandate that anyone configuring SSO/OIDC with Emby is a more advanced user.
I run my own self-hosted SSO with Authentik and have certificates from a root CA.
Thinking that having self-signed can be a flat no, there are many official ways through Letsencrypt, Cloudflare and others to get a certificates from trusted root authorities.

[joshooaj 2]

22 minutes ago, ados8000 said:

I think it's appropriate to assume and mandate that anyone configuring SSO/OIDC with Emby is a more advanced user.

Another Authentik user here with a similar setup and I agree - anyone messing with OIDC is an advanced user who is likely comfortable configuring DNS and certificate automation.

I have a domain registered for the home lab, and use Traefik for reverse proxy and Let’s Encrypt certificate requests/renewals using a DNS challenge.

Authentik runs in a separate container and allows clients on my network to authenticate with all the different apps I’m running with or without internet access. I can even login to Authentik via AzureAD since I have federation setup.

It’s even possible to do this with a free DDNS domain and let’s encrypt certs without exposing your server to the internet.

[roaku 832]

If I had a magic wand I would use it to make Emby focus solely on media presentation and playback and offload all aspects of remote internet access and security to vpns and whatnot.

[Sp4x18 2]

+1

Push this thread to hopfully implement SSO for EMBY

[sgobat 3]

+1
Emby server is now my only container that still relies on LDAP  Looking forward to what the team or community can come up with

[yec5muji 6]

For what it's worth, lack of SSO support (SAML or OIDC) is keeping me from using Emby/purchasing Emby Premiere. I've been using Jellyfin for year, and while I appreciate the Jellyfin's community's efforts, Jellyfin is pretty buggy and not worth the time it takes to manage it. However, even with all these issues, I'm not moving if it means giving up SSO support.

--

There is an alternative that nobody else in this thread has mentioned yet... why not allow for authentication via HTTP header (as an option, not on by default), so that authentication can be handled by a reverse proxy for users that want it? This would entirely remove the need for SSO support baked into Emby itself (though it'd still be nice), while satisfying this feature request. Here's what setup would look like:
1. An admin would deploy Emby
2. An admin would add user accounts to Emby
3. An admin would configure Emby to look at/parse an HTTP header for the name/email/similar, ideally via a regex expression. Emby would have a configuration text box that would accept regex similar to `X-User-Email: (?<userEmail>)` so that admins can extract what is effectively a "claim" from an arbitrary HTTP header. Ideally, authentication via this header would be IP limited, or maybe use some other form of auth between Emby and the reverse proxy (next step).
4. An admin would deploy a reverse proxy that handles the entire SSO flow. This reverse proxy would pass the "user claim" HTTP header to Emby when a user is authenticated. There's a lot of options for reverse proxies here, and the community could develop an Emby-specific one if needed (removing the burden from Emby developers)

Here's what the login flow would look like:
1. A user would go to https://reverse-proxy.domain-name.tld
2. When logged out, the reverse proxy would handle the SSO login flow and not forward traffic to Emby
3. After the login flow is complete, the reverse proxy would forward all future requests to Emby, adding the `X-User-Email` (or similar) "user claim" HTTP header to every request
4.  Emby would treat these requests as requests from the authenticated user, without asking for a password/similar

 

As I see it, this would entirely remove the burden of maintaining SSO support from Emby, while supporting the feature for users that want it.

Edited August 13, 2024 by yec5muji

[joshooaj 2]

I think that’s a reasonable strategy @yec5muji, with the caveat that the various client applications will still need to offer support for an OAuth login flow.

I run several apps behind Traefik with a forward auth middleware pointing to my Authentik instance. For web apps that do not support OIDC, I add the forward auth middleware so that accessing myapp.mydomain.com results in a redirect to Authentik, and then after successful authentication, I’m redirected to the real web app which can then handle authentication using headers as you describe.

To do the same thing with Emby, the iOS, Android, (and Google TV? Not sure if it’s the exact same app as Android or not) would need the option to “login with <auth provider>”. And if you’re already adding support for an alternative login flow to the native apps, you might as well provide full server side support. Though trusting headers from the reverse proxy could be a faster way to bring SSO support if it’s a huge headache to implement OIDC support on the server.

[yec5muji 6]

> with the caveat that the various client applications will still need to offer support for an OAuth login flow.

Yea unfortunately I think adding _any_ form of support for SSO to clients is non-trivial. I don't really have a solution for this that doesn't involve shipping an entire browser with these clients, or (where supported) using the device's default browser, then logging in with a flow that you mentioned.

> Though trusting headers from the reverse proxy could be a faster way to bring SSO support if it’s a huge headache to implement OIDC support on the server.

This is my interpretation of why Emby doesn't already support this - it sounds like devs don't want really want to implement or maintain OIDC support. While I definitely would prefer first-class support for OIDC or SAML, this would at least get some form of SSO support added (after being requested for years without progress).

Edited August 13, 2024 by yec5muji

[sgobat 3]

I think Forward Auth would work for the website and there are many options for handling it like Traefik's ForwardAuth implementation or OAuth2-Proxy. However, I imagine it would be difficult to implement that on the clients? I can't think of an example client app that handles Forward Auth. As @yec5mujisaid, I'd imagine a browser would be needed.

[bzpc001 0]

Your concern stems from the observation that Emby is tailored for intranet services, whereas OSS authentication necessitates the use of DNS domains and certificates. You're seeking clarification on whether Emby can be configured with a login-free option, leveraging the local IP address directly. By doing so, you intend to leverage a frontend proxy such as Traefik, which harmoniously works with Authelia for implementing login authentication. This setup would ensure that users aren't required to re-enter their passwords.

To address your query, while Emby primarily functions within a local network environment, it does support customization for authentication processes. It's indeed feasible to configure Emby in a way that bypasses its built-in authentication when accessed via the local network IP and instead relies on a frontend proxy server for secure user authentication. Traefik, coupled with Authelia, can manage the authentication layer, enforcing login requirements before allowing access to Emby, thus eliminating the need for duplicate login prompts.

In practice, you would:

1.

Configure Emby to listen on your local network IP without requiring authentication for that specific interface.

2.

Set up Traefik as a reverse proxy, directing traffic to Emby.

3.

Integrate Authelia with Traefik to handle all authentication requests before proxying them to Emby.

This architecture allows for a streamlined user experience where external or public access requires authentication managed by Traefik and Authelia, while internal or local network access to Emby could be made more accessible without redundant login steps.

[Relocate0604 3]

I saw that someone created an OIDC implementation for Home Assistant. There are many security conserns in this regard but I guess the hope is that developers would take notice and sponser the implementation.

I am not sure if it is posible with Emby DEV to create something similar but it defenatly worth looking into. I dont think otherwise it would be implemented.

[EHRETic 4]

+1

I'd love to integrate Emby in my SSO solution topo (Authentik). LDAP works fine, but it is just a matter of standardizing the whole AND "typing the user/password once"! 

[penalte23 0]

+1

Ldap is great but SSO OAuth2 its amazing.