Бир нече ай мурун мен жүздөгөн ички тиркемелерибизге кирүү мүмкүнчүлүгүн башкаруу үчүн OpenID Connect серверин ишке ашырып жаттым. Өзүбүздүн иштеп чыгуулардан, кичине масштабда ыңгайлуу, биз жалпы кабыл алынган стандартка өттүк. Борбордук кызмат аркылуу кирүү монотондуу операцияларды абдан жөнөкөйлөтөт, авторизацияларды ишке ашыруунун баасын төмөндөтөт, көптөгөн даяр чечимдерди табууга мүмкүндүк берет жана жаңыларын иштеп чыгууда мээңизди кыйнабаңыз. Бул макалада мен бул өткөөл жана биз толтурган бүдүрчөлөр жөнүндө сүйлөшөм.
Бир топ убакыт мурун... Баары кантип башталган
Бир нече жыл мурун, кол менен башкаруу үчүн өтө көп ички тиркемелер болгондо, биз компаниянын ичинде кирүү мүмкүнчүлүгүн көзөмөлдөө үчүн арыз жаздык. Бул жөнөкөй Rails тиркемеси болгон, ал ар кандай функцияларга жетүү конфигурацияланган кызматкерлер тууралуу маалыматы бар маалымат базасына туташкан. Ошол эле учурда биз биринчи SSOну көтөрдүк, ал токендерди кардардын жана авторизация серверинен текшерүүгө негизделген, токен бир нече параметрлер менен шифрленген түрдө өткөрүлүп, авторизация серверинде текшерилген. Бул эң ыңгайлуу вариант болгон жок, анткени ар бир ички тиркеме логиканын олуттуу катмарын сүрөттөшү керек болчу жана кызматкерлердин маалымат базалары авторизация сервери менен толугу менен синхрондоштурулган.
Бир канча убакыт өткөндөн кийин биз борборлоштурулган авторизациянын милдетин жөнөкөйлөштүрүү чечимине келдик. SSO баланстоочуга өткөрүлүп берилди. OpenResty'дин жардамы менен Луага шаблон кошулду, ал токендерди текшерип, сурам кайсы тиркемеге бараарын билген жана ал жерде кирүү мүмкүнчүлүгү бар-жогун текшере алат. Бул ыкма ички тиркемелерге кирүү мүмкүнчүлүгүн көзөмөлдөө милдетин абдан жөнөкөйлөттү - ар бир тиркеменин кодунда кошумча логиканы сүрөттөп берүүнүн кереги жок болчу. Натыйжада, биз тышкы трафикти жаптык, ал эми тиркеме өзү авторизация жөнүндө эч нерсе билген эмес.
Бирок бир маселе чечилбей калган. Кызматкерлер жөнүндө маалымат керек болгон тиркемелер жөнүндө эмне айтууга болот? Авторизациялоо кызматы үчүн API жазууга мүмкүн болчу, бирок андан кийин ар бир мындай тиркеме үчүн кошумча логиканы кошууга туура келет. Мындан тышкары, биз ички авторизация серверибизде кийинчерээк OpenSource тилине которула турган өз алдынча жазылган тиркемелерибиздин бирине болгон көз карандылыктан арылууну кааладык. Бул тууралуу башка убакта сүйлөшөбүз. эки маселени чечүү OAuth эле.
жалпы стандарттарга
OAuth түшүнүктүү, жалпы кабыл алынган авторизация стандарты, бирок анын функциясы гана жетишсиз болгондуктан, алар дароо OpenID Connect (OIDC) карай башташты. OIDC өзү OAuth 2.0 протоколунун (ачык авторизация протоколу) үстүнөн кошумчага кирген ачык аутентификация стандартынын үчүнчү ишке ашырылышы. Бул чечим акыркы колдонуучу жөнүндө маалыматтардын жоктугу көйгөйүн жаап, ошондой эле авторизациялоочу провайдерди өзгөртүүгө мүмкүндүк берет.
Бирок, биз конкреттүү провайдерди тандаган жокпуз жана учурдагы авторизация серверибиз үчүн OIDC менен интеграцияны кошууну чечтик. Бул чечимдин пайдасына OIDC акыркы колдонуучуга уруксат берүү жагынан абдан ийкемдүү болгон. Ошентип, учурдагы авторизация сервериңизде OIDC колдоосун ишке ашыруу мүмкүн болду.
Биздин OIDC серверибизди ишке ашыруу ыкмасы
1) Маалыматтарды керектүү формага алып келди
OIDCти интеграциялоо үчүн колдонуучунун учурдагы маалыматтарын стандарт менен түшүнүктүү формага келтирүү зарыл. OIDCде бул Дооматтар деп аталат. Дооматтар негизинен колдонуучунун маалымат базасындагы акыркы талаалар (аты-жөнү, электрондук почтасы, телефону ж.б.). Бар , жана бул тизмеге кирбеген нерселердин баары салт болуп эсептелет. Ошондуктан, эгер сиз иштеп жаткан OIDC провайдерин тандагыңыз келсе, көңүл бурушуңуз керек болгон биринчи жагдай - бул жаңы бренддерди ыңгайлуу ыңгайлаштыруу мүмкүнчүлүгү.
Белгилүү белгилердин тобу төмөнкү чакан топтомго бириктирилген - Колдонуу чөйрөсү. Авторизациялоо учурунда, белгилүү бир бренддерге эмес, алкактарга кирүү суралат, ал тургай, кээ бир бренддер керек болбосо да.
2) Керектүү гранттарды ишке ашырды
OIDC интеграциясынын кийинки бөлүгү – гранттар деп аталган авторизациянын түрлөрүн тандоо жана ишке ашыруу. Тандалган тиркеме менен авторизация серверинин ортосундагы өз ара аракеттенүүнүн кийинки сценарийи тандалган грантка жараша болот. Туура грантты тандоонун үлгүлүү схемасы төмөндөгү сүрөттө көрсөтүлгөн.
Биринчи арызыбыз үчүн биз эң кеңири таралган грантты, Авторизациялоо кодексин колдондук. Анын башкалардан айырмасы үч баскычтуу, б.а. кошумча текшерүүдөн өтүп жатат. Биринчиден, колдонуучу авторизацияга уруксат сурайт, токенди - Авторизация кодун алат, андан кийин бул жетон менен саякатка билет менен эле кирүү белгисин сурайт. Бул авторизация скриптинин бардык негизги өз ара аракети тиркеме менен авторизация серверинин ортосундагы багыттоолорго негизделген. Бул грант тууралуу кененирээк окуй аласыз .
OAuth авторизациядан кийин алынган жетүү токендери убактылуу болушу керек жана орточо ар бир 10 мүнөт сайын өзгөрүшү керек деген түшүнүктү карманат. Authorization Code гранты багыттоо аркылуу үч этаптуу текшерүү болуп саналат, ар бир 10 мүнөт сайын мындай кадамды буруш үчүн, ачык айтканда, көз үчүн эң жагымдуу иш эмес. Бул көйгөйдү чечүү үчүн дагы бир грант бар - Refresh Token, аны биз өзүбүздө да колдонгонбуз. Бул жерде баары оңой. Башка гранттан текшерүү учурунда, негизги жетүү токенине кошумча дагы бир - Жаңыртуу Токен чыгарылат, аны бир гана жолу колдонсо болот жана анын иштөө мөөнөтү адатта бир топ узун. Бул Жаңыртуу Токени менен, негизги жетүү токенинин TTL (Жашоо убактысы) аяктаганда, жаңы мүмкүндүк алуу белгисине суроо-талап башка гранттын акыркы чекитине келет. Колдонулган Жаңыртуу Токен дароо нөлгө коюлат. Бул текшерүү эки этаптуу жана колдонуучуга байкалбай, фондо аткарылышы мүмкүн.
3) Ыңгайлаштырылган маалымат чыгаруу форматтарын орнотуңуз
Тандалган гранттар ишке ашырылгандан кийин, авторизация иштери аяктагандан кийин, акыркы колдонуучу жөнүндө маалыматтарды алуу жөнүндө сөз кылуу зарыл. OIDCде бул үчүн өзүнчө акыркы чекит бар, анда сиз учурдагы жетүү белгиси менен колдонуучунун маалыматтарын жана ал жаңыртылгандыгын сурасаңыз болот. Эгер колдонуучунун маалыматтары тез-тез өзгөрбөсө жана сиз учурдагыларды көп жолу ээрчишиңиз керек болсо, сиз JWT токендери сыяктуу чечимге келе аласыз. Бул токендер стандарт тарабынан колдоого алынат. JWT токенинин өзү үч бөлүктөн турат: баш (токен жөнүндө маалымат), пайдалуу жүк (ар кандай зарыл маалыматтар) жана кол (кол, токенге сервер кол койгон жана сиз кийинчерээк анын кол тамгасынын булагын текшере аласыз).
OIDC ишке ашырууда JWT энбелгиси id_token деп аталат. Аны кадимки жетүү белгиси менен бирге сураса болот жана кол тамганы текшерүү гана калды. Авторизация серверинде бул үчүн форматта ачык ачкычтардын тобу бар өзүнчө акыркы чекит бар . Бул жөнүндө сөз кылып жатып, стандартка негизделген дагы бир акыркы чекит бар экенин белгилей кетүү керек OIDC серверинин учурдагы конфигурациясын чагылдырат. Ал бардык акыркы чекит даректерин (кол коюу үчүн колдонулган ачык ачкычтын дарегин кошо алганда), колдоого алынган бренддерди жана чөйрөлөрдү, колдонулган шифрлөө алгоритмдерин, колдоого алынган гранттарды ж.б. камтыйт.
Мисалы, Google'да:
{
"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 Foundation тарабынан тастыкталган ишке ашырууну тандаганыңыз жакшы. Бул чечимдер, адатта, OpenID Тастыктоо төш белгисине ээ.
Эгерде сиз OIDC сервериңизди сактап калгыңыз келбесе, учурдагы акы төлөнүүчү провайдерлер жөнүндө да унутпаңыз. Бүгүнкү күндө көптөгөн жакшы варианттар бар.
кийинкиси эмне
Жакынкы келечекте биз ички кызматтарга трафикти башкача жол менен жапканы жатабыз. Учурдагы SSOбузду OpenResty аркылуу баланстоочуга OAuth негизиндеги проксиге өткөрүүнү пландап жатабыз. Бул жерде көптөгөн даяр чечимдер бар, мисалы:
кошумча материалдар
- JWT токендерин текшерүү үчүн жакшы кызмат
- сертификатталган OIDC ишке ашыруулардын тизмеси
Source: www.habr.com