Add domain allowlist

[aablsk]

What does this PR do?

This PR introduces a new environment variable "AUTH_ALLOWED_DOMAINS" that acts as an "allowlist" for domains to login to the langfuse instance.

Motivation: I'd love a more secure way to onboard people for the self-hosted instance. A boolean toggle to turn off/on signups is insufficient for our requirements. Restricting signups to certain domain(s) is sufficient for CHAPTR's requirements.

🚨 Important security considerations 🚨

This domain allowlisting has certain nuances to it, depending on the provider used.

1. It is not secure if AUTH_DISABLE_USERNAME_PASSWORD is not set to true as there is no email verification. Anyone with knowledge of the allowed domains could still sign up with a non-existent email as long as the email's string has an allowed domain in it.
2. For the Google provider we use the hd claim on the profile as this seems to be the only secure way to validate the domain according to this Github Thread.
3. For Azure AD provider this has not been tested as I don't have access to an Azure AD and related credentials. Additionally, it seems like this might have the same issues as the Google OAuth Provider (https://www.descope.com/blog/post/noauth) in which case the email may not be trusted and thus the implementation of the domain validation could be exploited. I am unaware how a domain can be properly verified for the Azure AD provider.

UI considerations

Currently, if the sign-in fails, the following screen is shown, which does not adhere to the langfuse visual identity:

Type of change

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update (we should document the new env var, what it does and the above limitations and security concerns)

Mandatory Tasks

• Make sure you have self-reviewed the code. A decent size PR without self-review might be rejected.

Checklist

✅ I haven't read the contributing guide
✅ My code doesn't follow the style guidelines of this project (npm run prettier)
✅ I haven't commented my code, particularly in hard-to-understand areas
✅ I haven't checked if my PR needs changes to the documentation
✅ I haven't checked if my changes generate no new warnings (npm run lint)
❌ I haven't added tests that prove my fix is effective or that my feature works
-> I'd like to understand which tests and what coverage would be expected for this feature
🤷 I haven't checked if new and existing unit tests pass locally with my changes (same number of tests fail before and after the change for me locally)

[vercel]

@aablsk is attempting to deploy a commit to the langfuse Team on Vercel.

A member of the Team first needs to authorize it.

[aablsk]

@marcklingen is there anything I can do to push this forward?

[marcklingen]

Hi @aablsk, thanks again for your contribution on this and sorry for the delay.

I understand that it is very unclear if we can extend this logic to AzureAD, thereby Langfuse might get less secure when this setting is misinterpreted.

Until now, I recommended teams to restrict the OAuth app they create to their own google workspace account or AzureAD tenant. Thereby the OAuth app itself blocks all external users. I think this is secure and I'd probably go for adding this to the docs and closing this PR. What do you think? Is there a case that would require AUTH_ALLOWED_DOMAINS?

[aablsk]

Thank you for getting back to me, @marcklingen! 🙇

I understand that it is very unclear if we can extend this logic to AzureAD, thereby Langfuse might get less secure when this setting is misinterpreted.

I agree, which is why I originally proposed only adding this logic for the Google provider with a google-specific domain allow-list.

Until now, I recommended teams to restrict the OAuth app they create to their own google workspace account or AzureAD tenant. Thereby the OAuth app itself blocks all external users. I think this is secure and I'd probably go for adding this to the docs and closing this PR. What do you think? Is there a case that would require AUTH_ALLOWED_DOMAINS?

Unfortunately, for us this is not an option as we need to allow different domains that belong to multiple Workspace accounts due to the infrastructure setup of the business organisation in which we're embedded. This might be just a corner case, which means that we're happy to continue with maintaining our own fork.

[marcklingen]

Thanks for the clarification and then let's add this to Langfuse (maintaining a fork isn't fun). I'd suggest to go for AUTH_GOOGLE_ALLOWED_DOMAINS and only apply this flag to Google users to make sure this is not misunderstood leading to decreased security. What do you think?