Համար. թարգմանություն.: Այս հանրահռչակ նյութում Okta ընկերությունը պարզ և տեսողական կերպով նկարագրում է OAuth և OIDC (OpenID Connect) սկզբունքները: Այս գիտելիքները օգտակար կլինեն ծրագրավորողների, համակարգի ադմինիստրատորների և նույնիսկ «սովորական օգտվողների» համար, որը հավանական է, որ նաև փոխանակվում են անձնական տվյալներով այլ ծառայությունների հետ:
Ինտերնետի «քարի դարում» տեղեկատվության փոխանակումը ծառայությունների միջև շատ հեշտ էր: Դուք պարզապես տալիս էիք ձեր օնլայն ծառայության օգտահաշիվը մեկ այլ ծառայությանը, որպեսզի նա մուտք գործի ձեր հաշիվ և ստանա անհրաժեշտ տեղեկությունները:
«Ներդվեք ձեր բանկային հաշիվը»: — «Մենք խոստանում ենք, որ գաղտնաբառի ու գումարի հետ ամեն բան կարգին կլինի։ Իրոք, անձամբ խոստանում եմ!» *հի հի*
Ահա! Ոչ ոք երբեք և ոչ մի դեպքում չպետք է օգտատերանից պահանջի կիսվել իր օգտահաշվի և գաղտնաբառի, նրա ողբերգական տվյալներով, մեկ այլ ծառայության հետ: Ոչ մի երաշխիք չկա, որ այս ծառայության հետևում կանգնած կազմակերպությունը անվտանգ պահելու է տվյալները և չի հավաքի ավելին, քան անհրաժեշտ անձնական տեղեկությունները: Սա կարող է թվալ կատաղի, բայց որոշ հավելվածներ դեռևս օգտագործում են նման պրակտիկա:
Այսօր գոյություն ունի միանշանակ ստանդարտ, որը թույլ է տալիս մեկ ծառայությանը անվտանգ օգտվել մեկ այլի տվյալներից: Ցավոք, նման ստանդարտներն օգտագործում են շատ ժարգոն ու տերմիններ, ինչը complicates the understanding. Այս նյութի նպատակն է պարզ պատկերների միջոցով բացատրել, թե ինչպես են դրանք աշխատում (Կարծում եք, որ իմ նկարները հիշեցնում են երեխայի նկարչություն՞: Ինչ էլ լինի։)
Ի դեպ, այս ուղեցույցը միջոցառման տեսաֆորմատում նույնպես հասանելի է:
Տիկնայք և պարոնայք, թվականի ժամանեք: OAuth 2.0
— անվտանգությունն ստանդարտը, որն ընդդեմ մեկ հավելվածի թույլատրում է մուտք դեպի մյուս հավելվածի տեղեկատվություն: Ինքնակողմին սահմանման համար թույլատրող քայլերը [permission] (կամ համաձայնություն [consent]) հաճախ կոչվում է հեղինակացում [authorization] կամ նույնիսկ եղանակի հեղինակացում [delegated authorization]. Այս ստանդարտի միջոցով դուք թույլատրում եք հավելվածի դիտել մյուս հավելվածի տվյալները կամ օգտագործել այն ձեր անունից, առանց գաղտնաբառը փոխանցելու: Հիանալի!
Օրինակ, ենթադրենք, թե դուք գտել եք կայք՝ կոչված «Օրվա աղետալի մանիպուլյացիաներ», [Terrible Pun of the Day] և որոշել եք գրանցվել այնտեղ, որպեսզի ամեն օր ստանաք մանիպուլյացիաներ էգեմ, SMS հաղորդագրություններով: Կայքը ձեզ շատ դուր է եկել, և դուք մի որոշ ժամանակ ուզում եք կիսվել ձեր բոլոր ծանոթներով: Ախր, աղետալի մանիպուլյացիաները բոլորին դուր են գալիս, չէ՞?
«Օրվա աղետալի մանիպուլյացիաներ: Սահմանում եք մարդու, ով կորցրել է ձախ կեսը? Այժմ նա միշտ прав!» (թարգմանությունը մոտավոր է, քանի որ սկզբնական տեքստում այլ խաղ բառադրում է — բն. թ.)
Դա հասկանալի է, որ կապվելու համար բոլորին հաղորդագրություն ուղարկել անթույլատրելի է: Երկու դեպքում էլ, եթե դուք իմ նման եք, հնարավորը ամեն ինչ կանեք, որպեսզի խուսափեք ավելորդ աշխատանքից: Բարեբախտաբար, Terrible Pun of the Day-ն կարող է ինքնուրույն հրավիրել ձեր բոլոր ընկերներին: Դա անել պարզապես անհրաժեշտ է նրան բացել մուտք էլեկտրոնային հասցեների ցուցակից. սայթը ինքնուրույն կուղարկի հրավերներ (OAuth-ն աշխատում է)!
«Սովորաբար բոլորը սիրում են կատակներ! — Դուք արդեն մուտք գործել եք? — Կցանկանա՞ք բացել Terrible Pun of the Day-ի համար մուտքը կոնտակտների ցուցակ: — Շնորհակալություն! Այժմ մենք ձեր բոլոր ծանոթներին ամեն օր կհիշեցնենք հավիտյանս — դուք լավագույն ընկերն եք!»
- Ընտրեք ձեր էլեկտրոնային փոստի ծառայությունը։
- Եթե անհրաժեշտություն առաջանա, այցելեք փոստի կայք ու մուտք գործեք ձեր հաշիվ։
- Տուրքեք Terrible Pun of the Day կայքին ձեր կոնտակտներին մուտք գործելու իրավունք։
- Վերադարձեք Terrible Pun of the Day կայք։
Եթե դուք որոշեք վերադառնալ, OAuth օգտագործող ծրագրերը նաև ապահովում են մուտքային իրավունքները մերժելու տարբերակ: Եթե դուք որոշել եք, որ ցանկանում եք այլևս չկիսվել կոնտակտներով Terrible Pun of the Day-ի հետ, կարող եք գնալ փոստի կայք և հեռացնել կատակների կայքը թույլված ծրագրերի ցուցակից։
OAuth հոսք
Հիմա մենք անցել ենք այն, ինչ սովորաբար կոչվում է հոսք [flow] OAuth: մեր օրինակներում այս հոսքը բաղկացած է տեսանելի քայլերից, ինչպես նաև մի շարք անտեսանելի քայլերից, որոնց ընթացքում երկու ծառայություններ համաձայնության են գալիս անվտանգության մեթոդներով տեղեկատվություն փոխանակելու համար: Տեռիբլ Պուն օֆ դե Դեյ օրինակով օգտագործվում է ամենատարածված OAuth 2.0 հոսքը, որը հայտնի է որպես «հ autorización code» հոսք։ [«authorization code» flow].
Որպեսզի խորանալ OAuth-ի աշխատանքի սկզբունքների մեջ, կանգնենք որոշ տերմինների նշանակության հետ։
- Resource Owner:
Դուք եք: Դուք տիրապետում եք ձեր մուտքային տվյալներին, ձեր տեղեկատվությանը եւ վերահսկում եք այն գործողությունները, որոնք կարող են կատարել ձեր հաշիվների հետ։ - Client:
Ծրագրակը (օրինակ, Terrible Pun of the Day ծառայությունը), որը ուզում է մուտք գործել կամ որոշ գործողություններ կատարել Resource Owner‘ի համար։ - Authorization Server:
Ծրագիրը, որը գիտի Resource Owner‘ի մասին և որի մեջ Resource Owner‘ի համար արդեն հաշիվ կա։ - Resource Server:
Ծրագրային միջնորդ (API) կամ ծառայություն, որը Client ուզում է օգտագործել վերջինիս անունից։ Resource Owner‘ի համար։ - Redirect URI:
Հղումը, որտեղ Authorization Server կողմնորոշում կկատարվի՝ Resource Owner‘ին՝ թույլտվություն տրամադրելուց հետո։ ClientԱյ sometimes կոչվում է «Փ वापस URL» («Callback URL»)։ - Response Type:
Սովորաբար տեղեկությունը, որը սպասում է ստանալ Client. Ամենատարածված Response Type‘մկ՝ սա է կոդը, այսինքն՝ Client սպասվում է ստանալ Authorization Code. - Scope:
Սա մանրամասն նկարագրություն է այն թույլտվություների, որոնք պահանջվում են Client‘ի համար, ինչպես օրինակ տվյալների մուտք կամ որոշ գործողություններ կատարելու համար։ - Consent:
Authorization Server է Scopes, որոնք հարցնում են Client‘ին, արդյոք պատրաստ է այդուհետ տրամադրել Resource Owner‘ին համապատասխան թույլտվություններ։ ClientClient ID - Այս ID-ն օգտագործվում է:
‘ին նույնականացնելու համար Client‘ի վրա։ Authorization ServerClient Secret - Սա գաղտնաբառ է, որը հայտնի է միայն:
‘ին և Clientը և Authorization ServerԱյն թույլ է տալիս նրանց գաղտնիորեն փոխանակել տեղեկություններ։ - Authorization Code:
Թարմ կոդ, որը ունի կարճաժամկետ գործողություն, որը Client տրամադրում ենք Authorization Serverսպասարկում է փոխանակման համար Access Token. - Access Token:
Կիրը, որը հաճախորդը օգտագործելու է կապվելու համար Resource Serverծառայության հետ։ Այդպիսի բեյջ կամ բանալու քարտ, որն ապահովում է Clientհավանություն ծառայությանը տվյալների հարցումներ անել կամ գործողություններ կատարել Resource Serverձեր անունից։
Նշում: երբեմն Համաձայնության Սերվերը և Ռեսուրսի Սերվերը նույն սերվերն են։ Սակայն որոշ դեպքերում դրանք կարող են լինել տարբեր սերվերներ, անգամ միևնույն կազմակերպությանը չպատկանող։ Օրինակ, Համաձայնության Սերվերը կարող է լինել երրորդ կողմի ծառայություն, որին վստահում է Ռեսուրսի Սերվերը։
Այժմ, երբ մենք ծանոթացել ենք OAuth 2.0-ի հիմնական հասկացություններին, եկեք վերադառնանք մեր օրինակին և մանրամասն դիտարկենք, թե ինչ է տեղի ունենում OAuth-ի հոսքում։
- Դուք, Resource Owner, ցանկանում եք Terrible Pun of the Day-ից (Clientծառայությունից) մուտք ունենալ ձեր կոնտակտներին, որպեսզի նա կարողանա ուղարկել հրավերներ բոլոր ձեր ընկերներին։
- Client վերադարձնում է թերթիկը Authorization Serverհայտնի էջին և ներառում է հարցման մեջ Այս ID-ն օգտագործվում է, Redirect URI, Response Type և մեկ կամ մի քանի Scopes (հաստատումներ), որոնց անհրաժեշտ է։
- Authorization Server ստուգում է ձեզ, անհրաժեշտության դեպքում պահանջելով մուտքի անուն և գաղտնաբառ։
- Authorization Server հայտնում է ձև Consent (հաստատման) բոլորի ցանկով, որոնք Scopes, պահանջվում են Clientծառայությունից։ Դուք համաձայնում եք կամ մերժում։
- Authorization Server վերադարձնում է ձեզ կայքում Clientծառայության, օգտագործելով Redirect URI բաժիններով Authorization Code (հեղինակացման կոդով)։
- Client ուղիղ կապվում է Authorization Serverծառայությանը (թեքվելով կայքից Resource Ownerծառայության) և անվտանգ ուղարկում է Այս ID-ն օգտագործվում է, Սա գաղտնաբառ է, որը հայտնի է միայն և Authorization Code.
- Authorization Server ստուգում է տվյալները և պատասխան_with Access Tokenծառայությամբ (մուտքի կոդով)։
- Հիմա Client может օգտագործել Access Token հայտնելու հարցում դեպի Resource Server հնարավորություն ունենալու համար կոնտակտների ցանկը ստանալու։
Client ID և Secret
Հեռավոր չէ, մինչև դուք թույլ տվեք Terrible Pun of the Day-ին մուտք ունենալ ձեր կոնտակտներին, Client-ը և Համաձայնության Սերվերը հաստատել են աշխատանքային հարաբերություններ։ Համաձայնության Սերվերը ստեղծել է Client ID և Client Secret (ամեն անգամ դրանք անվանում են App ID և App Secret) և ուղեգրել է դրանք Client-ին հետագա տարածքում OAuth-ի շրջանակներում։
«Բարև! Ես ուզում եմ աշխատել քեզ հետ! — Այո, իհարկե! Ահա ձեր Client ID և Secret!»
Վ название намекает на то, что Client Secret должен оставаться в секрете, чтобы о нем знали только клиент и сервер авторизации. Именно с его помощью сервер авторизации подтверждает подлинность клиента.
Но это еще не все... Позвольте представить OpenID Connect!
OAuth 2.0 был создан только для դիմումի — մուտք տրամադրել տվյալներին և գործառույթներին մեկից մյուսին։ (OIDC) — это тонкий слой поверх OAuth 2.0, добавляющий сведения о логине и профиле пользователя, который вошел в учетную запись. Организацию логин-сессии часто называют ավտորիզացում [authentication], а информацию о пользователе, вошедшем в систему (դուք), — Resource Ownerանձնական տվյալներ [identity] . Եթե Համաձայնության Սերվերը աջակցում է OIDC-ին, նրան երբեմն անվանում ենանձնական տվյալների մատակարար [identity provider] , քանի որ նա տրամադրում էծառայությանը տեղեկություններ մասին Clientը տեղեկություն մասին Resource OwnerClient Secret
OpenID Connect հնարավորություն է տալիս իրականացնել սցենարներ, երբ մեկ միասնական մուտքը կարելի է օգտագործել բազմաթիվ հավելվածներում, այս մոտեցումը հայտնի է նաև որպես միասնական մուտք (SSO): Օրինակ, հավելվածը կարող է աջակցության ունենալ SSO ինտեգրում սոցիալական ցանցերի, ինչպիսիք են Facebook կամ Twitter, թույլ տալով օգտվողներին օգտվել արդեն իսկ имеющейся և նրանք նախընտրելի հաշվի համար:
OpenID Connect-ի հոսքը (flow) նման է OAuth-ի: Միակ տարբերությունն այն է, որ առաջնային հարցմանը օգտագործվող կոնկրետ scope-ն է openid, — իսկ Client վերջում ստանում է ինչպես Access Token, այնպես էլ ID Token-ը.
Նույնպես, ինչպես OAuth-ի հոսքում, Access Token OpenID Connect-ում — դա որոշակի արժեք է, որի իմաստը պարզ չէ Client‘ի: Գիտակից Client‘ի վրա Access Token представляет собой определённую строку символов, որը փոխանցվում է յուրաքանչյուր հարցման հետ Resource Server‘ի, իսկ նա որոշում է, արդյոք токէն действителен: ID Token-ը представляет собой совершенно другое:
ID Token-ը — դա JWT
ID Token-ը — սա հատուկ ձևաչափով ձևավորված字符串 է, որն հայտնի է որպես JSON Web Token կամ JWT (մեկ մարդիկ սովորաբար անվանում են JWT «ջոթ»). Երրորդ կողմերի դիտորդներին JWT կարող է թվալ անհասկանալի աղմուկ, բայց Client может извлечь из JWT տարբեր տեղեկություններ, ինչպես ID, օգտվողի անուն, մուտքի ժամանակը, ժամկետի անցողունակությունը ID Token-ը‘ի, միջամտության փորձերի առկայությունը JWT-ում: Տվյալները ներսում ID Token-ը‘ի կոչվում են դիմումներ [claims].
OIDC-ի դեպքում նույնպես ունի ստանդարտ եղանակ, որով Client может запросить дополнительную տեղեկություն անձի մասին . Եթե Համաձայնության Սերվերը աջակցում է OIDC-ին, նրան երբեմն անվանում են ից Authorization Server‘ի, օրինակ, էլեկտրոնային փոստի հասցեն, օգտվելով Access Token.
OAuth և OIDC-ի մասին լրացուցիչ տվյալներ
Ուրեմն, մենք կարճ վերանայեցինք OAuth-ի և OIDC-ի աշխատանքի սկզբունքները: Կ готовы深入 изучить? Вот дополнительные ресурсы, которые помогут узнать больше об OAuth 2.0 и OpenID Connect:
Ինչպես միշտ, մի թաքցրեք. Որպեսզի մեր վերջին նորություններից տեղեկացված լինեք, բաժանորդագրվեք և Okta ընկերության կողմից մշակողներին!
P.S. թարգմանչից
Նաեւ կարդացեք մեր բլոգում:
- «»;
- «»;
- «»;
- «».
Ընտանիք: habr.com
