Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Support OAuth allowed domains for self-hosted installs

Đang mở
  • Có gì không ổn?
#465 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@grootbro đang làm issue này rồi.

Từ ngày 7/9/2026.

  • #493 của @grootbro — đang mở

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
38/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
authentication, authorization

Hướng nghiên cứu

Bắt đầu bằng cách xác định các điểm đầu vào của OAuth callback và cấu hình, sau đó xác định cách các miền email đã xác minh, Google hosted-domain claims và ALLOW_REGISTRATION hiện được xử lý. Giải quyết các câu hỏi về cấu hình và hành vi đăng ký chung so với cấu hình và hành vi dành riêng cho provider trước khi triển khai; hoàn tất có nghĩa là những người dùng phù hợp có thể xác thực theo đặc tả, trong khi những người dùng không phù hợp bị từ chối và hành vi hiện có không thay đổi khi không có allowlist.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
7.1k
Fork
510
Merge trung bình
5 ngày 13 giờ
Pull request đã merge (30 ngày)
6

Chuẩn bị môi trường

  • Có Dockerfile hoặc tệp Docker Compose
  • Không có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Openpanel-dev/openpanel

Tất cả issue của Openpanel-dev/openpanel

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.