Hi! Opening this as an issue first before doing another PR/rebase, as suggested in #428.
Use case
For self-hosted OpenPanel deployments, it would be useful to enable OAuth login while restricting access to members of a company domain / Google Workspace domain.
A common setup is:
- OpenPanel is self-hosted and reachable on a public URL
- Google OAuth is enabled for convenience
- public registration is disabled with
ALLOW_REGISTRATION=false
- only users from an approved company domain should be able to sign in or create accounts through OAuth
At the moment, enabling OAuth does not provide a built-in domain allowlist, so operators need to rely on provider-side configuration or external controls. For Google OAuth, Workspace/internal setup is not always enough by itself for self-hosted deployments, and app-side enforcement would make the behavior clearer.
Proposed behavior
Add optional OAuth domain allowlisting:
- when no allowlist is configured, keep the current behavior unchanged
- when configured, reject OAuth callback users whose verified email domain is not allowed
- for Google, validate
email_verified, the email domain, and ideally the Google ID token hosted-domain claim (hd) for Workspace accounts
- matching-domain OAuth users can sign in
- matching-domain OAuth users can sign up even when
ALLOW_REGISTRATION=false
- non-matching users cannot sign in or create accounts through OAuth
Possible configuration
Generic option:
OAUTH_ALLOWED_DOMAINS=example.com,example.org
Optionally, provider-specific configuration could also be supported:
GOOGLE_ALLOWED_DOMAINS=example.com
Questions before implementation
- Would you prefer a single generic
OAUTH_ALLOWED_DOMAINS option, provider-specific options like GOOGLE_ALLOWED_DOMAINS, or both?
- For Google, should a configured domain allowlist require the
hd claim to match, or should verified email domain be enough?
- Should matching-domain OAuth be allowed to create users when
ALLOW_REGISTRATION=false, or should the allowlist only restrict login for users that already exist?
Happy to open a fresh PR if this direction makes sense.
Hi! Opening this as an issue first before doing another PR/rebase, as suggested in #428.
Use case
For self-hosted OpenPanel deployments, it would be useful to enable OAuth login while restricting access to members of a company domain / Google Workspace domain.
A common setup is:
ALLOW_REGISTRATION=falseAt the moment, enabling OAuth does not provide a built-in domain allowlist, so operators need to rely on provider-side configuration or external controls. For Google OAuth, Workspace/internal setup is not always enough by itself for self-hosted deployments, and app-side enforcement would make the behavior clearer.
Proposed behavior
Add optional OAuth domain allowlisting:
email_verified, the email domain, and ideally the Google ID token hosted-domain claim (hd) for Workspace accountsALLOW_REGISTRATION=falsePossible configuration
Generic option:
Optionally, provider-specific configuration could also be supported:
Questions before implementation
OAUTH_ALLOWED_DOMAINSoption, provider-specific options likeGOOGLE_ALLOWED_DOMAINS, or both?hdclaim to match, or should verified email domain be enough?ALLOW_REGISTRATION=false, or should the allowlist only restrict login for users that already exist?Happy to open a fresh PR if this direction makes sense.