اتصال ارائه‌دهندهٔ OpenID Connect
از این راهنما استفاده کنید وقتی ارائه‌دهندهٔ هویت شما به‌جای SAML از OpenID Connect حرف می‌زند. هر صادرکنندهٔ دارای گواهی OIDC کار می‌کند — Pocket ID، Keycloak، Auth0، Zitadel، Google Workspace و دیگران همه همین گام‌ها را دنبال می‌کنند؛ تنها جایی که ارائه‌دهندهٔ شما این مقدارها را نشان می‌دهد متفاوت است.
پیش‌نیازها
بخش با عنوان “پیش‌نیازها”- یک ارائه‌دهندهٔ OIDC که بتوانید در آن کلاینتی بسازید — شناسهٔ کلاینت
و URL صادرکننده آن را یادداشت کنید (پایه‌ای که سند
.well-known/openid-configurationزیر آن قرار دارد)، به‌همراه راز کلاینت آن وقتی کلاینت از نوع محرمانه است (کلاینت‌های عمومی PKCE رازی ندارند)، - یک سرور Control Center که خودتان اداره می‌کنید (مالک سرور).
گام‌ها
بخش با عنوان “گام‌ها”- تنظیمات → سرور → ورود یکپارچه را باز کنید و به OpenID Connect سوئیچ کنید.
- URL صادرکننده و شناسهٔ کلاینت و راز کلاینت (اختیاری) را پر کنید — اگر ارائه‌دهنده یکی صادر کرده باشد. Control Center نقطه‌های پایانی را از سند کشف استاندارد صادرکننده پیدا می‌کند — بدون پیکربندی مخصوص هر ارائه‌دهنده.
- نزد خود ارائه‌دهنده، نشانی بازگشت
https://<your-server>/oidc/callbackرا روی آن کلاینت ثبت کنید. - اگر گروه‌های شما زیر ادعایی غیر از
groupsقرار دارند، نام ادعای گروه‌ها را تنظیم کنید؛ اگر خواستید گروه‌ها را به نقش‌ها نگاشت کنید (SSO هرگز نمی‌تواند نقش مالک را بدهد). - سیاست عضویت را انتخاب کنید (افزودن خودکار به همهٔ فضاهای کاری، یا نیاز به دعوت برای هر فضای کاری)، استفاده از OpenID Connect برای ورود را روشن کنید و ذخیرهٔ اتصال را بزنید.
- آزمایش اتصال را بزنید — سرور سند کشف صادرکننده را می‌گیرد و نقطه‌های پایانی‌اش را تأیید می‌کند، پس یک توست سبز یعنی همه‌چیز جز رفت‌وبرگشت مرورگر کار می‌کند. برای بررسی ثبت کلاینت هم، از بررسی‌کنندهٔ پایین استفاده کنید.
- یک ورود انجام دهید: صفحهٔ اتصال وب ورود با OpenID Connect را نشان
می‌دهد، یا مستقیماً
https://<your-server>/oidc/loginرا باز کنید.
ادعاها (ایمیل، نام، گروه‌ها) توسط سرور شما روی TLS از نقطهٔ پایانی توکن
صادرکننده خوانده می‌شوند — مرورگر هرگز آن‌ها را تأمین نمی‌کند، پس هیچ
تأیید امضای JWT محلی در کار نیست. کلاینت باید اجازه داشته باشد دامنهٔ
openid profile email را درخواست کند، که دقیقاً همان چیزی است که
Control Center می‌خواهد.
چون آن کانال TLS تنها چیزی است که ادعاها را احراز می‌کند، URL صادرکننده
باید https باشد — صادرکنندهٔ متن‌روشن به هر مهاجم میان‌مسیری اجازه
می‌دهد هویت‌ها را یکجا جعل کند. http فقط برای صادرکننده‌های لوپ‌بک
(localhost، 127.0.0.1، ::1) و برای توسعهٔ محلی پذیرفته می‌شود.
پیکربندی خود را از همین صفحه بررسی کنید
بخش با عنوان “پیکربندی خود را از همین صفحه بررسی کنید”بررسی‌کنندهٔ زیر در مرورگر شما اجرا می‌شود. سند کشف صادرکنندهٔ شما را مستقیماً می‌گیرد، پس این سایت هرگز آن را نمی‌بیند، و قواعد سرور را اعمال می‌کند: صادرکنندهٔ https که با سند مطابقت دارد، نقطه‌های پایانی روی مبدأ خود صادرکننده، PKCE با S256 و روش احراز هویت توکنی که نوع کلاینت شما لازم دارد. با یک شناسهٔ کلاینت و نشانی سرور، می‌تواند یک ورود آزمایشی باز کند که نشان می‌دهد کلاینت و URI بازگشتش ثبت شده‌اند یا نه. هیچ‌وقت راز کلاینت را نمی‌خواهد.
Runs in your browserYour browser fetches the discovery document straight from your issuer. Add a server address and it also asks that server which sign-in methods it offers. This site never receives what you type.
Test sign-in at your provider
- Your provider's sign-in or consent page: the client ID and redirect URI are registered. You can close the tab.
- An error at your provider: it names what to fix, usually a redirect URI that is not registered or an unknown client ID.
- Your server's "Sign-in failed" page: also a pass. The provider accepted the request and sent you back; your server refuses it only because this page started the sign-in, not your server.