کچھ مہینے پہلے، میں اپنی سینکڑوں اندرونی ایپلی کیشنز تک رسائی کا انتظام کرنے کے لیے ایک OpenID Connect سرور نافذ کر رہا تھا۔ ہماری اپنی پیش رفت سے، چھوٹے پیمانے پر آسان، ہم ایک عام طور پر قبول شدہ معیار پر چلے گئے ہیں۔ مرکزی سروس کے ذریعے رسائی نیرس آپریشنز کو بہت آسان بناتی ہے، اجازتوں کو لاگو کرنے کی لاگت کو کم کرتی ہے، آپ کو بہت سے تیار حل تلاش کرنے کی اجازت دیتی ہے اور نئے کو تیار کرتے وقت آپ کے دماغ کو ریک نہیں کرتے ہیں۔ اس مضمون میں، میں اس منتقلی اور ان رکاوٹوں کے بارے میں بات کروں گا جنہیں ہم پُر کرنے میں کامیاب رہے۔
بہت عرصہ پہلے... یہ سب کیسے شروع ہوا۔
کچھ سال پہلے، جب دستی کنٹرول کے لیے بہت زیادہ داخلی درخواستیں تھیں، ہم نے کمپنی کے اندر رسائی کو کنٹرول کرنے کے لیے ایک درخواست لکھی۔ یہ ایک سادہ ریل ایپلی کیشن تھی جو ملازمین کے بارے میں معلومات والے ڈیٹا بیس سے منسلک تھی، جہاں مختلف فنکشنلٹی تک رسائی کو ترتیب دیا گیا تھا۔ اسی وقت، ہم نے پہلا SSO اٹھایا، جو کلائنٹ کی طرف سے ٹوکنز کی تصدیق اور اجازت دینے والے سرور پر مبنی تھا، ٹوکن کو کئی پیرامیٹرز کے ساتھ خفیہ کردہ شکل میں منتقل کیا گیا اور اجازت دینے والے سرور پر تصدیق کی گئی۔ یہ سب سے آسان آپشن نہیں تھا، کیونکہ ہر داخلی ایپلیکیشن کو منطق کی کافی پرت کو بیان کرنا ہوتا تھا، اور ملازمین کے ڈیٹا بیس کو اجازت دینے والے سرور کے ساتھ مکمل طور پر ہم آہنگ کیا جاتا تھا۔
کچھ وقت کے بعد، ہم نے مرکزی اختیار کے کام کو آسان بنانے کا فیصلہ کیا۔ ایس ایس او کو بیلنس میں منتقل کر دیا گیا۔ OpenResty کی مدد سے، Lua میں ایک ٹیمپلیٹ شامل کیا گیا جو ٹوکنز کو چیک کرتا تھا، جانتا تھا کہ درخواست کس درخواست پر جا رہی ہے، اور چیک کر سکتا ہے کہ آیا وہاں رسائی ہے۔ اس نقطہ نظر نے اندرونی ایپلی کیشنز تک رسائی کو کنٹرول کرنے کے کام کو بہت آسان بنا دیا - ہر ایپلیکیشن کے کوڈ میں، اضافی منطق کو بیان کرنا مزید ضروری نہیں رہا۔ نتیجے کے طور پر، ہم نے ٹریفک کو بیرونی طور پر بند کر دیا، اور درخواست کو خود اجازت کے بارے میں کچھ معلوم نہیں تھا۔
تاہم ایک مسئلہ حل طلب ہی رہا۔ ان ایپلی کیشنز کے بارے میں کیا ہے جن کو ملازمین کے بارے میں معلومات کی ضرورت ہے؟ اجازت کی خدمت کے لیے API لکھنا ممکن تھا، لیکن پھر آپ کو ایسی ہر درخواست کے لیے اضافی منطق شامل کرنا ہوگی۔ اس کے علاوہ، ہم اپنی خود سے لکھی ہوئی ایپلی کیشنز میں سے ایک پر انحصار سے چھٹکارا حاصل کرنا چاہتے تھے، جو بعد میں ہمارے اندرونی اجازت کے سرور پر اوپن سورس میں ترجمہ کیا جائے گا۔ اس پر کسی اور وقت بات کریں گے۔ دونوں مسائل کا حل OAuth تھا۔
عام معیارات پر
OAuth ایک قابل فہم، عام طور پر منظور شدہ اجازت کا معیار ہے، لیکن چونکہ صرف اس کی فعالیت ہی کافی نہیں ہے، اس لیے انہوں نے فوری طور پر OpenID Connect (OIDC) پر غور کرنا شروع کیا۔ OIDC بذات خود کھلی توثیق کے معیار کا تیسرا نفاذ ہے، جو OAuth 2.0 پروٹوکول (ایک کھلا اجازت دینے والا پروٹوکول) پر ایک ایڈ آن میں چلا گیا ہے۔ یہ حل آخری صارف کے بارے میں ڈیٹا کی کمی کے مسئلے کو ختم کرتا ہے، اور اجازت فراہم کرنے والے کو تبدیل کرنا بھی ممکن بناتا ہے۔
تاہم، ہم نے ایک مخصوص فراہم کنندہ کا انتخاب نہیں کیا اور اپنے موجودہ اجازت دینے والے سرور کے لیے OIDC کے ساتھ انضمام شامل کرنے کا فیصلہ کیا۔ اس فیصلے کے حق میں یہ حقیقت تھی کہ او آئی ڈی سی آخری صارف کی اجازت کے معاملے میں بہت لچکدار ہے۔ اس طرح، آپ کے موجودہ اجازت کے سرور پر OIDC سپورٹ کو نافذ کرنا ممکن تھا۔
ہمارے اپنے OIDC سرور کو نافذ کرنے کا ہمارا طریقہ
1) ڈیٹا کو مطلوبہ شکل میں لایا
OIDC کو مربوط کرنے کے لیے، یہ ضروری ہے کہ صارف کے موجودہ ڈیٹا کو ایک ایسی شکل میں لایا جائے جو معیار کے مطابق قابل فہم ہو۔ OIDC میں اسے کلیمز کہتے ہیں۔ دعوے بنیادی طور پر صارف کے ڈیٹا بیس (نام، ای میل، فون، وغیرہ) میں حتمی فیلڈز ہیں۔ موجود ہے۔ ، اور ہر وہ چیز جو اس فہرست میں شامل نہیں ہے اپنی مرضی کے مطابق سمجھا جاتا ہے۔ لہذا، پہلا نکتہ جس پر آپ کو توجہ دینے کی ضرورت ہے اگر آپ موجودہ OIDC فراہم کنندہ کا انتخاب کرنا چاہتے ہیں تو وہ ہے نئے برانڈز کی آسانی سے تخصیص کا امکان۔
ہال مارکس کے گروپ کو مندرجہ ذیل ذیلی سیٹ میں ملایا گیا ہے - دائرہ کار۔ اجازت کے دوران، مخصوص برانڈز تک رسائی کی درخواست کی جاتی ہے، بلکہ اسکوپس تک، چاہے دائرہ کار کے کچھ برانڈز کی ضرورت نہ ہو۔
2) ضروری گرانٹس کو لاگو کیا
OIDC انضمام کا اگلا حصہ اجازت کی قسموں کا انتخاب اور نفاذ ہے، نام نہاد گرانٹس۔ منتخب کردہ درخواست اور اجازت دینے والے سرور کے درمیان تعامل کا مزید منظر نامہ منتخب گرانٹ پر منحصر ہوگا۔ صحیح گرانٹ کے انتخاب کے لیے ایک مثالی اسکیم نیچے دی گئی تصویر میں دکھائی گئی ہے۔
اپنی پہلی درخواست کے لیے، ہم نے سب سے عام گرانٹ، اجازت نامے کا استعمال کیا۔ دوسروں سے اس کا فرق یہ ہے کہ یہ تین قدموں پر مشتمل ہے، یعنی۔ اضافی ٹیسٹنگ سے گزر رہا ہے۔ سب سے پہلے، صارف اجازت کی اجازت کے لیے درخواست کرتا ہے، ایک ٹوکن وصول کرتا ہے - اتھارٹی کوڈ، پھر اس ٹوکن کے ساتھ، گویا سفر کے لیے ٹکٹ کے ساتھ، رسائی ٹوکن کی درخواست کرتا ہے۔ اس اجازت کے اسکرپٹ کا تمام اہم تعامل درخواست اور اجازت دینے والے سرور کے درمیان ری ڈائریکٹ پر مبنی ہے۔ آپ اس گرانٹ کے بارے میں مزید پڑھ سکتے ہیں۔ .
OAuth اس تصور کی پاسداری کرتا ہے کہ اجازت کے بعد حاصل کردہ رسائی ٹوکن عارضی ہونے چاہئیں اور اوسطاً ہر 10 منٹ بعد تبدیل ہونا چاہیے۔ آتھرائزیشن کوڈ گرانٹ ری ڈائریکٹس کے ذریعے ایک تین قدمی تصدیق ہے، ہر 10 منٹ میں اس طرح کے ایک قدم کو موڑنا، واضح طور پر، آنکھوں کے لیے سب سے زیادہ خوشگوار کام نہیں ہے۔ اس مسئلے کو حل کرنے کے لیے، ایک اور گرانٹ ہے - ریفریش ٹوکن، جسے ہم اپنے ملک میں بھی استعمال کرتے ہیں۔ یہاں سب کچھ آسان ہے۔ ایک اور گرانٹ سے تصدیق کے دوران، اہم رسائی ٹوکن کے علاوہ، ایک اور جاری کیا جاتا ہے - ریفریش ٹوکن، جسے صرف ایک بار استعمال کیا جا سکتا ہے اور اس کی زندگی عام طور پر بہت لمبی ہوتی ہے۔ اس ریفریش ٹوکن کے ساتھ، جب مین ایکسیس ٹوکن کا TTL (ٹائم ٹو لائیو) ختم ہو جائے گا، نئے ایکسیس ٹوکن کی درخواست کسی اور گرانٹ کے اینڈ پوائنٹ پر آئے گی۔ استعمال شدہ ریفریش ٹوکن فوری طور پر صفر پر ری سیٹ ہو جاتا ہے۔ یہ چیک دو قدمی ہے اور اسے پس منظر میں کیا جا سکتا ہے، صارف کو غیر محسوس طور پر۔
3) حسب ضرورت ڈیٹا آؤٹ پٹ فارمیٹس ترتیب دیں۔
منتخب گرانٹس کے لاگو ہونے کے بعد، اجازت کام کرتی ہے، آخر صارف کے بارے میں ڈیٹا حاصل کرنا قابل ذکر ہے۔ اس کے لیے OIDC کا ایک الگ اینڈ پوائنٹ ہے، جہاں آپ اپنے موجودہ رسائی ٹوکن کے ساتھ صارف کے ڈیٹا کی درخواست کر سکتے ہیں اور اگر یہ اپ ٹو ڈیٹ ہے۔ اور اگر صارف کا ڈیٹا اتنی کثرت سے تبدیل نہیں ہوتا ہے، اور آپ کو موجودہ ڈیٹا کو کئی بار فالو کرنے کی ضرورت ہے، تو آپ JWT ٹوکنز جیسے حل پر آ سکتے ہیں۔ یہ ٹوکن بھی معیار کی طرف سے حمایت کر رہے ہیں. JWT ٹوکن خود تین حصوں پر مشتمل ہے: ہیڈر (ٹوکن کے بارے میں معلومات)، پے لوڈ (کوئی ضروری ڈیٹا) اور دستخط (دستخط، ٹوکن پر سرور کے ذریعے دستخط کیے جاتے ہیں اور آپ بعد میں اس کے دستخط کا ماخذ چیک کر سکتے ہیں)۔
OIDC کے نفاذ میں، JWT ٹوکن کو id_token کہا جاتا ہے۔ باقاعدہ رسائی ٹوکن کے ساتھ اس کی درخواست کی جا سکتی ہے اور بس دستخط کی تصدیق کرنا باقی ہے۔ اجازت دینے والے سرور کے پاس اس کے لیے فارمیٹ میں عوامی کلیدوں کے ایک گروپ کے ساتھ ایک علیحدہ اختتامی نقطہ ہے۔ . اور اس کے بارے میں بات کرتے ہوئے، یہ قابل ذکر ہے کہ ایک اور اختتامی نقطہ ہے، جو معیار پر مبنی ہے OIDC سرور کی موجودہ ترتیب کو ظاہر کرتا ہے۔ اس میں تمام اختتامی پتے (بشمول دستخط کرنے کے لیے استعمال ہونے والی عوامی کلید کی انگوٹی کا پتہ)، معاون برانڈز اور اسکوپس، استعمال شدہ انکرپشن الگورتھم، معاون گرانٹس وغیرہ شامل ہیں۔
مثال کے طور پر گوگل پر:
{
"issuer": "https://accounts.google.com",
"authorization_endpoint": "https://accounts.google.com/o/oauth2/v2/auth",
"device_authorization_endpoint": "https://oauth2.googleapis.com/device/code",
"token_endpoint": "https://oauth2.googleapis.com/token",
"userinfo_endpoint": "https://openidconnect.googleapis.com/v1/userinfo",
"revocation_endpoint": "https://oauth2.googleapis.com/revoke",
"jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
"response_types_supported": [
"code",
"token",
"id_token",
"code token",
"code id_token",
"token id_token",
"code token id_token",
"none"
],
"subject_types_supported": [
"public"
],
"id_token_signing_alg_values_supported": [
"RS256"
],
"scopes_supported": [
"openid",
"email",
"profile"
],
"token_endpoint_auth_methods_supported": [
"client_secret_post",
"client_secret_basic"
],
"claims_supported": [
"aud",
"email",
"email_verified",
"exp",
"family_name",
"given_name",
"iat",
"iss",
"locale",
"name",
"picture",
"sub"
],
"code_challenge_methods_supported": [
"plain",
"S256"
],
"grant_types_supported": [
"authorization_code",
"refresh_token",
"urn:ietf:params:oauth:grant-type:device_code",
"urn:ietf:params:oauth:grant-type:jwt-bearer"
]
}اس طرح، id_token کا استعمال کرتے ہوئے، آپ تمام ضروری ہال مارکس کو ٹوکن کے پے لوڈ پر منتقل کر سکتے ہیں اور صارف کے ڈیٹا کی درخواست کرنے کے لیے ہر بار اجازت دینے والے سرور سے رابطہ نہیں کر سکتے۔ اس نقطہ نظر کا نقصان یہ ہے کہ سرور سے صارف کے ڈیٹا میں تبدیلی فوری طور پر نہیں آتی بلکہ اس کے ساتھ ایک نیا رسائی ٹوکن بھی آتا ہے۔
نفاذ کے نتائج
لہذا، ہمارے اپنے OIDC سرور کو لاگو کرنے اور ایپلی کیشن سائیڈ پر اس سے کنکشن کنفیگر کرنے کے بعد، ہم نے صارفین کے بارے میں معلومات کی منتقلی کا مسئلہ حل کیا۔
چونکہ OIDC ایک کھلا معیار ہے، اس لیے ہمارے پاس موجودہ فراہم کنندہ یا سرور کے نفاذ کو منتخب کرنے کا اختیار ہے۔ ہم نے Keycloak کو آزمایا، جو کنفیگر کرنے کے لیے بہت آسان نکلا، ایپلیکیشن سائیڈ پر کنکشن کنفیگریشن کو ترتیب دینے اور تبدیل کرنے کے بعد، یہ جانے کے لیے تیار ہے۔ درخواست کی طرف، جو کچھ باقی ہے وہ کنکشن کنفیگریشنز کو تبدیل کرنا ہے۔
موجودہ حل کے بارے میں بات کرنا
ہماری تنظیم کے اندر، پہلے OIDC سرور کے طور پر، ہم نے خود اپنے نفاذ کو جمع کیا، جسے ضرورت کے مطابق پورا کیا گیا۔ دیگر ریڈی میڈ حلوں کا تفصیلی جائزہ لینے کے بعد، ہم کہہ سکتے ہیں کہ یہ ایک موٹ پوائنٹ ہے۔ ان کے اپنے سرور کو لاگو کرنے کے فیصلے کے حق میں، فراہم کنندگان کی جانب سے ضروری فعالیت کی عدم موجودگی کے ساتھ ساتھ ایک پرانے نظام کی موجودگی کے خدشات تھے جس میں کچھ خدمات کے لیے مختلف حسب ضرورت اجازتیں تھیں اور کافی زیادہ ملازمین کا ڈیٹا پہلے ہی محفوظ تھا۔ تاہم، تیار شدہ نفاذ میں، انضمام کے لیے سہولتیں موجود ہیں۔ مثال کے طور پر، Keycloak کا اپنا یوزر مینجمنٹ سسٹم ہے اور ڈیٹا اس میں براہ راست محفوظ ہوتا ہے، اور وہاں اپنے صارفین کو پیچھے چھوڑنا مشکل نہیں ہوگا۔ ایسا کرنے کے لیے، Keycloak کے پاس ایک API ہے جو آپ کو منتقلی کی تمام ضروری کارروائیوں کو مکمل طور پر انجام دینے کی اجازت دے گا۔
تصدیق شدہ، دلچسپ، میری رائے میں، نفاذ کی ایک اور مثال اوری ہائیڈرا ہے۔ یہ دلچسپ ہے کیونکہ یہ مختلف اجزاء پر مشتمل ہے۔ انٹیگریٹ کرنے کے لیے، آپ کو اپنی صارف کے نظم و نسق کی خدمت کو ان کی اجازت کی خدمت سے جوڑنے اور ضرورت کے مطابق توسیع کرنے کی ضرورت ہوگی۔
Keycloak اور Ory Hydra صرف آف دی شیلف حل نہیں ہیں۔ OpenID فاؤنڈیشن سے تصدیق شدہ نفاذ کا انتخاب کرنا بہتر ہے۔ ان حلوں میں عام طور پر ایک OpenID سرٹیفیکیشن بیج ہوتا ہے۔
اگر آپ اپنا OIDC سرور نہیں رکھنا چاہتے ہیں تو موجودہ ادا شدہ فراہم کنندگان کے بارے میں بھی نہ بھولیں۔ آج بہت سے اچھے اختیارات ہیں۔
آگے کیا ہے
مستقبل قریب میں، ہم داخلی خدمات کے لیے ٹریفک کو مختلف طریقے سے بند کرنے جا رہے ہیں۔ ہم اوپن ریسٹی کا استعمال کرتے ہوئے اپنے موجودہ SSO کو OAuth پر مبنی پراکسی میں منتقل کرنے کا ارادہ رکھتے ہیں۔ یہاں پہلے سے ہی بہت سے تیار حل موجود ہیں، مثال کے طور پر:
اضافی مواد
- JWT ٹوکن کی توثیق کے لیے اچھی سروس
- تصدیق شدہ OIDC کے نفاذ کی فہرست
ماخذ: www.habr.com