[Feature Request] OpenID Connect Authentication

Thank you for umami, it is fantastic!

Would love to see OpenID Connect as an authentication method, or even LDAP. Managing the local user accounts can be a bit tedious if there is high turn over or temporary individuals accessing the platform.

TIA

Not really sure this makes sense. OpenID is for when you want people to register an account with your site easily. With umami, it's up to the admin to allow access to others. There is no registration process.

Not really sure this makes sense. OpenID is for when you want people to register an account with your site easily. With umami, it's up to the admin to allow access to others. There is no registration process.

Not necessarily. We currently use OpenID in conjunction with an LDAP backend for most systems with no registration enabled. We do this is as many apps support OpenID but not other authentication methods such as LDAP. This allows for easier admin management as they only have to disable/enable access in the OpenID authenticator rather than that and then app itself. Additionally, this allows us to pass the authentication token to the app and allow it to log the user in directly. This eliminates the "double login" which is encountered once by the OpenID authentication provider and then again with the app itself.

Obviously not required but would definitely be helpful for centralised user management.

Additionally, this allows us to pass the authentication token to the app and allow it to log the user in directly.

Still trying to understand. When you log in, who are you logging in as? Doesn't the admin need to create accounts for everyone first?

Still trying to understand. When you log in, who are you logging in as? Doesn't the admin need to create accounts for everyone first?

The admin does not need to create the account. For our non-LDAP integrated applications, the user account is created in the application using information provided in the OpenID scopes. Typically we require the preferred_username, name, and email claims for our applications and this is the basis for the account in the platform. For most of our applications, they have LDAP integration configuration in conjunction with OpenID. LDAP in the application provides the user account in the application, while our OpenID leverages LDAP to validate user permissions for application authorization (we can filter application access by LDAP groups within the OIDC Provider). The OpenID Provider in these instances provides a "simple" SSO experience for the user and across the applications. For example, we hire a new employee and assign their account and groups within the LDAP server/Active Directory. The LDAP filters in the application are configured to allow specific groups to access the application. The OIDC Provider is configured to permit users of specific groups to log into the application, but we can also control their login experience depending on location (e.g., in the office on the LAN, no MFA required. On VPN or other subnet, MFA is required). Once they complete authentication through the OIDC Provider, the application receives the user information from the claims and attempts to match the UUID/username to an existing approved user in its LDAP configuration. If there isn't a match we're alerted by an error indicating the user DN is not located in the LDAP configuration. If the user changes departments or leaves the organisation, we remove them from the group or directory and access to the applications cease without having to remember what applications they had access to and manually removing them from each application individually. Hopefully that helps a bit more to understand the how we are leveraging this configuration. For reference, we are currently using umami with authentication disabled and controlling access strictly through the OIDC Provider, however all authenticated users can see all configured sites which isn't currently ideal. Hence the ask. Thanks for taking the time to read and understand.

There are many open source project out there who added this already. This may help implementing this. https://github.com/zorn-v/nextcloud-social-login

This issue is stale because it has been open for 60 days with no activity.

This issue was closed because it has been inactive for 7 days since being marked as stale.

I would like to see this feature, at least with auto-creation for accounts over OIDC/OAuth2.

Why is such a simple and common feature such a big deal here? Even that it needs so long discussion is telling for the project.

This feature is very much needed, and the important reason why I haven't considered deploying umami yet is the lack of SSO logic. For a platform with several components/sites, SSO support is a very important feature.

It seems to be on their roadmap for Q4 2023: https://trello.com/b/LIIz6ypc/umami-2023-roadmap

any news on this?