Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Support OAuth allowed domains for self-hosted installs

オープン
  • 何か問題がありますか？
#465 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@grootbro がすでに取り組んでいます。

2026年9月7日 から。

  • #493 @grootbro による — オープン

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
38/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
authentication, authorization

調査の方向性

まず OAuth コールバックと設定のエントリポイントを特定し、検証済みメールドメイン、Google hosted-domain claims、AL​​LOW_REGISTRATION が現在どのように扱われているかを確認します。実装する前に、汎用的な設定およびサインアップ動作とプロバイダー固有の設定およびサインアップ動作に関する疑問を解決してください。完了とは、条件に一致するユーザーが指定どおりに認証でき、一致しないユーザーが拒否され、allowlist がない場合は既存の動作が変更されないことを意味します。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
TypeScript
スター
7.1k
フォーク
510
平均マージ
7日 2時間
マージ済み PR（30日）
7

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートなし
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Openpanel-dev/openpanel のほかの issue

Openpanel-dev/openpanel の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。