Bir necha oy oldin men yuzlab ichki ilovalarimizga kirishni boshqarish uchun OpenID Connect serverini joriy qildim. Kichikroq miqyosda qulay bo'lgan o'z ishlanmalarimizdan biz umumiy qabul qilingan standartga o'tdik. Markaziy xizmat orqali kirish monoton operatsiyalarni sezilarli darajada soddalashtiradi, avtorizatsiyani amalga oshirish xarajatlarini kamaytiradi, ko'plab tayyor echimlarni topishga imkon beradi va yangilarini ishlab chiqishda miyangizni bezovta qilmaslikka imkon beradi. Ushbu maqolada men ushbu o'tish va biz urishga muvaffaq bo'lgan zarbalar haqida gapiraman.
Ancha vaqt oldin... Hammasi qaerdan boshlangan
Bir necha yil oldin, ichki ilovalar qo'lda boshqarish uchun haddan tashqari ko'payib ketganda, biz kompaniya ichida kirishni boshqarish uchun dastur yozdik. Bu oddiy Rails ilovasi bo'lib, u turli xil funksiyalarga kirish sozlangan xodimlar haqidagi ma'lumotlarga ega ma'lumotlar bazasiga ulangan. Shu bilan birga, biz mijoz va avtorizatsiya serveri tomonidan tokenlarni tekshirishga asoslangan birinchi SSO ni ishga tushirdik; token bir nechta parametrlar bilan shifrlangan shaklda uzatildi va avtorizatsiya serverida tekshirildi. Bu eng qulay variant emas edi, chunki har bir ichki dastur katta mantiqiy qatlamni tavsiflashi kerak edi va xodimlarning ma'lumotlar bazalari avtorizatsiya serveri bilan to'liq sinxronlashtirildi.
Biroz vaqt o'tgach, biz markazlashtirilgan avtorizatsiya vazifasini soddalashtirishga qaror qildik. SSO balansga o'tkazildi. OpenResty yordami bilan Lua-ga shablon qo'shildi, u tokenlarni tekshiradi, so'rov qaysi dasturga ketayotganini bilardi va u erda kirish mavjudligini tekshira oladi. Ushbu yondashuv ichki ilovalarga kirishni nazorat qilish vazifasini ancha soddalashtirdi - endi har bir ilova kodida qo'shimcha mantiqni tasvirlashga ehtiyoj qolmadi. Natijada, biz trafikni tashqi tomondan yopdik, lekin dasturning o'zi avtorizatsiya haqida hech narsa bilmas edi.
Biroq, bitta muammo hal etilmagan. Xodimlar haqida ma'lumot talab qiladigan ilovalar haqida nima deyish mumkin? Avtorizatsiya xizmati uchun API yozish mumkin edi, lekin keyin har bir bunday dastur uchun qo'shimcha mantiq qo'shishingiz kerak bo'ladi. Bundan tashqari, biz ichki avtorizatsiya serverimizdagi OpenSource-ga tarjima qilishga qaratilgan o'zimiz yozgan ilovalarimizdan biriga qaramlikdan xalos bo'lishni xohladik. Bu haqda boshqa vaqt aytib beramiz. Ikkala muammoning echimi OAuth edi.
Umumiy qabul qilingan standartlarga
OAuth aniq, umumeʼtirof etilgan avtorizatsiya standartidir, lekin uning funksionalligining oʻzi yetarli emasligi sababli, OpenID Connect (OIDC) darhol koʻrib chiqildi. OIDC o'zi OAuth 2.0 protokolining (Open Authorization Protocol) yuqori to'plamiga aylangan ochiq autentifikatsiya standartining uchinchi dasturidir. Ushbu yechim oxirgi foydalanuvchi haqida ma'lumotlar etishmasligi muammosini hal qiladi, shuningdek, avtorizatsiya provayderini o'zgartirishga imkon beradi.
Biroq, biz aniq provayderni tanlamadik va mavjud avtorizatsiya serverimiz uchun OIDC bilan integratsiyani qo'shishga qaror qildik. Ushbu qaror OIDC oxirgi foydalanuvchini avtorizatsiya qilish nuqtai nazaridan juda moslashuvchan ekanligi bilan tasdiqlandi. Shunday qilib, joriy avtorizatsiya serveringizda OIDC qo'llab-quvvatlashini amalga oshirish mumkin bo'ldi.
Bizning OIDC serverimizni amalga oshirish yo'li
1) Ma'lumotlarni kerakli shaklga keltiring
OIDC ni integratsiya qilish uchun joriy foydalanuvchi ma'lumotlarini standart uchun tushunarli shaklga keltirish kerak. OIDCda bu da'volar deb ataladi. Brendlar asosan foydalanuvchi ma'lumotlar bazasidagi yakuniy maydonlardir (ism, elektron pochta, telefon va boshqalar). Mavjud , va bu ro'yxatga kiritilmagan hamma narsa odatiy hisoblanadi. Shuning uchun, agar siz mavjud OIDC provayderini tanlamoqchi bo'lsangiz, e'tibor berishingiz kerak bo'lgan birinchi nuqta - bu yangi shtamplarni qulay tarzda sozlash qobiliyati.
Belgilar guruhi quyidagi kichik to'plamga birlashtirilgan - Qo'llash doirasi. Avtorizatsiya vaqtida kirish ma'lum belgilarga emas, balki ko'lamdagi belgilarning ba'zilari kerak bo'lmasa ham, foydalanish sohalariga so'raladi.
2) Kerakli grantlarni amalga oshirdi
OIDC integratsiyasining keyingi qismi grantlar deb ataladigan avtorizatsiya turlarini tanlash va amalga oshirishdir. Tanlangan dastur va avtorizatsiya serveri o'rtasidagi o'zaro ta'sirning keyingi stsenariysi tanlangan grantga bog'liq bo'ladi. To'g'ri grantni tanlashning taxminiy sxemasi quyidagi rasmda keltirilgan.
Birinchi arizamiz uchun biz eng keng tarqalgan grant - Avtorizatsiya kodidan foydalandik. Uning boshqalardan farqi shundaki, u uch bosqichli, ya'ni. qo'shimcha sinovdan o'tadi. Birinchidan, foydalanuvchi avtorizatsiya ruxsati uchun so'rov yuboradi, Avtorizatsiya kodi tokenini oladi, so'ngra ushbu token yordamida xuddi sayohat chiptasi bilan kirish tokenini so'raydi. Ushbu avtorizatsiya stsenariysining barcha asosiy o'zaro ta'siri dastur va avtorizatsiya serveri o'rtasidagi qayta yo'naltirishga asoslangan. Ushbu grant haqida ko'proq o'qishingiz mumkin .
OAuth avtorizatsiyadan so'ng olingan kirish tokenlari vaqtinchalik bo'lishi va o'rtacha har 10 daqiqada o'zgarishi kerak degan kontseptsiyaga amal qiladi. Avtorizatsiya kodi granti - bu qayta yo'naltirish orqali uch bosqichli tekshirish; bunday qadamni har 10 daqiqada bajarish, ochig'ini aytganda, ko'z uchun eng yoqimli vazifa emas. Bu muammoni hal qilish uchun yana bir grant bor - Refresh Token, biz ham undan foydalandik. Bu erda hamma narsa oddiyroq. Boshqa grantdan tekshirish paytida, asosiy kirish tokeniga qo'shimcha ravishda yana biri chiqariladi - yangilash tokeni, uni faqat bir marta ishlatish mumkin va uning ishlash muddati, qoida tariqasida, sezilarli darajada uzoqroq. Ushbu yangilash tokeni bilan, asosiy kirish tokenining TTL (Yashash vaqti) tugagach, yangi kirish tokeniga soʻrov boshqa grantning soʻnggi nuqtasiga keladi. Ishlatilgan yangilash tokeni darhol nolga qaytariladi. Ushbu tekshirish ikki bosqichli bo'lib, foydalanuvchi tomonidan sezilmaydigan fonda amalga oshirilishi mumkin.
3) Konfiguratsiya qilingan foydalanuvchi ma'lumotlarini chiqarish formatlari
Tanlangan grantlar amalga oshirilgandan so'ng, avtorizatsiya ishlaydi, oxirgi foydalanuvchi ma'lumotlarini olishni eslatib o'tish kerak. OIDC buning uchun alohida so'nggi nuqtaga ega, u erda siz joriy kirish tokeningiz va agar u yangilangan bo'lsa, foydalanuvchi ma'lumotlarini so'rashingiz mumkin. Agar foydalanuvchi ma'lumotlari tez-tez o'zgarmasa-da, lekin siz hozirgilariga ko'p marta borishingiz kerak bo'lsa, siz JWT tokenlari kabi yechimga kelishingiz mumkin. Ushbu tokenlar standart tomonidan ham qo'llab-quvvatlanadi. JWT tokenining o'zi uch qismdan iborat: sarlavha (token haqida ma'lumot), foydali yuk (har qanday kerakli ma'lumotlar) va imzo (imzo, token server tomonidan imzolanadi va kelajakda siz uning imzo manbasini tekshirishingiz mumkin).
OIDC amalga oshirishda JWT tokeni id_token deb ataladi. Uni muntazam kirish tokeni bilan birga so'rash mumkin va faqat imzoni tekshirish qoladi. Shu maqsadda avtorizatsiya serverida formatdagi ochiq kalitlar to'plamiga ega alohida so'nggi nuqta mavjud . Va bu haqda gapirganda, standartga asoslangan yana bir yakuniy nuqta borligini ta'kidlash kerak OIDC serverining joriy konfiguratsiyasini aks ettiradi. Unda barcha so'nggi nuqta manzillari (jumladan, imzolash uchun ishlatiladigan ochiq kalit halqasining manzili), qo'llab-quvvatlanadigan shtamplar va doiralar, ishlatilgan shifrlash algoritmlari, qo'llab-quvvatlanadigan grantlar va boshqalar mavjud.
Masalan, Googleda:
{
"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"
]
}Shunday qilib, id_token-dan foydalanib, siz barcha kerakli belgilarni token yukiga o'tkazishingiz mumkin va foydalanuvchi ma'lumotlarini so'rash uchun har safar avtorizatsiya serveriga murojaat qilishingiz shart emas. Ushbu yondashuvning kamchiligi shundaki, serverdan foydalanuvchi ma'lumotlaridagi o'zgarishlar darhol emas, balki yangi kirish tokeni bilan birga keladi.
Amalga oshirish natijalari
Shunday qilib, o'z OIDC serverimizni amalga oshirganimizdan va unga ilova tomonida ulanishlarni o'rnatganimizdan so'ng, biz foydalanuvchi ma'lumotlarini uzatish muammosini hal qildik.
OIDC ochiq standart bo'lgani uchun bizda hozirda mavjud provayder yoki server ilovasini tanlash imkoniyati mavjud. Biz Keycloak-ni sinab ko'rdik, uni sozlash juda oson; ilova tomonida ulanish konfiguratsiyasini o'rnatgandan va o'zgartirgandan so'ng, u ishlashga tayyor. Ilova tomonida faqat ulanish konfiguratsiyasini o'zgartirish qoladi.
Mavjud echimlar haqida gapirish
Tashkilotimiz doirasida, birinchi OIDC serveri sifatida biz o'z dasturimizni yig'dik, kerak bo'lganda to'ldirildi. Boshqa tayyor echimlarni batafsil o'rganib chiqqandan so'ng, bu bahsli nuqta deb aytishimiz mumkin. O'z serverimizni joriy qilish qaroriga provayderlar tomonidan zarur funksiyalarning yo'qligi, shuningdek, ba'zi xizmatlar uchun turli xil ruxsatnomalarni o'z ichiga olgan va xodimlar haqida juda ko'p ma'lumotlarni saqlagan eski tizim mavjudligi bilan bog'liq xavotirlar sabab bo'ldi. . Biroq, tayyor amalga oshirishda integratsiya uchun qulayliklar mavjud. Masalan, Keycloak o'zining foydalanuvchilarni boshqarish tizimiga ega va ma'lumotlar to'g'ridan-to'g'ri unda saqlanadi va foydalanuvchilaringizni u erga ko'chirish qiyin bo'lmaydi. Shu maqsadda Keycloak-da barcha kerakli uzatish amallarini to'liq bajarishga imkon beruvchi API mavjud.
Tasdiqlangan, qiziqarli, mening fikrimcha, amalga oshirishning yana bir misoli Ory Hydra. Bu qiziqarli, chunki u turli xil tarkibiy qismlardan iborat. Integratsiyalash uchun siz foydalanuvchilarni boshqarish xizmatini ularning avtorizatsiya xizmatiga ulashingiz va kerak bo'lganda kengaytirishingiz kerak bo'ladi.
Keycloak va Ory Hydra - bu yagona tayyor echimlar emas. OpenID Foundation tomonidan tasdiqlangan dasturni tanlash yaxshidir. Ushbu echimlar odatda OpenID sertifikatiga ega.
OIDC serveringizni saqlashni xohlamasangiz, mavjud pullik provayderlar haqida ham unutmang. Bugungi kunda juda ko'p yaxshi variantlar mavjud.
Keyin nima
Yaqin kelajakda biz ichki xizmatlarga trafikni boshqacha tarzda yopmoqchimiz. Biz joriy SSO-ni OpenResty-dan foydalangan holda balanslovchida OAuth-ga asoslangan proksi-serverga o'tkazishni rejalashtirmoqdamiz. Bu erda ham ko'plab tayyor echimlar mavjud, masalan:
Qo'shimcha materiallar
– JWT tokenlarini tekshirish uchun yaxshi xizmat
— sertifikatlangan OIDC ilovalari roʻyxati
Manba: www.habr.com