Забелешка. превод.: Оваа одлична статија од Okta објаснува како функционираат OAuth и OIDC (OpenID Connect) на едноставен и јасен начин. Ова знаење ќе биде корисно за програмерите, системските администратори, па дури и за „редовните корисници“ на популарните веб-апликации, кои најверојатно разменуваат и доверливи податоци со други услуги.
Во каменото доба на интернетот, споделувањето информации помеѓу сервисите беше лесно. Едноставно, ги дадовте логинот и лозинката од една на друга услуга, така што тој влезе во вашата сметка и ги доби сите информации што му беа потребни.
„Дајте ми ја вашата банкарска сметка“. „Ветуваме дека се ќе биде во ред со лозинката и парите. Тоа е искрено, искрено!“ *хи хи*
Ужас! Никој никогаш не треба да бара од корисникот да сподели корисничко име и лозинка, ингеренциите, со друга услуга. Не постои гаранција дека организацијата која стои зад оваа услуга ќе ги чува податоците безбедни и нема да собира повеќе лични информации отколку што е потребно. Можеби звучи лудо, но некои апликации сè уште ја користат оваа практика!
Денес постои единствен стандард кој овозможува една услуга безбедно да ги користи податоците на друга. За жал, таквите стандарди користат многу жаргони и термини, што го отежнува нивното разбирање. Целта на овој материјал е да објасни како тие функционираат користејќи едноставни илустрации (Дали мислите дека моите цртежи наликуваат на детско измачкување? О, добро!).
Патем, овој водич е достапен и во видео формат:
Дами и господа, добредојде: OAuth 2.0
е безбедносен стандард кој овозможува една апликација да добие дозвола за пристап до информации во друга апликација. Редоследот на чекори за издавање дозвола [дозвола] (Или согласност [согласност]) често се јавуваат овластување [овластување] или дури делегирано овластување [делегирана овластување]. Со овој стандард, дозволувате апликацијата да чита податоци или да ги користи функциите на друга апликација во ваше име без да и ја дадете вашата лозинка. Класа!
Како пример, да речеме дека откривте страница наречена „Несреќна игра на денот“ [Ужасна игра на зборови на денот] и решил да се регистрира на него за да добива секојдневни игра на зборови во форма на смс пораки на телефон. Навистина ви се допадна страницата и решивте да ја споделите со сите ваши пријатели. На крајот на краиштата, сите сакаат морничави игри на зборови, нели?
„Несреќна игра на зборови на денот: Слушнавте за момчето што ја загуби левата половина од телото? Сега тој е секогаш во право!“ (приближен превод, бидејќи оригиналот има своја игра на зборови - приближно превод.)
Јасно е дека пишувањето на секое лице од списокот со контакти не е опција. А, ако сте дури и малку како мене, тогаш ќе одите на секакви напори за да избегнете непотребна работа. За среќа, Ужасната игра на денот може сама да ги покани сите ваши пријатели! За да го направите ова, само треба да отворите пристап до е-поштата на вашите контакти - самата страница ќе им испраќа покани (правила на OAuth)!
„Сите сакаат игра на зборови! - Веќе сте најавени? „Дали би сакале да дозволите веб-страницата „Грозна игра на денот“ да пристапи до вашата листа на контакти? - Ви благодарам! Отсега, ќе испраќаме потсетници секој ден до сите што ги познавате, до крајот на времето! Ти си најдобар пријател!"
- Изберете ја вашата услуга за е-пошта.
- Доколку е потребно, одете на страницата за пошта и најавете се на вашата сметка.
- Дајте му дозвола на Terrible Pun of the Day да пристапи до вашите контакти.
- Врати се на страницата Страшна игра на денот.
Во случај да се предомислите, апликациите што користат OAuth исто така обезбедуваат начин за отповикување на пристапот. Откако ќе одлучите дека повеќе не сакате да споделувате контакти со Страшната игра на денот, можете да отидете на страницата за пошта и да ја отстраните страницата за игра на зборови од списокот со овластени апликации.
Проток на OAuth
Само што поминавме низ она што обично се нарекува проток [тек] OAuth. Во нашиот пример, овој тек се состои од видливи чекори, како и неколку невидливи чекори, во кои две служби се согласуваат за сигурна размена на информации. Претходниот пример за ужасна игра на денот го користи најчестиот тек на OAuth 2.0, познат како проток на „код за овластување“. [протек на „шифра за авторизација“].
Пред да нурнеме во деталите за тоа како функционира OAuth, ајде да зборуваме за значењето на некои термини:
- Сопственик на ресурси:
Тоа си ти! Вие ги поседувате вашите ингеренции, вашите податоци и ги контролирате сите активности што може да се вршат на вашите сметки. - клиентот:
Апликација (на пример, услугата Terrible Pun of the Day) која сака да пристапи или да изврши одредени дејства во име на Сопственик на ресурси'а. - Сервер за авторизација:
Апликацијата што знае Сопственик на ресурси'а и во која у Сопственик на ресурси„Веќе имам сметка. - сервер за ресурси:
Апликациски програмски интерфејс (API) или услуга која клиентот сака да користи во име Сопственик на ресурси'а. - Пренасочи URI:
Врската што Сервер за авторизација ќе се пренасочи Сопственик на ресурси„и по давање дозвола клиентотна. Понекогаш се нарекува „URL на повратен повик“. - Тип на одговор:
Видот на информациите што се очекува да бидат примени клиентот. Најчести Тип на одговор„Ом е кодот, т.е клиентот очекува да добие Код за овластување. - Опсегот:
Ова е детален опис на дозволите што се потребни клиентот'y, како што се пристап до податоци или извршување одредени дејства. - Согласност:
Сервер за авторизација зема Дометпобарано клиентот„Ом, и прашува Сопственик на ресурси„а, дали е подготвен да обезбеди клиентот„Имајте соодветни дозволи. - ID на клиент:
Овој проект се користи за идентификација клиентотна Сервер за авторизацијад. - Тајна на клиентот:
Ова е лозинката што е само позната клиентот„ти и Сервер за авторизацијана. Тоа им овозможува да споделуваат информации приватно. - Код за овластување:
Привремен код со краток период на важност, кој клиентот обезбедува Сервер за авторизацијаВо замена за Пристап до знакот. - Пристап до знакот:
Клучот со кој клиентот ќе комуницира сервер за ресурсиом. Еден вид значка или клучна картичка што обезбедува клиентот„Имате дозвола да барате податоци или да извршите дејствија на сервер за ресурсиво ваше име.
Имајте на ум: Понекогаш серверот за авторизација и серверот за ресурси се ист сервер. Меѓутоа, во некои случаи, ова може да се различни сервери, дури и ако не припаѓаат на истата организација. На пример, серверот за овластување може да биде услуга од трета страна на која му верува серверот за ресурси.
Сега кога ги опфативме основните концепти на OAuth 2.0, да се вратиме на нашиот пример и да погледнеме подетално што се случува во протокот на OAuth.
- Ти, Сопственик на ресурси, сакате да ја обезбедите услугата Страшна игра на денот (клиентотy) пристап до вашите контакти за да можат да испраќаат покани до сите ваши пријатели.
- клиентот го пренасочува прелистувачот на страницата Сервер за авторизација'а и вклучи во барањето ID на клиент, Пренасочи URI, Тип на одговор и еден или повеќе Домет (дозволи) што му треба.
- Сервер за авторизација ве проверува, барајќи корисничко име и лозинка доколку е потребно.
- Сервер за авторизација прикажува форма Согласност (потврди) со список на сите Дометпобарано клиентотом. Се согласувате или одбивате.
- Сервер за авторизација ве пренасочува на страницата клиентот„а, користејќи Пренасочи URI заедно со Код за овластување (шифра за авторизација).
- клиентот директно комуницира со Сервер за авторизацијаОм (заобиколувајќи го прелистувачот Сопственик на ресурси'а) и безбедно испраќа ID на клиент, Тајна на клиентот и Код за овластување.
- Сервер за авторизација ги проверува податоците и одговара со Пристап до знакотом (токен за пристап).
- сега клиентот може да користи Пристап до знакот да испрати барање до сервер за ресурси за да добиете листа на контакти.
Идентификација на клиентот и тајна
Долго пред да дозволите Страшната игра на денот да пристапи до вашите контакти, клиентот и серверот за овластување воспоставија работен однос. Серверот за овластување ги генерирал ИД на клиентот и Тајната на клиентот (понекогаш се нарекуваат ИД на апликацијата и Тајната на апликацијата) и ги испрати до клиентот за понатамошна интеракција во рамките на OAuth.
"- Здраво! Би сакал да работам со тебе! - Секако, не е проблем! Еве го вашиот клиент ID и тајна!“
Името имплицира дека Тајната на клиентот мора да се чува во тајност, така што само клиентот и серверот за овластување го знаат тоа. На крајот на краиштата, со негова помош серверот за овластување ја потврдува вистината на Клиентот.
Но, тоа не е се... Ве молиме добредојде OpenID Connect!
OAuth 2.0 е дизајниран само за овластување - да обезбеди пристап до податоци и функции од една до друга апликација. (OIDC) е тенок слој на врвот на OAuth 2.0 кој ги додава деталите за најавување и профилот на корисникот кој е пријавен на сметката. Организацијата на сесија за најавување често се нарекува автентикација [автентикација], и информации за корисникот најавен во системот (т.е. за Сопственик на ресурсид), - лични податоци [идентитет]. Ако серверот за авторизација поддржува OIDC, тој понекогаш се нарекува давател на лични податоци [давател на идентитет]бидејќи обезбедува клиентот„Имате информации за Сопственик на ресурсид.
OpenID Connect ви овозможува да имплементирате сценарија каде што едно најавување може да се користи во повеќе апликации - овој пристап е познат и како единствено најавување (ДЗС). На пример, апликацијата може да поддржува интеграција на ДЗС со социјалните мрежи како што се Facebook или Twitter, дозволувајќи им на корисниците да користат сметка што веќе ја имаат и претпочитаат да ја користат.
Протокот (протокот) OpenID Connect изгледа исто како и во случајот со OAuth. Единствената разлика е во тоа што во примарното барање, специфичниот опсег што се користи е openid, - А клиентот на крајот добива како Пристап до знакотИ ИД токен.
Исто како во протокот на OAuth, Пристап до знакот во OpenID Connect, ова е одредена вредност што не е јасна клиентотна. Од гледна точка клиентот'А Пристап до знакот претставува низа од знаци кои се пренесуваат заедно со секое барање до сервер за ресурси'y, што одредува дали токенот е валиден. ИД токен претставува сосема друга работа.
ID Token е JWT
ИД токен е специјално форматирана низа од знаци познати како JSON Web Token или JWT (понекогаш токените JWT се изговараат како „jots“). На надворешните набљудувачи, JWT може да изгледа како неразбирливо глупост, но клиентот може да извлече различни информации од JWT, како што се ID, корисничко име, време за најава, датум на истекување ИД токен„а, присуство на обиди за мешање во JWT. Податоци внатре ИД токен„а се нарекуваат апликации [побарувања].
Во случајот со OIDC, постои и стандарден начин на кој клиентот може да побара дополнителни информации за поединецот [идентитет] од Сервер за авторизација„А, на пример, е-пошта со користење Пристап до знакот.
Дознајте повеќе за OAuth и OIDC
Значи, накратко разгледавме како функционираат OAuth и OIDC. Подготвени да копате подлабоко? Еве дополнителни ресурси кои ќе ви помогнат да дознаете повеќе за OAuth 2.0 и OpenID Connect:
Како и секогаш, слободно коментирајте. За да бидете во тек со нашите најнови вести, претплатете се на и Okta за програмери!
PS од преведувач
Прочитајте и на нашиот блог:
- «";
- «";
- «";
- «".
Извор: www.habr.com