SSO OpenID

[sydlexius 243]

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 3339]

@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 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 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 by Mutex001

[softworkz 3339]

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 3339]

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 3339]

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 3339]

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 8]

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 1]

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 795]

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.