Soʻnggi paytlarda Vizend uchinchi tomon kirish funksiyasini joriy etdi va qayta ishladi. Uchinchi tomon kirishi foydalanuvchini Google, Apple, Facebook va Keycloak kabi tashqi autentifikatsiya usullari orqali tekshirishga imkon beradi va natijani Vizendning ichki foydalanuvchi tizimiga ulaydi. Foydalanuvchi interfeysida bu umumiy ko‘rinadigan 'Tashqi hisob bilan kirish' tugmasi sifatida ko‘rinadi, ammo server nuqtai nazaridan asosiy jihat tashqi autentifikatsiya natijasini ichki hisoblar, obuna siyosatlari, hisob bog‘lash siyosatlari va sessiya siyosatlari bilan qanday bog‘lashdir.
Ushbu ishda muhim nuqtalar tashqi autentifikatsiyani ichki kirishdan ajratish edi. Tashqi provayderlar foydalanuvchining ma'lum bir hisobning egasi ekanligini tasdiqlay oladilar. Ammo, ular shu foydalanuvchining Vizendda faolmi, qaysi tashkilotga tegishli, qanday ruxsatlarga ega bo‘lishi kerak yoki xizmatga kirish shartlarini bajaradimi yoki yo‘qligini aniqlay olmaydilar. Ushbu hukm Vizendning foydalanuvchi modeli va autentifikatsiya siyosatlari doirasida qo‘yilishi kerak.
Shuning uchun, uchinchi tomon kiri tashqi autentifikatsiya muvaffaqiyatini ichki kirish muvaffaqiyati sifatida to‘g‘ridan-to‘g‘ri hisoblaydigan funksiya emas. Bu tashqi autentifikatsiya natijalarini standartlashtiradigan, ichki foydalanuvchilar bilan bog‘lanishni tasdiqlaydigan va zarur bo‘lganda yangi ro‘yxatdan o‘tishga yoki mavjud hisoblarni bog‘lashga olib keladigan autentifikatsiya yordamchi oqimiga yaqinroqdir. Ushbu maqolada men Vizendda uchinchi tomon kiritish va qayta ishlash jarayonida tashkil etilgan dizayn yo'nalishi, dasturlash jarayoni va asosiy masalalarni ulashaman.
Dasturiy asos
Vizendning Gate - bu bir nechta xizmatlar bo'yicha ishlatiladigan umumiy autentifikatsiya poydevori. Har bir xizmat Google kirishi, Apple kirishi va Keycloak kirishini to'g'ridan-to'g'ri amalga oshirishi mumkin bo'lsa-da, buni amalga oshirish autentifikatsiya siyosatlarini xizmatlar bo'yicha tarqatishga olib keladi. Dastlab, bu tezroq ko'rinishi mumkin, ammo ko'proq provayderlar va xizmatlar qo'shilganda, operatsion xarajatlar oshadi, siyosat o'zgarishlari sodir bo'lganda ta'sir doirasini tushunishni qiyinlashtiradi.
Masalan, ba'zi kompaniyalar Google loginni ruxsat berishi kerak, boshqalari esa faqat ichki Keycloakni ruxsat berishi mumkin. Ba'zi xizmatlar faqat elektron pochta manzillari tasdiqlangan foydalanuvchilar uchun avtomatik ro'yxatdan o'tishni ruxsat berishi mumkin, boshqa xizmatlar esa tashqi loginni ruxsat berishi mumkin, lekin avtomatik ro'yxatdan o'tishni oldini oladi. Ushbu siyosatlarni har bir xizmatning kodiga tarqatish xuddi shu mezonlarning takroriy amalga oshirilishiga olib keladi, muammolar yuzaga kelganda esa sabablar ham tarqatilgan bo'ladi.
Yana bir asosiy masala esa tashqi hisoblar va ichki hisoblar o'rtasidagi aloqadir. Foydalanuvchi Google bilan muvaffaqiyatli autentifikatsiya qilinganligi, ularni Vizendning ichki foydalanuvchisi sifatida darhol ko'rib chiqish mumkin emas. Ular allaqachon ichki hisobga ega bo'lishi mumkin yoki hali ro'yxatdan o'tmagan bo'lishi mumkin. Ular tashqi tarzda faollashtirilgan, ammo ichki jihatdan faol bo'lmagan foydalanuvchilar ham bo'lishi mumkin. Shuning uchun, tashqi autentifikatsiya natijasini ichki hisobga bog‘lash uchun alohida qadam zarur.
Uchinchi tomon kiritish va qayta ishlashning mezonlari quyidagicha yig'ilishi mumkin.
-
Provayderlar tomonidan autentifikatsiya usullaridagi farqlarni Gate ichidagi umumiy oqimga singdirish.
-
Tashkilot bo'yicha provayderlar va ro'yxatdan o'tish siyosatlari uchun turli sozlamalar ruxsat berish.
-
Tashqi hisob ma'lumotlarini ichki foydalanuvchilar bilan to'g'ridan-to'g'ri aralashtirmasdan bog'lanish ma'lumotlari sifatida boshqarish.
-
Yangi roʻyxatdan oʻtish va mavjud hisob bogʻlashlarni aniq farqlash.
-
Tashqi autentifikatsiyadan soʻng ichki foydalanuvchi holatini, ruxsatlarini va sessiya siyosatlarini saqlab qolish.
Dizayn yo'nalishi
Dizayn asosiy jihati - provayderlar tomonidan farqlarni ichki autentifikatsiya siyosatlaridan ajratishdir. OAuth nomi bir xil bo'lsa-da, haqiqiy harakat provayderga qarab farq qiladi. Ba'zi provayderlar foydalanuvchi ma'lumotlarini kirish tokeni yordamida olishadi, boshqalari esa token olish uchun autentifikatsiya kodini almashishlari kerak. Apple holatida, foydalanuvchi identifikatsiyalash ma'lumotlari id tokenidan to'g'ridan-to'g'ri tasdiqlanishi mumkin.
Agar farq ro'yxatga olish mantiqi yoki hisobni bog'lash mantiqi orqali to'g'ridan-to'g'ri tan olinadigan bo'lsa, har safar provayder qo'shilganda mavjud oqimda shoxlanishlar ko'payadi. Shuning uchun, har bir provayderga oid autentikatsiya natijalari Gate tushunishi mumkin bo'lgan umumiy foydalanuvchi ma'lumotlariga aylantiriladi va keyingi oqim bir xil mezon bo'yicha, provayderning turiga qaramay, boshqarish uchun konfiguratsiyalanadi.
Umumiy foydalanuvchi ma'lumotlari tashqi foydalanuvchi ID, elektron pochta, ism, elektron pochta tasdiqlash holati, provayder identifikatori va boshqalarni o'z ichiga oladi. Ichki foydalanuvchini moslashtirish, yangi ro'yxatdan o'tish imkoniyatlarini aniqlash va mavjud hisoblar bilan bog'lanish imkoniyatlarini baholash ushbu umumiy ma'lumotlar va Vizend siyosatlari asosida amalga oshiriladi. Shu tarzda, har bir provayder uchun amalga oshirish old qismda ajratiladi va domen siyosatlari barqaror holda saqlanadi.
Biz siyosatlarni qattiq kodlash o'rniga, kompaniya maxsus sozlamalari sifatida boshqarishni tanladik. Tashqi kirish sozlamalari hatto ish paytida ham o'zgarishi mumkin. Yo'naltirish URI o'zgarishi mumkin, Keycloak sohalari ajratilishi mumkin, va ba'zi provayderlar vaqtincha o'chirib qo'yilishi kerak bo'lishi mumkin. Agar bu qiymatlar kod ichiga kiritilsa, hatto kichik operatsion o'zgarishlar ham joylashishni talab qiladi. Ularni siyosatlar sifatida ajratish orqali, biz korporativ darajada yanada moslashuvchan tarzda javob bera olishimiz mumkin.
Tashqi hisob ulanish ma'lumotlari ham alohida boshqariladi. Ichki foydalanuvchi ma'lumotlari ichiga provayder ID'larini to'g'ridan-to'g'ri joylashtirish oson, ammo kengaytirilishi yo'q. Bitta foydalanuvchi bir nechta tashqi hisoblarni bog'lashi mumkin va faqat ba'zi tashqi hisob ulanishlarini vaqtincha o'chirish zarur bo'lishi mumkin. Shuning uchun, tashqi provayderning foydalanuvchi ID'si va ichki foydalanuvchi ID'si o'rtasidagi bog'lanishni alohida ma'lumot sifatida saqlovchi struktura yanada mos keladi.
Umumiy oqim
Uchinchi tomonli kirishning umumiy oqimini tashqi autentifikatsiya, Gate tekshiruvi, ichki foydalanuvchini moslashtirish va ro'yxatdan o'tish yoki bog'lash tartibida tashkil etish mumkin. Avval foydalanuvchi Google, Apple, va Keycloak kabi provayderlar bilan klientdan autentifikatsiya o'tkazadi. Provayder autentifikatsiyasi tugagach, klient olingan ma'lumotlarni Gate'ga o'tkazadi.
Gate avval o'sha provayderni tegishli kompaniyada ishlatish mumkinligini tekshiradi. Agar provayder o'chirilgan bo'lsa yoki siyosat mavjud bo'lmasa, Gate muvaffaqiyatli bo'lsa ham tashqi autentifikatsiyani ruxsat bermaydi. Bu qadam operatsion siyosatlarni saqlab turish uchun birinchi mudofaa chizig'idir.
Agar provayderni ishlatish ruxsat etilsa, Gate ma'lumotnomalarni tasdiqlaydi va tashqi foydalanuvchi ma'lumotlarini oladi. Bu nuqtada har bir provayder bo'yicha farqlar kelib chiqadi. Google, Facebook, Apple, va Keycloak foydalanuvchi ma'lumotlarini tasdiqlash va javob formatlari bo'yicha turli yondashuvlarga ega. Biroq Gate ichida bu umumiy foydalanuvchi ma'lumotlariga aylantiriladi va keyingi bosqichga o'tkaziladi.
Keyin Gate tashqi hisob ichki foydalanuvchi bilan allaqachon bog'langanligini tekshiradi. Agar ulanishgan foydalanuvchi mavjud bo'lsa, u ichki foydalanuvchi ma'lumotlarini qaytaradi va keyingi xizmatlarga kirish Gate'ning standart kirish va token siyosatlari asosida amalga oshiriladi. Agar ulanishgan foydalanuvchi mavjud bo'lmasa, darhol ro'yxatdan o'tmaydi, balki keyingi bosqichga o'tish uchun qisqa muddatli ro'yxatdan o'tish tokenini beradi.
Ro'yxatdan o'tish tokeni tashqi autentifikatsiya natijalarini xavfsiz uzatish mexanizmdir. Tashqi autentifikatsiyadan so'ng, foydalanuvchi darhol ro'yxatdan o'tishni to'ldirmasligi mumkin. U foydalanuvchi nomini sozlashi, qo'shimcha ma'lumot kiritishi yoki mavjud hisobga bog'lanishni hal qilishi kerak. Agar klient ushbu davrda provayder foydalanuvchi ID yoki elektron pochta kabi muhim qiymatlarni to'g'ridan-to'g'ri olib o'tsa, manipulyatsiya xavfi bor. Server vaqtincha tashqi autentifikatsiya natijalarini saqlab turishi va faqat qisqa muddatli tokenni klientga uzatishi orqali ushbu xavfni kamaytirish mumkin.
Agar foydalanuvchi ro'yxatdan o'tishni tanlasa, Gate ro'yxatdan o'tish tokenini tekshiradi va ro'yxatdan o'tish siyosatlarini qo'llaydi. U o'sha kompaniyada ro'yxatdan o'tish ruxsat berilganligini, provayderga asoslangan ro'yxatdan o'tish faol ekanligini, elektron pochta talab qilinganligini va tasdiqlangan elektron pochta zarurati bor-yo'qligini tekshiradi. Agar shartlar bajarilsa, ichki foydalanuvchi yaratiladi va tashqi hisob ulanish ma'lumotlari ham saqlanadi.
Agar foydalanuvchi mavjud hisobni bog'lashni tanlasa, ulardan ichki hisobning foydalanuvchi nomi va parolini qayta kiritish so'raladi. Tashqi autentifikatsiya muvaffaqiyati asosida mavjud ichki hisobga bog'lanish xavflidir. Umumiy qurilmalar yoki hisoblarni almashtirish vaziyatlarida, noto'g'ri tashqi hisob ichki hisobga bog'lanishi mumkin. Ichki hisob parolini qayta tasdiqlash, foydalanuvchining o'sha ichki hisobning egasi ekanligini yana bir bor tasdiqlash imkonini beradi.
Provayderga oid farqlarni boshqarish
Uchinchi tomonli kirishda tashkil etilishi kerak bo'lgan birinchi soha provayder javoblaridagi farqlardir. Umumiy standartlar, masalan, OAuth yoki OIDC bo'lsa ham, haqiqiy integratsiya har bir provayder tomonidan taqdim etiladigan ma'lumotlar va tasdiqlash usullari bo'yicha farq qiladi.
Google elektron pochta va elektron pochta tasdiqlash holatini nisbatan aniq taqqoslashni taqdim etadi. Ushbu qiymat avtomatik ro'yxatdan o'tish yoki avtomatik bog'lash siyosatlari uchun muhim asos bo'lishi mumkin. Biroq, Facebook elektron pochta qiymatini qabul qilsa ham, tasdiqlash holatiga ishonch bildirishi qiyin. Bunday hollarda, ularni konservativ tarzda boshqarish xavfsizroqdir.
Apple id tokenlar atrofida markazlashtirilgan oqimga ega. Foydalanuvchi identifikatori tokenning subyektiviga qarab ko'rinishi mumkin, shuningdek, elektron pochta xabarlari ham token da'volari sifatida uzatilishi mumkin. Biroq, nom ma'lumotlari har doim ishonchli ravishda taqdim etilmaydi va shaxsiy relay elektron pochta kabi xususiyatlar ham hisobga olinishi kerak. Shuning uchun, Apple integratsiyasi to'liq foydalanuvchi profil ma'lumotlari har doim olingan deb hisoblangan qayta tuzilmasligi kerak.
Keycloak standart OIDC oqimiga yaqin, lekin u konfiguratsiyaga juda bog'liq. Token almashinuvi va foydalanuvchi ma'lumotlarini olish usuli realm, mijoz, qayta yo'naltirish URI va mijozni autentifikatsiyalash usuliga qarab farq qilishi mumkin. Ayniqsa, mijoz kompaniyalari yoki ichki IdPlar bilan integratsiyalashganda, endpoint va mijozni autentifikatsiyalash usuli muhitga qarab farq qilishi mumkin, bu esa siyosatga asoslangan konfiguratsiyani muhim qiladi.
Ta'minotchi tomonidan farqlar bo'lsa ham, Gate ichki oqimida ma'lumotlar umumiy foydalanuvchi ma'lumotlariga aylantirilgandan so'ng qayta ishlanadi. Bu tuzilma ta'minotchilarni qo'shish yoki o'zgartirishda ta'sir doirasini kamaytiradi. Agar yangi ta'minotchi qo'shilsa, ro'yxatdan o'tish siyosatlarini, hisobni bog'lash siyosatlarini yoki ichki foydalanuvchi qidirish oqimlarini qayta yaratish zarurati yo'q.
Yangi ro'yxatdan o'tish va mavjud hisobni bog'lashni ajratish
Agar tashqi autentifikatsiya muvaffaqiyatli o'tsa, lekin ichki bog'lovchi ma'lumotlar yo'q bo'lsa, foydalanuvchining yangi yoki mavjud hisobga ega ekanligi aniq emas. Agar server bu holatda ro'yxatdan o'tishni o'z xohishiga ko'ra davom ettirsa, takroriy hisoblar yaratilishi mumkin. Aksincha, agar mavjud hisob faqat elektron pochta bir xil bo'lganligi uchun bog'lanadigan bo'lsa, noto'g'ri hisob bog'lanishi mumkin.
Ushbu muammoni bartaraf etish uchun tashqi autentifikatsiya tekshiruvlari natijalari va haqiqiy ro'yxatdan o'tish yoki bog'lash alohida ajratiladi. Gate avval tashqi foydalanuvchilarni tekshiradi va agar ichki bog'langan foydalanuvchilar bo'lmasa, ro'yxatdan o'tish tokenini beradi. Keyin, agar foydalanuvchi ro'yxatdan o'tishni tanlasa, oqim ro'yxatga olish jarayoniga o'tadi; agar ular mavjud hisobni bog'lashni tanlashsa, oqim hisobni bog'lash jarayoniga o'tadi.
Ushbu ajratish ekran oqimiga ham yordam beradi. Mijoz Gate'dan javobga qarashi mumkin va agar foydalanuvchi allaqachon bog'langan bo'lsa, kirish oqimini davom ettirishi mumkin, bog'lanmagan foydalanuvchilar uchun esa ro'yxatdan o'tish yoki hisobni bog'lash ekranini taqdim etadi. Bu har bir ta'minotchi uchun turli ekran mantiqini yaratish zaruratini kamaytiradi.
Ro'yxatdan o'tish jarayonida kompaniyaning siyosatlari tekshiriladi. Tashqi ta'minotchilar asosidagi ro'yxatdan o'tish ruxsat berilishi, elektron pochta talab etilishi, elektron pochtani tasdiqlash zarurligi, administrator tasdig'i kerakligi va hokazo aniqlanadi. Ichki foydalanuvchilar yaratilib, tashqi hisob bog'lash ma'lumotlari faqat ushbu siyosatdan o'tgandan so'ng saqlanadi.
Mavjud hisobni bog'lashda ichki hisob egasini tekshirish amalga oshiriladi. Mavjud hisob faqat tashqi ta'minotchining autentifikatsiya natijasi asosida bog'lanmaydi, balki ichki hisobning autentifikatsiya ma'lumotlari qaytadan tekshiriladi. Ushbu qadam noto'g'ri bog'lanishga qarshi muhim himoyadir.
Emailga asoslangan avtomatik bog'lash
Uchinchi tomonli kirishda elektron pochta bilan avtomatik bog'lash qulay, lekin ehtiyotkorlik bilan yondoshishni talab qiladi. Foydalanuvchi tajribasi nuqtai nazaridan qaraganda, ta'minotchidan olingan elektron pochta ichki hisobning elektron pochtasi bilan mos kelganda avtomatik bog'lash tabiiy ko'rinadi. Biroq, bir xil elektron pochta satriga ega bo'lish hisob egaligini tasdiqlamaydi.
Shuning uchun oddiy elektron pochta asosidagi bog'lash va tasdiqlangan elektron pochta asosidagi bog'lashni ajratish zarur. Agar ta'minotchi aniq tasdiqlangan elektron pochta egaligini ko'rsatib bersa, avtomatik bog'lanishning ishonchliligi oshadi. Aksincha, tasdiqni kafolatlay olmaydigan ta'minotchi bilan, avtomatik bog'lashni cheklash xavfsizroqdir.
Shuningdek, agar bir xil elektron pochta bilan bir nechta faol foydalanuvchilar bo'lsa, ulardan biri avtomatik ravishda tanlanmasligi kerak. Autentifikatsiya tizimidagi noaniq avtomatik aniqlash xavfsizlik hodisalariga olib kelishi mumkin. Bunday holatda, buni siyosat buzilishi sifatida ko'rish va foydalanuvchini hisoblarni tartiblash yoki bog'lash jarayonini aniq ko'rsatmalar orqali boshqarish yaxshiroqdir.
Email bilan bog'lash qulaylik va xavfsizlik o'rtasida muvozanatni talab qiladi. Vizend's ThirdParty kirishida oqim ta'minotchiga qarab elektron pochta tasdiqlash holatini va ichki foydalanuvchilar o'rtasidagi takrorlanuvchanlik holatini hisobga olish uchun bo'lingan.
Ro'yxatdan o'tish tokenining roli
Ro'yxatdan o'tish tokeni tashqi autentifikatsiya va ichki ro'yxatga olish yoki ulanishni bog'lash uchun mo'ljallangan qisqa muddatli token hisoblanadi. Tashqi provayder autentifikatsiyasi natijasi provayder foydalanuvchi IDsi, elektron pochta, elektron pochta tasdiqlanganligi va ism kabi ma'lumotlarni o'z ichiga oladi. Ushbu qiymatlar ro'yxatdan o'tish va ulanish uchun kerak, lekin mijoz tomonidan tasodifiy o'zgartirilmasligi kerak.
Ro'yxatdan o'tish tokenidan foydalanish serverga tashqi autentifikatsiya natijasini saqlashga va faqat mijozga noaniq token uzatishga imkon beradi. Ro'yxatdan o'tish yoki ulanish so'rovi keyinchalik kelganda, server tokenni tekshirib asl tashqi autentifikatsiya natijasini tiklaydi. Ushbu usul tashqi autentifikatsiya natijalarining manipulyatsiya qilish imkoniyatini kamaytiradi va tashqi autentifikatsiya va ichki qayta ishlash o'rtasidagi vaqt farqini xavfsiz boshqaradi.
Tokenlar qisqa vaqt ichida amaldagi bo'lishi va bir marta ishlatilgandan keyin qayta ishlatilmasligi kerak. Agar foydalanuvchi ro'yxatdan o'tish ekranida juda uzoq vaqt qolsa, token amal qilish muddati o'tishi mumkin, va oldin ishlatilgan tokenning qayta yuborilishi mumkin, bu brauzer orqaga yurish navigatsiyasi yoki takroriy yuborishlar sababli. Bunday hollarda, foydalanuvchini tashqi autentifikatsiya tizimiga qaytarish tabiiy yondashuvdir.
Ishlab chiqarish muhitida, tokenlarni saqlash usuli ham muhimdir. Bitta holatda, xotira asosidagi saqlash oddiy ishlashi mumkin, lekin bir necha holatga kengaytirilgan muhitda, umumiy saqlash zarur. Bu tokenni ishlab chiqadigan va iste'mol qiladigan holatlar boshqacha bo'lishi mumkinligi bilan bog'liq. Shuning uchun, kengaytirishni hisobga olib, Redis kabi umumiy saqlash asosida rivojlantirish ma'qul.
Ilova natijalari
ThirdParty login'i joriy etgandan va qayta tuzganimizdan so'ng, oqim provayderga xos amalga oshirishlar va domen siyosatlari bo'yicha ajratildi. Google, Facebook, Apple va Keycloakda turli xil autentifikatsiya usullari mavjud bo'lsa-da, ular Gate ichidagi bitta oqimda boshqarilishi mumkin. Provayderlar o'rtasidagi farqlar oldindan tashkil etilgan, va shundan so'ng, ichki foydalanuvchini moslashtirish, ro'yxatdan o'tish siyosatlari va hisob ulash siyosatlari bir xilda qo'llaniladi.
Bundan ham operatsion afzalliklar mavjud. Provayderlar har bir kompaniyaning asosida faollashtirilishi yoki o'chirilishi mumkin, va har bir provayderga xos mijoz sozlamalari yoki qaytish URI'lari siyosatlar sifatida boshqarilishi mumkin. Agar muammo aniqlanadigan provayder bilan yuzaga kelsa, faqat ushbu provayder siyosatini o'zgartirish mumkin, umumiy autentifikatsiya tuzilmasini o'zgartirmasdan.
Xavfsizlik nuqtai nazaridan tashqi autentifikatsiya va ichki kirish hukmini ajratish eng muhimdir. Agar tashqi provayder autentifikatsiyasi muvaffaqiyatli bo'lsa, xizmatga kirish faqat ichki foydalanuvchi holati va siyosatlaridan o'tgach sodir bo'lishi mumkin. Agar foydalanuvchida tashqi hisob bo'lsa, lekin Vizend ichida faol bo'lmasa, kirishga ruxsat berilmasligi mumkin.
Texnik xizmat ko'rsatish nuqtai nazaridan, provayderlarni qo'shish narxi kamayadi. Yangi provayder qo'shilganda, bu faqat u provayderning ma'lumotlarini tekshirishni va umumiy foydalanuvchi ma'lumotlari konvertatsiyasini yangilashni talab qiladi. Ro'yxatdan o'tish siyosatlari, ulanish siyosatlari va ichki foydalanuvchini qidirish oqimlari hali ham o'z holicha foydalanilishi mumkin. Ushbu ajratuvchilik uzoq muddatda autentifikatsiya usullarini oshirish imkoniyati mavjud bo'lgan xizmatlar uchun muhimdir.
Xulosa
ThirdParty login faqat oddiy OAuth API chaqiruvi emas, balki tashqi autentifikatsiya natijalarini ichki foydalanuvchi modeliga ulovchi autentifikatsiya oqimidir. Bu foydalanuvchi ekranida bitta tugma sifatida ko'rinsa ham, server ichida tashqi autentifikatsiya, ichki foydalanuvchi holati, ro'yxatdan o'tish siyosatlari, hisob ulash va sessiya siyosatlari bir-biriga bog'langan. Agar bu oqim aniq ajratilmasa, amalga oshirish tez ko'rinishi mumkin, lekin operatsion va kengaytirish qiyinchiliklari yuzaga keladi.
Vizendning ThirdParty loginni joriy etish va qayta tuzish jarayonida biz tashqi provayderlar o'rtasidagi farqlarni oldindan tashkil etishni, kompaniyaga xos siyosatlarni sozlamalar orqali boshqarishni va ichki foydalanuvchi va autentifikatsiya siyosatlariga asoslangan haqiqiy xizmatga kirish hukmlarini saqlashni tanladik. Ushbu tuzilma provayderlar soni oshgani sari autentifikatsiya modelida barqarorlikni ta'minlaydi.
Autentifikatsiya sohasida noto'g'ri ulanishlarni oldini olish qulaylikdan ko'ra muhimroq. Foydalanuvchilarning elektron pochta manzillari bir xilda bo'lgani uchun avtomatik hisob ulashdan bosh tortish, tasdiqlanmagan elektron pochta manzillariga ishonmaslik va bir marta ishlatilgan tokenlarning qayta ishlatilishini oldini olish kabi qarorlar barchasi bir yo'nalishda. Agar bu foydalanuvchilardan qo'shimcha tasdiqlash qadamini talab qilsa ham, noto'g'ri hisob ulashning oldini olish xavfsizroq.
Kelajakda ro'yxatdan o'tish tokeni saqlash operatsion kengaytirilish bo'yicha umumiy saqlash asosiga o'tkaziladi, va qo'l bilan ulashni tasdiqlash yoki administrator tasdiqlash kabi siyosatlar operatsion interfeysgacha yaqinroq bog'lanishi mumkin. Provayder bo'yicha muvaffaqiyatsizliklar va ishlash vaqtlarini kuzatish ham hodisalar javobini tezlashtiradi. ThirdParty login faqat tashqi kirish usullarini oshirishdan tashqari ichki foydalanuvchi modeli bilan turli autentifikatsiya usullarini doimiy ravishda bog'lashni ta'minlovchi asosiy funktsiya sifatida ko'rilishi mumkin.
David