Qeyd. tərc.: Bu maraqlı materialda Okta şirkəti OAuth və OIDC (OpenID Connect) işləmə prinsiplərini sadə və açıq şəkildə izah edir. Bu biliklər, proqramçılar, sistem administratorları və hətta populyar veb tətbiqlərin "adi istifadəçiləri" üçün faydalı olacaq, çünki onlar çox güman ki, digər xidmətlərlə gizli məlumat mübadiləsi həyata keçirirlər.
İnternetin "daş dövründə" xidmətlər arasında məlumat paylaşmaq asan idi. Sadəcə, bir xidmət üçün istifadəçi adı və şifrənizi digərinə verirdiniz ki, o sizin hesabınıza daxil olub, tələb olunan bütün məlumatları əldə etsin.
„Bank hesabınızı təqdim edin“. — „Şifrəniz və pulunuz təhlükəsiz olacaq. Tamamilə dürüst!” *Heh-heh*
Yaman! Heç kimdən istifadəçi adı və şifrəsini paylaşmasını tələb etmək olmaz. məlumatları, digər xidmətlə paylaşsın. Belə bir xidmətin arxasında duran təşkilatın məlumatları təhlükəsiz saxlayacağı və lazım olduğundan daha çox şəxsi məlumat toplamayacağına dair heç bir zəmanət yoxdur. Bu, dəhşətli görünə bilər, amma bəzi proqramlar hələ də bu cür praktikadan istifadə edirlər!
Bu gün bir xidmətin digərinin məlumatlarından təhlükəsiz istifadə etməsinə icazə verən unikal bir standart mövcuddur. Təəssüf ki, bu cür standartlar çox sayda jargon və termin istifadə edir, bu da onların başa düşülməsini çətinləşdirir. Bu materialın məqsədi, sadə illüstrasiyalarla, onların necə işlədiyini izah etməkdir (Sizcə, mənim rəsmlərim uşaq işinə bənzəyir? Yaxşı, zülfikar!)
Bu arada, bu bələdçi vide formatında da mövcuddur:
Cənablar, tanış olun: OAuth 2.0
— bir tətbiqin digər tətbiqdəki məlumatlara daxil olma icazəsini alınmasına imkan tanıyan təhlükəsizlik standartıdır. İcazə verilməsi prosesi [permission] (və ya razılıq [consent]) tez-tez səlahiyyət verilməsi [authorization] və ya hətta delegasiyalı icazə [delegated authorization]. Bu standartdan istifadə edərək, tətbiqə öz şifrənizi bildirmədən digər tətbiqin məlumatlarını oxumağı və ya funksiyalarını istifadə etməyə icazə verirsiniz. Əla!
Məsələn, "Günün İflaslı Kalamburu" adında bir səhifə kəşf etdiyinizi təsəvvür edin [Terrible Pun of the Day] və gündəlik olaraq telefonunuza mətn mesajı olaraq kalamburlar almaq üçün qeydiyyatdan keçmək qərarına gəldiniz. Səhifəni çox bəyəndiniz və bunu tanışlarınızla bölüşmək istədiniz. Axı, pis kalamburlar hamıya xoş gəlir, elə deyil?
"Günün İflaslı Kalamburu: Sol bədəninin yarısını itirən oğlandan eşitdiniz? İndi həmişə sağdır!" (tərcümə təxminidir, çünki orijinalda öz oyun sözü var — qeyd. tərc.)
Aydındır ki, əlaqə siyahınızdakı hər bir insana yazmaq mümkün deyil. Və əgər mənim kimi bir az da olsa siz də belə düşünürsünüzsə, o zaman əlavə işdən qaçmaq üçün hər şeyi edəcəksiniz. Xoşbəxtlikdən, Terrible Pun of the Day sizin dostlarınıza dəvət göndərə bilər! Bunun üçün yalnız kontaktlarınızın elektron poçtuna giriş imkanı vermək lazımdır — sayt onları avtomatik olaraq dəvət edəcək (OAuth rəhbərdir)!
«Hamı kalamburlarını sevir! — Artıq giriş etmisiniz? — Terrible Pun of the Day-ə əlaqə siyahınıza daxil olma icazəsi vermək istəyirsiniz? — Təşəkkürlər! İndi biz hər gün tanışlarınıza xatırlatmalar göndərəcəyik, əbədi olaraq! Siz ən yaxşı dostsunuz!»
- E-poçt xidmətinizi seçin.
- Gərəkli olduqda poçt saytına keçin və hesabınıza daxil olun.
- Terrible Pun of the Day saytına kontaktlarınıza daxil olma icazəsi verin.
- Terrible Pun of the Day saytına qayıdın.
Düşüncənizdən daşınırsınızsa, OAuth istifadə edən proqramlar da icazəni ləğv etmə imkanı təqdim edir. Artıq Terrible Pun of the Day ilə əlaqələrinizi paylaşmaq istəmirsinizsə, poçt saytına keçin və kalambur saytını icazə verilmiş proqramlar siyahısından silin.
OAuth axını
Məhz hal-hazırda başa çatdığımız şey adətən axın [flow] OAuth-da. Bizim nümunəmizdə bu axın görünən addımlardan ibarətdir və bir neçə görünməz addımı dəyişdirərək iki xidmət arasında təhlükəsiz məlumat mübadiləsi barədə razılaşılır. Terrible Pun of the Day ilə bağlı əvvəlki nümunə, 'authorization code' axını adlanan ən geniş yayılmış OAuth 2.0 axınını istifadə edir. [‘authorization code’ flow].
OAuth-un necə işlədiyinə dərinləşmədən əvvəl, bəzi terminlərin mənasını müzakirə edək:
- Resurs Sahibi:
Bu, sizsiniz! Siz öz məlumatlarınıza, öz kimlik məlumatlarınıza sahibsiniz və hesablarınızla bağlı bütün fəaliyyətləri idarə edirsiniz. - Müştəri:
Sizə (məsələn, Terrible Pun of the Day xidməti) öz adından daxil olmaq və ya müəyyən fəaliyyətlər həyata keçirmək istəyən tətbiq. Resurs Sahibi‘ın. - İcazə Verən Server:
Sizin məlumatlarınıza sahib olan tətbiq Resurs Sahibi‘ın və Resurs Sahibiorada artıq hesabınız var. - Resurs Serveri:
Proqram interfeysi (API) və ya xidmət, Müştəri onun adından istifadə etmək istədiyi Resurs Sahibi‘ın. - Yenidən Yönləndirilən URI:
Bağlantı, İcazə Verən Server məbləği Resurs Sahibi‘a təqdim edildikdən sonra Müştəri‘u. Bunu bəzən «Qaytarıcı URL» («Callback URL») adlandırır. - Cavab Növü:
Hansı məlumatı əldə etməyə ümid etdiyinizi Müştəriİstifadəçidən alınır. Ən geniş yayılmış Cavab Növütip,” Müştəri o deməkdir ki, İcazə Kodunu alır. - Məzmun:
Bu detallı izahdır ki, hansılarının 'bəzi' tələb olunan icazələrdir Müştəri‘a, məsələn, məlumatlara giriş və ya müəyyən fəaliyyətlərin həyata keçirilməsi. - Razılıq:
İcazə Verən Server birmənalıdır; Tələb olunan‘ın, istəyi sənəd Müştəri‘a, ona uyğun icazələr verməsi üçün onu soruşur. Resurs SahibiMüştəri ID MüştəriBu ID, - ‘ı tanımaq üçün istifadə olunur.:
Müştəri Gizliyi MüştəriBu, yalnız İcazə Verən Server‘a məlum olan bir parol. - ‘ın:
Bu, yalnızca Müştəri‘u tərəfindən bilinən bir paroldur. İcazə Verən ServerO, müştərilərin gizli şəkildə məlumat paylaşmalarına imkan tanıyır. - İcazə Kodunu alır:
Qısa müddətli və asanlıqla istifadə edilə bilən koddur ki, bu da Müştəri təmin edir İcazə Verən ServerMübadilə etmək üçün Access Token. - Access Token:
Müştərinin Resurs Serverisistemlə əlaqə qurmaq üçün istifadə edəcəyi açardır. Bu, məlumatların sorğusu və ya sizin adınıza hər hansı bir hərəkət etmək üçün sistemə icazə verən bir badge və ya açar kartdır. MüştəriMəlumatlarına erişim əldə etməyə icazə verir. Resurs Serveriİstədiyiniz məlumatı sizin adınıza əldə etməsi üçün.
Qeyd: Bəzən Authorization Server və Resource Server eyni server ola bilər. Lakin bəzən bu, fərqli serverlər də ola bilər, hətta eyni təşkilata aid olmayan. Məsələn, Authorization Server bir üçüncü tərəf xidməti ola bilər ki, bu da Resource Server tərəfindən etibar edilir.
İndi, OAuth 2.0 ilə bağlı əsas anlayışlarla tanış olduq, gəlin misalımıza qayıdaq və OAuth axınında baş verənləri daha ətraflı nəzərdən keçirək.
- Siz, Resurs Sahibi, Terrible Pun of the Day (Müştəri) xidmətinə dostlarınıza dəvət göndərmək üçün kontaktlarınıza giriş imkanı vermək istəyirsiniz.
- Müştəri brauzeri İcazə Verən Serversəhifəsinə yönləndirir ‘ı tanımaq üçün istifadə olunur., Yenidən Yönləndirilən URI, Cavab Növü və bir və ya bir neçə Tələb olunan (icazə) tələb edir.
- İcazə Verən Server Sizi yoxlayır, lazım olduğu halda istifadəçi adı və şifrə tələb edir.
- İcazə Verən Server Bütün Razılıq (təsdiq) forması ilə təqdim edir. Tələb olunanbütün Müştərisistem tərəfindən tələb olunan
- İcazə Verən Server İcazəni qəbul edirsiniz və ya imtina edirsiniz. MüştəriSizi Yenidən Yönləndirilən URI saytına yönləndirir İcazə Kodunu alır və
- Müştəri (təsdiq kodu) ilə. İcazə Verən Serverbirbaşa əlaqə qurur Resurs Sahibisistemlə (brauzerdən kənar) və təhlükəsiz şəkildə ‘ı tanımaq üçün istifadə olunur., ‘ın və İcazə Kodunu alır.
- İcazə Verən Server göndərir. Access TokenMəlumatları yoxlayır və
- Artıq Müştəri istifadə edə bilər Access Token bu sistemə sorğu göndərmək üçün Resurs Serveri əlaqə siyahısının alınması məqsədilə.
Müştəri ID və Secret
Terrible Pun of the Day xidmətinə kontaktlarınıza giriş icazəsi vermədən əvvəl, Müştəri və Authorization Server arasında etibarlı münasibətlər yaradılıb. Authorization Server Müştəri ID və Müştəri Secret-i (bəzən onları App ID və App Secret) yaradır və bunu Müştəriyə göndərir ki, OAuth çərçivəsində daha da əlaqə qursun.
«— Salam! Səninlə işləmək istərdim! — Əlbəttə! Buyur, sənin Müştəri ID və Secret!»
Adından görünür ki, Müştəri Secret gizli saxlanmalıdır, yalnız Müştəri və Authorization Server tərəfindən bilinməlidir. Çünki məhz onun vasitəsilə Authorization Server Müştərinin doğruluğunu təsdiqləyir.
Amma bu hələ bitmir… Açılışda OpenID Connect-ə salam verin!
OAuth 2.0 yalnız autentifikasiya üçün hazırlanmışdır — bir tətbiqdən digərinə məlumatlara və funksiyalara giriş verilməsi məqsədiylə. (OIDC) — OAuth 2.0 üstündə incə bir qatdır, istifadəçi girişləri və profil məlumatlarını əlavə edir. Giriş sessiyasını authenticationadlandırırlar, və sistemdə olan istifadəçi haqqında məlumatlar (yəni. Resurs Sahibi) — şəxsi məlumatlar identity. Əgər Authorization Server OIDC-ni dəstəkləyirsə, bəzən ona şəxsi məlumatlar xidməti identity providerdeyilir, çünki Müştərisistemdə istifadəçi haqqında məlumat təqdim edir. Resurs Sahibi‘a məlum olan bir parol.
OpenID Connect bir çox tətbiqdə eyni giriş istifadə etməyə imkan verən ssenariləri həyata keçirməyə imkan tanıyır — bu yanaşma təkliklə giriş (SSO) kimi tanınır. Məsələn, bir tətbiq SSO-nu Facebook və Twitter kimi sosial şəbəkələrlə inteqrasiya edə bilər, istifadəçilərə artıq mövcud olan və istifadə etməyi prefer etdikləri hesabı istifadə etməyə imkan tanıyır.
OpenID Connect axını (flow) OAuth-da olduğu kimi görünür. Yeganə fərq, ilkin sorğuda istifadə olunan konkret scope-un openidolmasıdır, — və Müştəri nəticədə həm Access Token, həm də ID Token.
OAuth axınında olduğu kimi, Access Token OpenID Connectdə — müəyyən bir dəyərdir ki, bu, Müştəri‘a. Müqayisədə Müştəri‘dan Access Token bir simvol sətirini təmsil edir ki, bu, hər sorğu ilə birlikdə Resurs Serveri‘a ötürülür, və o, tokenin etibarlı olub olmadığını müəyyən edir. ID Token tamamilə fərqli bir şeydir.
ID Token — bu, JWT-dir
ID Token — xüsusi şəkildə formatlanmış simvol sətiridir ki, buna JSON Web Token və ya JWT deyilir (bəzən JWT-ləri «jots» olaraq tələffüz edirlər). Xarici müşahidəçilər üçün JWT-nin başa düşülməsi çətin olsa da, Müştəri JWT-dən müxtəlif məlumatları çıxara bilər, məsələn, ID, istifadəçi adı, hesabınıza giriş zamanı, son istifadə müddəti ID Token‘ın, JWT-yə müdaxilə etmə cəhdlərinin olub olmaması. İçindəki məlumatlar ID Token‘a tələbələr [claims].
OIDC vəziyyətində, əlavə məlumat tələb etmək üçün standart bir yol da mövcuddur Müştəri ‘dan, məsələn, e-poçt ünvanı, istifadə edərək identity aylıq İcazə Verən ServerOAuth və OIDC haqqında əlavə məlumat Access Token.
Beləliklə, OAuth və OIDC-nin iş prinsiplərini qısaca nəzərdən keçirdik. Daha dərin getməyə hazırsınız? OAuth 2.0 və OpenID Connect haqqında daha çox öyrənməyə kömək edəcək əlavə resurslar:
OAuth nədir?
Okta şirkətinin inkişaf etdiricilər üçün olan bülleteninə abunə olun! və P.S. tərcüməçidən
Kubernetes-də təhlükəsizlik: identifikasiya, icazə, audit
Blogumuzda oxuyun:
- «»;
- «»;
- «»;
- «».
Mənbə: habr.com
