OpenID Connect فراہم کنندہ جوڑیں

جب آپ کا شناخت فراہم کنندہ SAML کے بجائے OpenID Connect بولتا ہو تو یہ گائیڈ استعمال کریں۔ کوئی بھی OIDC-سرٹیفائیڈ جاری کنندہ کام کرتا ہے — Pocket ID، Keycloak، Auth0، Zitadel، Google Workspace اور اُن جیسے سب ایک ہی مراحل پر چلتے ہیں؛ فرق صرف یہ ہے کہ آپ کا فراہم کنندہ یہ اقدار کہاں دکھاتا ہے۔

پیشگی تقاضے

• ایک OIDC فراہم کنندہ جہاں آپ کلائنٹ بنا سکیں — اُس کا client id اور اُس کا issuer URL نوٹ کر لیں (وہ بنیادی پتہ جس کے تحت .well-known/openid-configuration دستاویز رہتی ہے)، نیز اُس کا client secret بھی جب کلائنٹ خفیہ قسم کا ہو (پبلک PKCE کلائنٹس کے پاس کوئی نہیں ہوتا)،
• ایک Control Center سرور جس کے آپ منتظم ہوں (یعنی سرور مالک)۔

مراحل

1. ترتیبات → سرور → سنگل سائن آن کھولیں اور OpenID Connect پر سوئچ کریں۔
2. Issuer URL اور Client ID بھریں، اور Client secret (اختیاری) بھی جب فراہم کنندہ نے ایک جاری کیا ہو۔ Control Center اینڈ پوائنٹس جاری کنندہ کی معیاری discovery دستاویز سے خود ڈھونڈ لیتا ہے — فی فراہم کنندہ کوئی کنفیگریشن نہیں۔
3. فراہم کنندہ پر، اُس کلائنٹ کے لیے redirect https://<your-server>/oidc/callback رجسٹر کریں۔
4. اگر آپ کے گروپس groups کے علاوہ کسی اور کلیم کے تحت آتے ہیں تو Groups claim کا نام سیٹ کریں؛ چاہیں تو گروپس کو کرداروں سے میپ کریں (SSO کبھی مالک کا کردار نہیں دے سکتا)۔
5. رکنیت کی پالیسی چنیں (ہر ورک اسپیس میں خودکار شمولیت، یا فی ورک اسپیس دعوتیں لازمی)، سائن اِن کے لیے OpenID Connect استعمال کریں آن کریں اور کنکشن محفوظ کریں دبائیں۔
6. کنکشن ٹیسٹ کریں دبائیں — سرور جاری کنندہ کی discovery دستاویز لاتا ہے اور اُس کے اینڈ پوائنٹس کی تصدیق کرتا ہے، اس لیے سبز ٹوسٹ کا مطلب ہے کہ براؤزر کے راؤنڈ ٹرپ کے سوا سب کچھ کام کر رہا ہے۔ کلائنٹ کی رجسٹریشن بھی جانچنی ہو تو نیچے دیا گیا چیکر استعمال کریں۔
7. ایک لاگ اِن آزمائیں: ویب کنیکٹ اسکرین OpenID Connect سے سائن اِن دکھاتی ہے، یا https://<your-server>/oidc/login براہِ راست کھولیں۔

کلیمز (ای میل، نام، گروپس) آپ کا سرور جاری کنندہ کے ٹوکن اینڈ پوائنٹ سے TLS کے اوپر پڑھتا ہے — براؤزر انہیں کبھی فراہم نہیں کرتا، چنانچہ کوئی مقامی JWT دستخط کی تصدیق درکار نہیں ہوتی۔ کلائنٹ کو openid profile email اسکوپ مانگنے کی اجازت ہونی چاہیے، جو بالکل وہی ہے جو Control Center مانگتا ہے۔

چونکہ کلیمز کی تصدیق کرنے والی واحد چیز وہی TLS چینل ہے، اس لیے جاری کنندہ کا URL لازماً https ہونا چاہیے — سادہ متن والا جاری کنندہ ہر راستے میں بیٹھے حملہ آور کو بڑے پیمانے پر شناختیں جعل کرنے دیتا ہے۔ http صرف لوپ بیک جاری کنندگان (localhost، 127.0.0.1، ::1) کے لیے، مقامی ڈیولپمنٹ کے لیے قبول کیا جاتا ہے۔

