Bir neçə ay əvvəl mən yüzlərlə daxili tətbiqimizə girişi idarə etmək üçün OpenID Connect serverini tətbiq edirdim. Daha kiçik miqyasda əlverişli olan öz inkişaflarımızdan biz ümumi qəbul edilmiş standarta keçdik. Mərkəzi xidmət vasitəsilə giriş monoton əməliyyatları xeyli asanlaşdırır, icazələrin həyata keçirilməsi xərclərini azaldır, bir çox hazır həllər tapmağa və yenilərini hazırlayarkən beyninizi sındırmağa imkan verir. Bu yazıda mən bu keçiddən və doldurmağı bacardığımız qabarlardan danışacağam.
Çoxdan... Hər şey necə başladı
Bir neçə il əvvəl, əl ilə idarəetmə üçün çoxlu daxili proqramlar olduqda, şirkət daxilində girişə nəzarət etmək üçün ərizə yazdıq. Bu, müxtəlif funksionallıqlara girişin konfiqurasiya edildiyi işçilər haqqında məlumat olan verilənlər bazasına qoşulan sadə Rails proqramı idi. Eyni zamanda, müştəri və avtorizasiya serveri tərəfindən tokenlərin yoxlanılmasına əsaslanan ilk SSO-nu qaldırdıq, token bir neçə parametrlə şifrələnmiş formada ötürüldü və avtorizasiya serverində yoxlanıldı. Bu, ən əlverişli seçim deyildi, çünki hər bir daxili proqram əhəmiyyətli bir məntiq qatını təsvir etməli idi və işçi məlumat bazaları avtorizasiya serveri ilə tamamilə sinxronlaşdırıldı.
Bir müddət sonra biz mərkəzləşdirilmiş avtorizasiya tapşırığını sadələşdirmək qərarına gəldik. SSO balanslaşdırıcıya köçürüldü. OpenResty-nin köməyi ilə Lua-ya tokenləri yoxlayan, sorğunun hansı tətbiqə getdiyini bilən və orada giriş olub-olmadığını yoxlaya bilən şablon əlavə edildi. Bu yanaşma daxili proqramlara girişi idarə etmək tapşırığını xeyli sadələşdirdi - hər bir tətbiqin kodunda əlavə məntiqi təsvir etmək artıq lazım deyildi. Nəticədə biz trafiki xaricdən bağladıq və tətbiqin özü avtorizasiya haqqında heç nə bilmirdi.
Ancaq bir problem həll olunmamış qaldı. İşçilər haqqında məlumat tələb edən proqramlar haqqında nə demək olar? Avtorizasiya xidməti üçün API yazmaq mümkün idi, lakin sonra hər bir belə tətbiq üçün əlavə məntiq əlavə etməli olacaqsınız. Bundan əlavə, biz daxili avtorizasiya serverimizdə gələcəkdə OpenSource-a tərcüməyə yönəlmiş öz-özünə yazılmış proqramlarımızdan birindən asılılıqdan xilas olmaq istədik. Bu barədə başqa vaxt danışacağıq. Hər iki problemin həlli OAuth idi.
ümumi standartlara
OAuth başa düşülən, ümumiyyətlə qəbul edilmiş avtorizasiya standartıdır, lakin yalnız onun funksionallığı kifayət etmədiyi üçün dərhal OpenID Connect (OIDC) nəzərdən keçirməyə başladılar. OIDC özü OAuth 2.0 protokolu (açıq avtorizasiya protokolu) üzərində əlavəyə daxil olan açıq autentifikasiya standartının üçüncü tətbiqidir. Bu həll son istifadəçi haqqında məlumat çatışmazlığı problemini aradan qaldırır, həmçinin avtorizasiya provayderini dəyişdirməyə imkan verir.
Bununla belə, biz konkret provayder seçmədik və mövcud avtorizasiya serverimiz üçün OIDC ilə inteqrasiya əlavə etmək qərarına gəldik. Bu qərarın lehinə OIDC-nin son istifadəçi icazəsi baxımından çox çevik olması faktı oldu. Beləliklə, cari avtorizasiya serverinizdə OIDC dəstəyini həyata keçirmək mümkün oldu.
Öz OIDC serverimizi həyata keçirmə üsulumuz
1) Məlumatları istədiyiniz formaya gətirin
OIDC-ni inteqrasiya etmək üçün cari istifadəçi məlumatlarını standart tərəfindən başa düşülən formaya gətirmək lazımdır. OIDC-də buna İddialar deyilir. İddialar mahiyyətcə istifadəçi verilənlər bazasında (ad, e-poçt, telefon və s.) yekun sahələrdir. Mövcuddur , və bu siyahıya daxil olmayan hər şey xüsusi hesab olunur. Buna görə, mövcud OIDC provayderini seçmək istəyirsinizsə, diqqət etməli olduğunuz ilk məqam, yeni markaların rahat fərdiləşdirilməsi imkanıdır.
Əlamətlər qrupu aşağıdakı alt qrupa birləşdirilir - Əhatə dairəsi. Avtorizasiya zamanı, əhatə dairəsindən bəzi markalara ehtiyac olmasa belə, xüsusi markalara deyil, əhatə dairələrinə giriş tələb olunur.
2) Lazımi qrantları həyata keçirdi
OIDC inteqrasiyasının növbəti hissəsi qrantlar adlanan icazə növlərinin seçilməsi və həyata keçirilməsidir. Seçilmiş proqram və avtorizasiya serveri arasında qarşılıqlı əlaqənin sonrakı ssenarisi seçilmiş qrantdan asılı olacaq. Düzgün qrant seçmək üçün nümunəvi sxem aşağıdakı şəkildə göstərilmişdir.
İlk müraciətimiz üçün ən çox yayılmış qrant olan İcazə Məcəlləsindən istifadə etdik. Onun digərlərindən fərqi üç pilləli olmasıdır, yəni. əlavə sınaqdan keçirilir. Əvvəlcə istifadəçi avtorizasiya icazəsi üçün sorğu edir, bir token alır - Avtorizasiya Kodu, sonra bu tokenlə, sanki səyahət bileti ilə, giriş nişanı tələb edir. Bu avtorizasiya skriptinin bütün əsas qarşılıqlı əlaqəsi proqram və avtorizasiya serveri arasında yönləndirmələrə əsaslanır. Bu qrant haqqında daha çox oxuya bilərsiniz .
OAuth, avtorizasiyadan sonra əldə edilən giriş nişanlarının müvəqqəti olması və orta hesabla hər 10 dəqiqədən bir dəyişdirilməsi konsepsiyasına əməl edir. Authorization Code qrant yönləndirmələr vasitəsilə üç addımlı yoxlamadır, hər 10 dəqiqədən bir belə bir addımı çevirmək, açığı, gözlər üçün ən xoş iş deyil. Bu problemi həll etmək üçün başqa bir qrant var - Refresh Token, biz də ölkəmizdə istifadə etdik. Burada hər şey daha asandır. Başqa bir qrantdan yoxlama zamanı, əsas giriş tokeninə əlavə olaraq, başqa biri verilir - yalnız bir dəfə istifadə edilə bilən və ömrü adətən daha uzun olan Yeniləmə Tokeni. Bu Yeniləmə Tokeni ilə əsas giriş nişanının TTL (Yaşamaq vaxtı) başa çatdıqda, yeni giriş nişanı üçün sorğu başqa bir qrantın son nöqtəsinə gələcək. İstifadə olunmuş Yeniləmə Tokeni dərhal sıfırlanır. Bu yoxlama iki addımlıdır və istifadəçi üçün hiss olunmadan arxa planda həyata keçirilə bilər.
3) Xüsusi məlumat çıxış formatlarını qurun
Seçilmiş qrantlar həyata keçirildikdən, avtorizasiya işləri aparıldıqdan sonra son istifadəçi haqqında məlumatların əldə edilməsini qeyd etmək lazımdır. OIDC-nin bunun üçün ayrıca son nöqtəsi var, burada cari giriş nişanı ilə və onun yeni olub-olmaması ilə istifadəçi məlumatlarını tələb edə bilərsiniz. İstifadəçinin məlumatları tez-tez dəyişmirsə və indikiləri dəfələrlə izləmək lazımdırsa, JWT tokenləri kimi bir həll yoluna gələ bilərsiniz. Bu tokenlər də standart tərəfindən dəstəklənir. JWT tokeninin özü üç hissədən ibarətdir: başlıq (token haqqında məlumat), faydalı yük (hər hansı zəruri məlumat) və imza (imza, token server tərəfindən imzalanır və sonra onun imza mənbəyini yoxlaya bilərsiniz).
OIDC tətbiqində JWT tokeni id_token adlanır. Normal giriş nişanı ilə birlikdə tələb oluna bilər və imzanı yoxlamaq qalır. Avtorizasiya serverində bunun üçün formatda bir dəstə ictimai açarla ayrıca son nöqtə var . Bundan danışarkən, standarta əsaslanan başqa bir son nöqtənin olduğunu qeyd etmək lazımdır OIDC serverinin cari konfiqurasiyasını əks etdirir. O, bütün son nöqtə ünvanlarını (imza üçün istifadə olunan açıq açar halqasının ünvanı daxil olmaqla), dəstəklənən markalar və əhatə dairələrini, istifadə olunan şifrələmə alqoritmlərini, dəstəklənən qrantları və s.
Məsələn, Google-da:
{
"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"
]
}Beləliklə, id_token istifadə edərək, bütün lazımi işarələri tokenin faydalı yükünə köçürə və istifadəçi məlumatlarını tələb etmək üçün hər dəfə avtorizasiya serveri ilə əlaqə saxlamaya bilərsiniz. Bu yanaşmanın dezavantajı odur ki, serverdən istifadəçi məlumatlarında dəyişiklik dərhal deyil, yeni giriş nişanı ilə birlikdə baş verir.
İcra nəticələri
Beləliklə, öz OIDC serverimizi tətbiq etdikdən və tətbiq tərəfində onunla əlaqəni konfiqurasiya etdikdən sonra istifadəçilər haqqında məlumatların ötürülməsi problemini həll etdik.
OIDC açıq standart olduğundan, mövcud provayder və ya server tətbiqini seçmək seçimimiz var. Tətbiq tərəfində əlaqə konfiqurasiyalarını qurduqdan və dəyişdirdikdən sonra konfiqurasiya etmək çox rahat olduğu ortaya çıxan Keycloak-ı sınadıq, getməyə hazırdır. Tətbiq tərəfində yalnız əlaqə konfiqurasiyalarını dəyişdirmək qalır.
Mövcud həllər haqqında danışırıq
Təşkilatımız daxilində ilk OIDC serveri olaraq biz öz tətbiqimizi yığdıq və lazım olduqda əlavə edildi. Digər hazır həlləri ətraflı nəzərdən keçirdikdən sonra bunun mübahisəli bir nöqtə olduğunu söyləyə bilərik. Öz serverlərini həyata keçirmək qərarının lehinə, provayderlər tərəfindən lazımi funksionallığın olmaması, habelə bəzi xidmətlər üçün müxtəlif xüsusi icazələrin və kifayət qədər çox olduğu köhnə sistemin olması ilə bağlı narahatlıqlar var idi. işçilər haqqında məlumat artıq saxlanılırdı. Bununla belə, hazır tətbiqlərdə inteqrasiya üçün rahatlıqlar var. Məsələn, Keycloak-ın öz istifadəçi idarəetmə sistemi var və məlumatlar birbaşa orada saxlanılır və orada istifadəçilərinizi ötmək çətin olmayacaq. Bunun üçün Keycloak bütün lazımi köçürmə hərəkətlərini tam yerinə yetirməyə imkan verən API-yə malikdir.
Sertifikatlaşdırılmış, maraqlı, mənim fikrimcə, tətbiqin başqa bir nümunəsi Ory Hydradır. Müxtəlif komponentlərdən ibarət olduğu üçün maraqlıdır. İnteqrasiya etmək üçün istifadəçi idarəetmə xidmətinizi onların avtorizasiya xidməti ilə əlaqələndirməli və lazım olduqda genişləndirməlisiniz.
Keycloak və Ory Hydra yeganə hazır həllər deyil. Ən yaxşısı OpenID Fondu tərəfindən təsdiq edilmiş tətbiqi seçməkdir. Bu həllər adətən OpenID Sertifikatlaşdırma nişanına malikdir.
OIDC serverinizi saxlamaq istəmirsinizsə, mövcud ödənişli provayderləri də unutmayın. Bu gün çox yaxşı variantlar var.
Nədir?
Yaxın gələcəkdə daxili xidmətlərə trafiki fərqli şəkildə bağlayacağıq. Cari SSO-muzu OpenResty-dən istifadə edərək balanslaşdırıcıya OAuth-a əsaslanan proksiyə köçürməyi planlaşdırırıq. Burada artıq bir çox hazır həllər var, məsələn:
Əlavə materiallar
– JWT tokenlərini təsdiqləmək üçün yaxşı xidmət
- sertifikatlaşdırılmış OIDC tətbiqlərinin siyahısı
Mənbə: www.habr.com