ڪجھ مهينا اڳ آئون هڪ OpenID ڪنيڪٽ سرور لاڳو ڪري رهيو آهيان اسان جي سوين اندروني ايپليڪيشنن تائين رسائي کي منظم ڪرڻ لاءِ. اسان جي پنهنجي ترقيات کان، ننڍڙي پيماني تي آسان، اسان عام طور تي قبول ٿيل معيار ڏانهن منتقل ڪيو. مرڪزي خدمت ذريعي رسائي خاص طور تي هڪجهڙائي واري عمل کي آسان بڻائي ٿي، اختيارين تي عمل درآمد جي قيمت گھٽائي ٿي، توهان کي اجازت ڏئي ٿي ته ڪيترائي تيار ڪيل حل ڳولڻ ۽ توهان جي دماغ کي ريڪ نه ڪريو جڏهن نوان ٺاهي رهيا آهن. هن آرٽيڪل ۾ آئون هن منتقلي بابت ڳالهائيندس ۽ انهن bumps جنهن کي اسان مارڻ ۾ منظم ڪيو.
گهڻو وقت اڳ ... جتي اهو سڀ شروع ٿيو
ڪيترائي سال اڳ، جڏهن اندروني ايپليڪيشنون هٿرادو انتظام ڪرڻ لاءِ تمام گهڻيون ٿي ويون، اسان ڪمپني جي اندر رسائي کي ڪنٽرول ڪرڻ لاءِ هڪ درخواست لکي. اها هڪ سادي ريل ايپليڪيشن هئي جيڪا ملازمن جي معلومات سان گڏ ڊيٽابيس سان ڳنڍيل هئي، جتي مختلف ڪارڪردگي تائين رسائي ترتيب ڏني وئي هئي. ساڳئي وقت، اسان پهريون SSO شروع ڪيو، جيڪو ڪلائنٽ جي حصي تي ٽوڪن جي تصديق ۽ اختيار ڪرڻ واري سرور تي ٻڌل هو؛ ٽوڪن ڪيترن ئي پيرا ميٽرز سان گڏ انڪرپٽ ٿيل فارم ۾ منتقل ڪيو ويو ۽ اجازت ڏيڻ واري سرور تي تصديق ڪئي وئي. اهو سڀ کان وڌيڪ آسان اختيار نه هو، ڇاڪاڻ ته هر اندروني ايپليڪيشن کي منطق جي هڪ وڏي پرت کي بيان ڪرڻو پوندو هو، ۽ ملازم ڊيٽابيس کي مڪمل طور تي اجازت ڏيڻ واري سرور سان هم وقت سازي ڪئي وئي هئي.
ڪجهه وقت کان پوء، اسان مرڪزي اختيار جي ڪم کي آسان ڪرڻ جو فيصلو ڪيو. ايس ايس او کي بيلنس ۾ منتقل ڪيو ويو. OpenResty جي مدد سان، Lua ۾ هڪ ٽيمپليٽ شامل ڪيو ويو جيڪو ٽوڪن کي چيڪ ڪري ٿو، ڄاڻي ٿو ته درخواست ڪهڙي درخواست ڏانهن وڃي رهي آهي، ۽ چيڪ ڪري سگهي ٿو ته اتي رسائي آهي يا نه. هن طريقي سان اندروني ايپليڪيشنن تائين رسائي کي ڪنٽرول ڪرڻ جي ڪم کي تمام آسان بڻائي ڇڏيو آهي - هر ايپليڪيشن جي ڪوڊ ۾ اضافي منطق بيان ڪرڻ جي ضرورت ناهي. نتيجي طور، اسان ٽريفڪ کي خارجي طور تي بند ڪيو، پر ايپليڪيشن پاڻ کي اجازت ڏيڻ بابت ڪجھ به نه ڄاڻيو.
بهرحال، هڪ مسئلو حل نه ڪيو ويو. ڇا ايپليڪيشنن بابت جيڪي ملازم جي معلومات جي ضرورت آهي؟ اختيار ڪرڻ جي خدمت لاءِ API لکڻ ممڪن هو، پر پوءِ توهان کي هر اهڙي ايپليڪيشن لاءِ اضافي منطق شامل ڪرڻي پوندي. ان کان علاوه، اسان چاهيون ٿا ته اسان جي خود لکيل ايپليڪيشنن مان هڪ تي انحصار کان نجات حاصل ڪرڻ لاء، جيڪو وڌيڪ ڌيان ڏنو ويو آهي OpenSource ۾ ترجمو ڪرڻ تي، اسان جي اندروني اجازت ڏيڻ واري سرور تي. ان بابت ڪنهن ٻئي وقت ٻڌائينداسين. ٻنهي مسئلن جو حل OAuth هو.
عام طور تي قبول ٿيل معيار جي طرف
OAuth هڪ واضح، عام طور تي قبول ٿيل اختياري معيار آهي، پر جيئن ته ان جي ڪارڪردگي اڪيلو ڪافي ناهي، OpenID Connect (OIDC) کي فوري طور تي سمجهيو ويو. OIDC خود کليل تصديق واري معيار جو ٽيون عمل آهي، جيڪو OAuth 2.0 پروٽوڪول (اوپن اٿارائزيشن پروٽوڪول) جي سپر سيٽ ۾ تبديل ٿي چڪو آهي. اهو حل آخري صارف بابت ڊيٽا جي کوٽ جي مسئلي کي حل ڪري ٿو، ۽ اهو پڻ ممڪن بڻائي ٿو ته اختيار فراهم ڪندڙ کي تبديل ڪرڻ.
تنهن هوندي، اسان هڪ مخصوص فراهم ڪندڙ نه چونڊيو ۽ اسان جي موجوده اختيار جي سرور لاء OIDC سان انضمام شامل ڪرڻ جو فيصلو ڪيو. هن فيصلي جي حمايت ڪئي وئي ته 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 آهي جيڪو توهان کي مڪمل طور تي سڀني ضروري منتقلي عملن کي انجام ڏيڻ جي اجازت ڏيندو.
تصديق ٿيل، دلچسپ، منهنجي خيال ۾، عملدرآمد جو هڪ ٻيو مثال Ory Hydra آهي. اهو دلچسپ آهي ڇاڪاڻ ته اهو مختلف حصن تي مشتمل آهي. ضم ڪرڻ لاء، توهان کي پنهنجي صارف جي انتظام جي خدمت کي انهن جي اختيار جي خدمت سان ڳنڍڻ جي ضرورت پوندي ۽ ضرورت مطابق وڌايو.
Keycloak ۽ Ory Hydra صرف تيار ٿيل حل نه آهن. اھو بھترين آھي ھڪڙي عمل درآمد کي چونڊيو جيڪو OpenID فائونڊيشن پاران تصديق ٿيل آھي. انهن حلن ۾ عام طور تي هڪ OpenID سرٽيفڪيشن بيج هوندو آهي.
موجوده ادا ڪيل مهيا ڪندڙن جي باري ۾ پڻ نه وساريو جيڪڏهن توهان نٿا چاهيو ته توهان پنهنجو OIDC سرور رکو. اڄ اتي ڪيترائي سٺا اختيار آھن.
ايندڙ ڇا آهي
ويجهي مستقبل ۾، اسان هڪ مختلف طريقي سان اندروني خدمتن ڏانهن ٽرئفڪ کي بند ڪرڻ وارا آهيون. اسان منصوبا بندي ڪري رهيا آهيون اسان جي موجوده SSO کي بيلنسر تي OpenResty استعمال ڪندي هڪ پراکسي ڏانهن OAuth جي بنياد تي. هتي پڻ ڪيترائي تيار ڪيل حل آهن، مثال طور:
اضافي مواد
- JWT ٽوڪن جي چڪاس لاءِ سٺي خدمت
- تصديق ٿيل OIDC عملن جي فهرست
جو ذريعو: www.habr.com