SSO OpenID

[ados8000 8]

Is there plans on the roadmap for OpenID. I have searched but not found any indication this is in development.

With many admins taking up SSO through Authelia or Authentik to enhance security it would be great for Emby to support it.

One of the easier open standards is OpenID which the aforementioned support. Users could continue to use LDAP if they wish while others can use the arguably better SSO experience.

[horstepipe 356]

I‘d also like my Fido sticks to work with Emby apps, but I do not think this is coming soon, or probably ever.

Emby is mainly designed for local usages so this would be a big development task just a handful of people would benefit of.

 

Not sure if this could be realized with a plug-in (without additional core changes),  but I guess if this will happen some day then this way.

[ados8000 8]

Well that's a big shame, I think a reasonable amount of people will benefit as SSO has become more popular.

I'm not sure what you mean by local usages, LDAP is already supported by a plug-in, so maybe it's another plugin in this case.

Edited December 7, 2022 by ados8000

[Luke 37051]

I haven't looked into what it would take to support this, but assuming it could be done server-side without requiring changes to every single app, then in theory an authentication plugin for OpenID could be built just like Ldap.

[ados8000 8]

44 minutes ago, Luke said:

I haven't looked into what it would take to support this, but assuming it could be done server-side without requiring changes to every single app, then in theory an authentication plugin for OpenID could be built just like Ldap.

I'm not sure on that one, hopefully the login authentication passed by the client apps to the server can do it with little modification.

OpenID would allow a multitude of services to connect to Emby, you could have your Microsoft account authorize your login.

Edited December 8, 2022 by ados8000
Additional info

[softworkz 3335]

1 hour ago, Luke said:

but assuming it could be done server-side without requiring changes to every single app,

No, it can't be done like this.  With the LDAP plugin, Emby gets the user name and password of every user who logs on in clear text and the server attempts to log on with these credentials at the LDAP server. 
Such procedures are totally forbidden with OAuth/OIDC. It is a core feature of those implementations that you must and may never give your password to any 3rd party. You only sign-in at the site where the account is from that you are using to sign-in.

There are multiple authentication "flows".
The most typical one is browser redirection, which means that a client app needs to redirect you to the web site that has issued your account. Once you have logged in there, you get returned to the app, while in the background of this procedure, tokens are exchanged between the 3 parties: The app with the issuer website, then the app with Emby Server and eventually Emby Server itself with the issuer website.
There's also a "flow" for devices which cannot redirect (because they aren't browser-based): With the "device flow", the client tells the user a website to open (separately, e.g. via mobile device), the user logs on to the website and gets a numeric code, which it then enters into the client app. The rest is the same like above.

Assuming Emby Server (and all clients!) would support this, there are additional caveats:

• The Emby Server needs to have a  DNS registration of your own domain (no dynamic dns) and must be continuously and reliably available 
• As an owner of an Emby server who wants to set this up, you need to go quite a way to get this working:
  • You need to open a developer account with the sign-in provider through which you want to allow users to sign on to your server
  • And you need to do this for every sign-in provider you want to suppport.
    For example: you want to allow users to log in with their 
    • Google accounts,
    • Facebook accounts,
    • GitHub accounts and
    • Microsoft accounts
  • With all of them, you will need to open a developer account and then, you need to register your "app/service" (=Emby Server) for OAuth/OIDC authentication
  • The procedures are quite different with all of them and the data you get and will need to set up Emby server accordingly looks differently, and it's quite a process to get it all figured out
• Finally, there's another complication: when you want to allow users to log in with their Google accounts (for example), that doesn't mean that you want to allow everybody with a Google account to log into your server, which means in turn that you need a mechanism for selection. Possible methods are
  • By invite link
    you actively send invites to users you want to allow
  • Approval Queue
    Users who authenticate the first time are put into an approval queue where you regularly need to grant or deny access
  • Probably the most simple one is to only allow existing users (who already have a normal account on your Emby server) to also set up a 3rd party login for their account.

I have done all this for a (yet unreleased) project, and what I can say is that it's nice when it's working, but it takes a little effort - and I'm talking just about the setup that users need to do. 

Edited December 8, 2022 by softworkz

[xyrodileas 3]

On 12/8/2022 at 12:25 AM, softworkz said:

Assuming Emby Server (and all clients!) would support this, there are additional caveats:

• The Emby Server needs to have a  DNS registration of your own domain (no dynamic dns) and must be continuously and reliably available 
• As an owner of an Emby server who wants to set this up, you need to go quite a way to get this working:
  • You need to open a developer account with the sign-in provider through which you want to allow users to sign on to your server
  • And you need to do this for every sign-in provider you want to suppport.
    For example: you want to allow users to log in with their 
    • Google accounts,
    • Facebook accounts,
    • GitHub accounts and
    • Microsoft accounts
  • With all of them, you will need to open a developer account and then, you need to register your "app/service" (=Emby Server) for OAuth/OIDC authentication
  • The procedures are quite different with all of them and the data you get and will need to set up Emby server accordingly looks differently, and it's quite a process to get it all figured out