پبلک کلائنٹ یا خفیہ کلائنٹ؟

ڈیفالٹ — اور تجویز کردہ — صورت ایک پبلک کلائنٹ ہے جو PKCE (RFC 7636) کے ساتھ authorization code فلو استعمال کرتا ہے: سرور کے پاس رکھا ایک بار استعمال ہونے والا code verifier سیکرٹ کی جگہ لے لیتا ہے اور ٹوکن ایکسچینج اُسی authorization درخواست سے بندھا ہوتا ہے جس نے اسے شروع کیا۔ لیک ہونے کے لیے کوئی سیکرٹ نہیں ہوتا اور چرایا گیا authorization code code verifier کے بغیر بیکار ہے۔ کچھ فراہم کنندگان اسے بناتے وقت “SPA” یا “native” کلائنٹ قسم کہتے ہیں۔

اگر آپ کے فراہم کنندہ نے اس کے بجائے خفیہ کلائنٹ جاری کیا ہو تو یا فراہم کنندہ پر کلائنٹ کو پبلک نشان زد کریں (PKCE دونوں صورتوں میں چلتا رہتا ہے)، یا کلائنٹ سیکرٹ کو کنکشن کے Client secret (اختیاری) فیلڈ میں چسپاں کر دیں۔ سیکرٹ سرور کی 0600 سیکرٹس فائل میں محفوظ ہوتا ہے (ڈیٹا بیس میں کبھی نہیں)، ٹوکن اینڈ پوائنٹ کو client_secret_post کے طور پر بھیجا جاتا ہے اور RPC پر کبھی واپس نہیں آتا؛ محفوظ کرتے وقت فیلڈ خالی چھوڑنے سے محفوظ سیکرٹ برقرار رہتا ہے۔ جب ٹوکن ایکسچینج پر کوئی لاگ اِن ناکام ہو تو سرور کا لاگ فراہم کنندہ کی اپنی غلطی کا نام لے کر بتاتا ہے (invalid_client کا مطلب تقریباً ہمیشہ یہی ہوتا ہے کہ سیکرٹ غائب ہے یا غلط ہے)۔

رسائی

لاگ اِن خود براؤزر کے ذریعے ہوتا ہے: جاری کنندہ صرف صارف کے براؤزر کو واپس /oidc/callback پر بھیجتا ہے اور آپ کا سرور ٹوکن اینڈ پوائنٹ کو ایک آؤٹ باؤنڈ HTTPS کال کرتا ہے — جاری کنندہ سے کوئی اِن باؤنڈ کنکشن درکار نہیں، اس لیے NAT کے پیچھے موجود سرور بھی کام کرتا ہے جب تک صارفین کے براؤزر اُس تک پہنچ سکیں (LAN، VPN، Tailscale، یا کوئی ٹنل)۔ SCIM پروویژنگ استثنا ہے: IdP آپ کے سرور کو براہِ راست کال کرتا ہے، جس کے لیے ٹنل یا عوامی URL درکار ہوتا ہے — SCIM سے صارفین فراہم کریں دیکھیں۔

اسی صفحے سے اپنی کنفیگریشن جانچیں

نیچے دیا گیا چیکر آپ کے براؤزر میں چلتا ہے۔ یہ آپ کے جاری کنندہ کی discovery دستاویز براہِ راست لاتا ہے، اس لیے یہ سائٹ اُسے کبھی نہیں دیکھتی، اور سرور کے قواعد لاگو کرتا ہے: ایسا https جاری کنندہ جو دستاویز سے مطابقت رکھتا ہو، جاری کنندہ کے اپنے اوریجن پر اینڈ پوائنٹس، PKCE S256 اور وہ ٹوکن توثیق کا طریقہ جو آپ کے کلائنٹ کی قسم کو درکار ہے۔ کلائنٹ ID اور سرور کے پتے کے ساتھ یہ ایک آزمائشی سائن اِن کھول سکتا ہے جو دکھاتا ہے کہ کلائنٹ اور اُس کا redirect 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.

Issuer URL

Client ID (optional)

Needed for the test sign-in.

Groups claim (optional)

Client type

Public, PKCE only Confidential, has a client secret

Never paste the secret here. The check only needs to know whether one exists.

Server address (optional)

The address your users open. Adds a reachability check and a test sign-in.

Paste the discovery document instead

Discovery document JSON

For providers that block other sites from reading it.

Check issuer