umami-software
External auth/OIDC
Describe the feature or enhancement
Hi!
I'm interested in tying in Umami to a collection of apps I'm self-hosting, but Umami rolling its own authentication model that can't be side-stepped make it a much larger hassle than (without exception) every other service I'm currently running, which all either support OIDC/LDAP intergration or (in more simple cases) can have have auth disabled and insert an auth check in the reverse proxy.
I see this has come up before #1112, but since that issue has been closed as stale it seems like a new issue might be warranted. With a separate authentication service (including roles like admin) has already been set up, it's a pity when that can't be reused, duplicate accounts need to be created, and there's no longer one single place to manage who has access to what resources.
Even bigger orgs need OIDC. Imagine to have to create hundreds of accounts and also make users use those instead of the SSO they use for everything else.
There was some prior discussion in https://github.com/umami-software/umami/issues/1608, pointing to next-auth.js as a possible choice to build this feature. It seems that project has evolved and changed names, to auth.js.
I think it's also worth noting that with the rise of self-hosted SSO solutions (Authentik, Zitadel, Keycloak, Authelia, Pocket ID, etc.), this is a feature that was rather niche a few years ago, but is now of increasing importance in the self-hosting space.
My org uses Okta SSO for all of its applications, and SSO is an expectation, particularly for anything data sensitive like a site analytics app, we can't have people leave the business and accidentally leave their logins in place in an app like this
SSO is literally Single Sign on. You don't want people to memorize different logins for different apps used in an Org. With SSO, they can login using their email or LDAP accounts to all the apps. This is a must feature.
It's interesting to see how quickly this has jumped up to be the most 👍'd open issue.
@mikecao: while I'm sure you've got no shortage of things that would benefit from your attention, it would be good to hear what your current thoughts are around SSO/OIDC in light of not just the issues a few years ago but the conversation here 🙂
It's something we would like to tackle after we release v3, which is taking all my time. Will probably end up implementing this, https://www.better-auth.com/docs/plugins/sso
Technically, there is already an SSO mechanism in Umami through the endpoint /sso?url={desination_url}&token={bearer_token}. It's what is used on Cloud. But you would have to generate the token yourself with createSecureToken.
Technically, there is already an SSO mechanism in Umami through the endpoint
/sso?url={desination_url}&token={bearer_token}. It's what is used on Cloud. But you would have to generate the token yourself withcreateSecureToken.
That sounds interesting, can you point some documentation or something to get going?
@Sov3rain, and also for anyone who stumbles upon this thread in the future, here's how I implemented this in a quick fix. I am not able to give the code, but hopefully my write up is enough to replicate it.
I created a Go reverse proxy (:3001) that points to the Umami instance (port :3000) for all routes, except for /login (hijacked this path) and /{provider}/callback (new path for the proxy).
If a user navigates to /login, start the OIDC/OAuth flow with your provider, giving the provider your /{provider}/callback URL as the redirect URL.
When the user gets redirected to /{provider}/callback from the OIDC provider, you can extract the code, state, etc. in the proxy code (in my case, Go). With this info, you contact the provider to generate an access token. With the access token, you can then fetch the user information to get the username and other details of the user.
Afterwards, I made a POST request to /api/auth/login with some credentials for an admin account. Auth docs here. This was to get a token for the admin account.
After obtaining the admin token, I would do a POST request to /api/users using these docs to create a user based on the info I got using the OIDC user info. For the password, I created a secret for the proxy and hashed the secret + username + any other info. That was just to ensure the password remains the same without storing it somewhere else. If the API responds with 400, the response is usually just a JSON blob that states the user already exists. In this case, you can ignore it. If it's some other response code, you'll need to fix/handle the error.
Once you are sure the user exists, you can do the same POST request to /api/auth/login but with the credentials for the user that is trying to sign in. Afterwards, redirect the user to /sso?url={destination_url}&token={generated_token} and be sure to escape the generated_token for the query parameter.
So seemingly Umami v3.0.0 was released. Wuhu! Now this feature would be cool to be included in a subversion :)