• Finally, there's another complication: when you want to allow users to log in with their Google accounts (for example), that doesn't mean that you want to allow everybody with a Google account to log into your server, which means in turn that you need a mechanism for selection. Possible methods are
  • By invite link
    you actively send invites to users you want to allow
  • Approval Queue
    Users who authenticate the first time are put into an approval queue where you regularly need to grant or deny access
  • Probably the most simple one is to only allow existing users (who already have a normal account on your Emby server) to also set up a 3rd party login for their account.

 

 The caveats you mention can be mitigated if you selfhost your identity provider as well. In my case it's Keycloak. Still require a lot of configuration of course.

[quintus753 0]

I apologize for the thread necromancy but I just wanted to chime in and agree with xyrodileas that the main reason I would want this feature would be to authenticate against my selfhosted Authentik rather than Google / Facebook / Microsoft / Github.

(Less for me, and more because I'm the only one in my family who actually securely saves passwords and getting constant calls of 'I forget my password for X!' is really annoying. Authentik lets them change it themselves. I realize I could just use LDAP, but prefer enforcing MFA.)

Edited February 28, 2023 by quintus753

[Avsynthe 0]

This exists as a plugin for Jellyfin. It supports both OIDC and SAML. Could this be altered for use with Emby?

https://github.com/9p4/jellyfin-plugin-sso

[sydlexius 241]

13 hours ago, Avsynthe said:

This exists as a plugin for Jellyfin. It supports both OIDC and SAML. Could this be altered for use with Emby?

https://github.com/9p4/jellyfin-plugin-sso

Be aware that almost no developer of closed-source software (Emby) is going to incorporate code that leverages GPL 2/3-licensed code.  Any portion of their code that depends on such code would itself need to be opened up (in Emby's case, modifications to dependencies like ffmpeg are open/shared).  Further, simply looking at such code itself is legally fraught, as it could be considered a derivative work.  In OIDC's case, they provide a reference implementation for .NET (licensed under Apache 2.0, which is far more permissive).  Similar implementation details for SAML are available from MS.

I'd love to see improvements to security and authentication, but I would not recommend providing references to code that could embroil the developers of a product I depend on (Emby, or otherwise).

[Luke 37051]

3 minutes ago, sydlexius said:

Be aware that almost no developer of closed-source software (Emby) is going to incorporate code that leverages GPL 2/3-licensed code.  Any portion of their code that depends on such code would itself need to be opened up (in Emby's case, modifications to dependencies like ffmpeg are open/shared).  Further, simply looking at such code itself is legally fraught, as it could be considered a derivative work.  In OIDC's case, they provide a reference implementation for .NET (licensed under Apache 2.0, which is far more permissive).  Similar implementation details for SAML are available from MS.

I'd love to see improvements to security and authentication, but I would not recommend providing references to code that could embroil the developers of a product I depend on (Emby, or otherwise).

It would be an open source plugin if we did it and incorporated gpl code. But most likely we wouldn't use the code to begin with.

[magicdian 0]

It would be great if emby can support OIDC.

[joshooaj 1]

I’d also love to see OIDC support. In my environment I have Emby running as a container behind traefik for reverse-proxy.

Authentik is my identity provider, and OIDC is my protocol preference, but it supports LDAP so I suppose I’ll figure that out and use it for now.

It feels like OIDC is the standard du jour, but most modern identity management systems seem to provide support for multiple standards - OIDC, SAML, LDAP, etc. So while LDAP feels dated, it can often still be used.

[JordanReich 4]

Dropping this here:
https://emby.media/community/index.php?/topic/77083-saml2oauth-login-method-ie-okta/

These requests, to my last post in the thread above, are not dissimilar.

[xyrodileas 3]

On 4/6/2023 at 12:25 AM, Avsynthe said:

This exists as a plugin for Jellyfin. It supports both OIDC and SAML. Could this be altered for use with Emby?

https://github.com/9p4/jellyfin-plugin-sso

I've been debating if I should switch to Jellyfin instead of Emby since this released.

Sad to ditch my Emby premium pass, but having a proper OIDC integration is more important to me.
Will probably switch to Jellyfin in April if Emby did not progress. Hopefully I will have time to handle the migration.

Edited December 4, 2023 by xyrodileas

[softworkz 3335]

32 minutes ago, xyrodileas said:

On 4/6/2023 at 6:25 AM, Avsynthe said:

This exists as a plugin for Jellyfin. It supports both OIDC and SAML. Could this be altered for use with Emby?

https://github.com/9p4/jellyfin-plugin-sso

I've been debating if I should switch to Jellyfin instead of Emby since this released.

Sad to ditch my Emby premium pass, but having a proper OIDC integration is more important to me.
Will probably switch to Jellyfin in April if Emby did not progress. Hopefully I will have time to handle the migration.

How about trying out this solution before setting up any deadlines?

[xyrodileas 3]

28 minutes ago, softworkz said:

How about trying out this solution before setting up any deadlines?

Already did, also used LDAP for a couple of years with Emby, thanks for the advise !
MediaCenter is the last service I need to integrate to my OIDC. While I understand that this feature may not get prioritized as security is not always a priority for the typical user,  it is a priority for me as I don't like Emby directly handling the auth part (I prefer emby to focus on what it does best) and not integrating properly with my other services.

I've dropped LDAP support due to the OIDC one-way sync limitation that I had, as well as trying to move away from legacy protocols.
Also this from your previous post, clear text creds : "With the LDAP plugin, Emby gets the user name and password of every user who logs on in clear text and the server attempts to log on with these credentials at the LDAP server. "

Edited December 4, 2023 by xyrodileas

[softworkz 3335]

39 minutes ago, xyrodileas said:

Already did,

So it's sufficient for you that it's working only when accessing Emby with a browser, but not with any of the apps? And that you have a different identity when signing in via SSO opposed to Emby login is acceptable for you?

15 minutes ago, xyrodileas said:

While I understand that this feature may not get prioritized as security is not always a priority for the typical user,  it is a priority for me as I don't like Emby directly handling the auth part (I prefer emby to focus on what it does best) and not integrating properly with my other services.

I sympathize a lot with the idea in general. In this case, it's not about de-priorization of security related matters. It's primarily about the fact that this cannot be implemented as a self-contained and rounded-up feature, as a quick and concise benefit for users.

Let me explain by example what I mean by this:

Assume there's a feature request for allowing users to change the size of subtitle text shown on the screen:
(we already have that, just for the sake of having an example)

When we go and implement that, we would:

• Add an option to a settings page
• Change player/subtitle frameworks to read the new setting and apply it accordingly

Eventually, we ship that feature, users will be happy and we are done with it, put a checkmark behind and don't have to deal with it any further.

 

The feature which is being requested here is of a totally different nature. Not only that we would need to implement this in all of the apps for once. There are often small nuances between different SSO providers and that means that any changes which are required to support a certain SSO provider would be made each time in all of the apps.

And those changes and adjustments are also the core of the problem (I think I have sufficiently detailed those things in my earlier post): 
We would never be done with this feature - just the opposite. Once we would have an initial implementation, it would mark the beginning of a continuous amount of work that will be required for supporting it. We would be facing countless questions and issues about settings this up and why it doesn't work in each user's specific kind of setup and requests for supporting SSO provider X or Y.
The inevitable outcome of implementing this would mean to put a huge load onto our shoulders for making just a small amount of users happy (and some perhaps even less happy than when we would have never tried to provide it).  

All in all, there's more to lose than to win in this case. It's not a coincidence that our forkers didn't implement it. The referenced plugin is of little value IMO, it's experimental (self-declared as 'alpha') and very limited.

[softworkz 3335]

I've been still thinking about ways how this could be made possible while keeping ourselves out of the "line of fire"  

The typical way for such things is either provide it in form of a plugin or allow community-provided plugins to provide this functionality. From the reasoning given above, it would rather have to be the latter. The problem though is that a plugin alone doesn't have the ability to implement this as a compound solution.

But what I could imagine in this context might be that we could put a plugin into the position to implement this feature. For this, we would still need to add an implementation to all the apps, but it could be based on the "Device Flow" model for authentication, which works similarly to Emby Connect login in our apps where you go to a website, log in there and  get a one-time PIN which you need to enter in the app to get logged in.
For this, we would only provide this simple interaction, implemented within the apps. Everything else would have to be driven by an Emby Server plugin (provided by the community).

This is just an idea, I can't say whether we're going to do this, but the bottom line is that a feature request for:

"Allow a server plugin to provide SSO capabilities with one-time-PIN (device flow) login to apps"

would have substantially better chances to be taken on than "Provide SSO for all apps and be compatible with arbitrary SSO providers".

[ReichJordan 2]

This idea is to a degree more in alignment with the points I posted in the link above and would seem to be an acceptable trade off. My 2c.

[xyrodileas 3]

I didn't wanted to sound like i'm denigrating the work done on Emby, I love the product and been using it for years. I prefer Emby for the features and stability. Plex's authentication system is what made me choose Emby in the first place.
Thanks for taking the time to answer to your users !

The work to decouple the login from the rest  of the application and integrate it in apps is understandably huge, but I still believe the benefits of offloading authentication (security, UX) to a standardized SSO system outweigh the initial complexities. By delegating the authentication process Emby can focus on media management and streaming.

I tend to prefer OpenID over SAML (SAML is a bit older), but both are good standard used in a lots of corp applications and integrate in most Identity Providers (Azure, Okta, Keycloak, Authelia, etc.).

4 hours ago, softworkz said:

But what I could imagine in this context might be that we could put a plugin into the position to implement this feature. For this, we would still need to add an implementation to all the apps, but it could be based on the "Device Flow" model for authentication, which works similarly to Emby Connect login in our apps where you go to a website, log in there and  get a one-time PIN which you need to enter in the app to get logged in.

For this, we would only provide this simple interaction, implemented within the apps. Everything else would have to be driven by an Emby Server plugin (provided by the community).

This is just an idea, I can't say whether we're going to do this, but the bottom line is that a feature request for:

"Allow a server plugin to provide SSO capabilities with one-time-PIN (device flow) login to apps"

would have substantially better chances to be taken on than "Provide SSO for all apps and be compatible with arbitrary SSO providers".

Agreed that Device Code Flow is very good enough to setup a device. As you said the plugin can handle the creation of a device code that can then be given to the app, to login the user that was previously binded with the Identity Provider, like the LDAP plugin do. This might minimize the need to refactor the user system and the apps  less to be "aware" of the protocol, as long as they can validate the code with the server.

[ebr 14910]

22 minutes ago, xyrodileas said:

The work to decouple the login from the rest  of the application and integrate it in apps is understandably huge, but I still believe the benefits of offloading authentication (security, UX) to a standardized SSO system outweigh the initial complexities.

Hi.  Perhaps for you but I can tell you that you are very far from a typical home server user.  Attempting to setup and manage the SSO would be much more complex to most of our users I believe.

Thus, as some sort of plug-in as opposed to core functionality is probably where this would end up.

[softworkz 3335]

5 minutes ago, xyrodileas said:

The work to decouple the login from the rest  of the application and integrate it in apps is understandably huge, but I still believe the benefits of offloading authentication (security, UX) to a standardized SSO system outweigh the initial complexities. By delegating the authentication process Emby can focus on media management and streaming.

There won't be any "decoupling" or "offloading". This isn't possible because SSO is cloud-based and requires the Emby Server to be publicly reachable with a registered DNS name and SSL setup and a fixed IP address (dynamic dns is not a good choice here). Only a fraction of users will have that nor even want that. Many even prefer a completely closed system which is not accessible from outside in any way. And while SSO provides advantages in some ways, many others will also legitimately argue:

"Why should I need or use a 3rd party for being able to log into my own Emby Server?"

This means that the integrated authentication won't go away. All the involved complexity for an SSO implementation would need to be covered by a community plugin, I cannot imagine that we will go and implement the OAuth redirection flow in the apps - not even the device flow. What I meant instead is that we could perhaps provide only the UI interaction part for the device flow (which is pretty trivial). But this would need to be driven by a server plugin which is covering all the complexity.

[Mutex001 1]

On 04/12/2023 at 15:46, softworkz said:

There won't be any "decoupling" or "offloading". This isn't possible because SSO is cloud-based and requires the Emby Server to be publicly reachable with a registered DNS name

Why does the Emby server need public DNS?  For web clients, all OIDC communication can be done from the browser.  As long as the browser can see both the auth provider and the Emby server (at a fixed location) it should be fine.

For thick clients, typically they either use an embedded browser component (so work exactly like a regular browser), or device code flow where auth happens in conjunction with another device.

There isn't any direct communication from the auth server to the relying party with OIDC/OAuth2.

The Emby server will need to be reachable by the browser at a fixed address, but that can be resolved by private DNS, hosts file or a fixed IP.   It also doesn't strictly need to be SSL, but IIRC some providers require this 

 

 

Edited February 22 by Mutex001

[softworkz 3335]

On 2/22/2024 at 5:49 AM, Mutex001 said:

Why does the Emby server need public DNS?  For web clients, all OIDC communication can be done from the browser.  As long as the browser can see both the auth provider and the Emby server (at a fixed location) it should be fine.

No it isn't.

On 2/22/2024 at 5:49 AM, Mutex001 said:

There isn't any direct communication from the auth server to the relying party with OIDC/OAuth2.

There is.

On 2/22/2024 at 5:49 AM, Mutex001 said:

The Emby server will need to be reachable by the browser at a fixed address, but that can be resolved by private DNS, hosts file or a fixed IP.   It also doesn't strictly need to be SSL, but IIRC some providers require this 

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.