OpenID

մինի|OpenID-ի տարբերանշանը
**OpenIDб** ապակենտրոնացված նույնականացման համակարգի բաց ստանդարտ, որը թույլ է տալիս օգտատիրոջը ստեղծել մեկ հաշիվ՝ երրորդ կողմի ծառայությունների միջոցով մեկը մյուսի հետ չկապված բազմաթիվ ինտերնետային ռեսուրսներում վավերացման համար:

OpenID-ի հիմնական գործառույթը անվճար և ապակենտրոնացված օգտագործման համար փոխադրելի, հաճախորդի կողմից օգտագործվող թվային ինքնություն տրամադրելն է:

Ստանդարտը նկարագրում է ինտերնետային ռեսուրսների (հավաստի կողմեր) և OpenID մատակարարների (OpenID մատակարարներ) միջև հաղորդակցության գործընթացը: Կան մի քանի OpenID մատակարարներ, որոնք ապահովում են OpenID URL հոսթինգը: Google-ը, Yahoo!-ը, AOL-ը, LiveJournal-ը, MySpace-ը, IBM-ը, Steam և Orange-ը օգտագործվում են OpenID-ի վավերացումը: Ստանդարտի ընդլայնումը (OpenID Attribute Exchange) հեշտացնում է օգտատիրոջ տվյալների, ինչպիսիք են անունը կամ սեռը, փոխանցումը OpenID մատակարարից ինտերնետային ռեսուրսին:

2009 թվականի դեկտեմբերի դրությամբ կար ավելի քան 1 միլիարդ OpenID հաշիվ և մոտ 9 միլիոն կայք, որոնք աջակցում էին OpenID տեխնոլոգիային:

Ստանդարտի ներկայիս տարբերակը՝ OpenID Connect 1.0-ը, թողարկվել է 2014 թվականի փետրվարին և թարմացվել է 2014 թվականի նոյեմբերին:

## Ծագման պատմություն
2005 թվականին Բրեդ Ֆիցպատրիկը, որը հայտնի է որպես LiveJournal-ի ստեղծող, որն այդ ժամանակ աշխատում էր Six Apart-ում, ինտերնետային համայնքին առաջարկել է տարբեր ինտերնետային ռեսուրսների համար մեկ հաշվի գաղափարը: Նա առաջարկել է օգտատիրոջ հաշիվը պահել մեկ սերվերի վրա և օգտագործել այս հաշիվը այլ ինտերնետային ռեսուրսներում գրանցվելիս: Սկզբում արձանագրությունը կոչվում էր Yadis («Եվս մեկ բաշխված վավերացման համակարգ» հապավումը)։ Արձանագրությունը ստացել է OpenID անվանումը, երբ Six Apart-ը գրանցել է openid.net դոմեյնային անունը իրենց նախագծի համար: Շուտով OpenID-ի աջակցությունը ներդրվել է LiveJournal-ում, և այս տեխնոլոգիան արագորեն գրավել է ինտերնետային համայնքի ուշադրությունը;

2006 թվականին ստեղծվել է առաջին OpenID սպեցիֆիկացիան՝ OpenID Authentication 1.1-ը:

2007 թվականի դեկտեմբերի 5-ին Sun Microsystems-ը, VeriSign-ը և OpenID-ի մշակմանը մասնակցող մի շարք ընկերություններ թողարկել են OpenID 2.0 սպեցիֆիկացիան և պաշտոնապես հայտարարելեն, որ չեն առարկի, եթե որևէ մեկը օգտագործի OpenID տեխնոլոգիա, եթե տեխնոլոգիան օգտագործող անձի գործողությունները չեն ուղղված տեխնոլոգիայի ներդրման կամ տեխնոլոգիան օգտագործելու իրավունքի դեմ:

OpenID ապրանքանիշը գրանցվել է 2008 թվականի մարտին Միացյալ Նահանգներում:

## OpenID-ի մուտք՝ վերջնական օգտագործողի տեսանկյունից
Օրինակ՝  `example.com`, կայքում կա մուտքի ձև՝ OpenID նույնականացուցիչի համար մեկ մուտքագրման դաշտով։ Հաճախ նման դաշտի կողքին հայտնվում է OpenID-ի տարբերանշանը: Այս կայք մուտք գործելու համար՝ օգտագործելով ձեր նույնականացուցիչը, օրինակ՝ `pupkin.openid-provider.org`, որը գրանցված է OpenID մատակարար `openid-provider.org`-ում  օգտատերը պետք է մուտքագրի իր նույնականացուցիչը կայքում առաջարկվող մուտքի ձևում: После этого сайт `example.com` կայքը վերահղում է օգտատիրոջը մատակարարի կայք։ Մատակարարի կայքը խնդրում է օգտատիրոջը հաստատել, թե արդյոք օգտատերը իսկապես ցանկանում է տրամադրել իր հաշվի մասին տեղեկություններ։ Եթե օգտատերը համաձայն է, մատակարարի կայքը վերահասցեագրում է օգտատիրոջը դեպի կախյալ կողմի կայք։ Հետ վերահասցեագրվելիս մատակարարը փոխանցում է օգտատիրոջ մասին տեղեկությունները կախյալ կողմին:

Օրինակ, LiveJournal-ը OpenID-ի մատակարար է, այնպես որ կարող եք օգտագործել ձեր LiveJournal օրագրի հասցեն որպես OpenID նույնացուցիչ:

## Արձանագրության ընդհանուր նկարագրություն
### OpenID-ի հնարավորություններ
OpenID-ն թույլ է տալիս օգտատիրոջը օգտագործել մեկ հաշիվ, որը գրանցված է OpenID մատակարարի մոտ մի քանի այլ կայքերում: Օգտատերը կարող է ընտրել, թե ինչ տեղեկատվություն կտրամադրի կայքին: Պրոֆիլային տեղեկատվության կամ OpenID-ի սպեցիֆիկացիայում չնկարագրված այլ տեղեկատվության փոխանակումը կարող է իրականացվել OpenID արձանագրության վերևում՝ օգտագործելով լրացուցիչ ծառայություններ: Այս նպատակով OpenID-ի արձանագրությունը տրամադրում է պաշտոնապես աջակցվող արձանագրության ընդլայնման մեխանիզմ:

Հնարավոր է պատվիրակել OpenID-ին: Սա նշանակում է, որ դոմեյնի անվան սեփականատերը կարող է այն օգտագործել որպես ցանկացած OpenID մատակարարից ստացված առկա OpenID նույնականացուցիչի հոմանիշ (կեղծանուն)։ Դրա համար անհրաժեշտ է մի քանի մետա թեգեր ավելացնել պատվիրակված էջին:

### Ապակենտրոնացում
OpenID-ին ապակենտրոնացված համակարգ է: Սա նշանակում է, որ չկա որևէ կենտրոնական ծառայություն կամ կազմակերպություն, որը թույլատրում է համակարգի օգտագործումը կամ գրանցում է ինտերնետային ռեսուրսներ կամ OpenID մատակարարներ, որոնք պահանջում են OpenID-ի նույնականացում: Վերջնական օգտատերն ազատ է ընտրելու, թե որ OpenID մատակարարն օգտագործի և պահպանում է նույնականացուցիչը, եթե OpenID-ի մատակարարը փոխվի:

### Տեխնոլոգիական պահանջներ
Ստանդարտը չի պահանջում JavaScript կամ ժամանակակից բրաուզերներ, սակայն նույնականացման սխեման լավ համատեղելի է AJAX-ի հետ: Սա նշանակում է, որ վերջնական օգտատերը կարող է նույնականացվել կայքում՝ առանց ընթացիկ էջը լքելու: Այս դեպքում ինտերնետային ռեսուրսը ֆոնային ռեժիմով կապվում է OpenID-ի  հետ: OpenID նույնականացումը օգտագործում է միայն ստանդարտ HTTP(S) հարցումներ և պատասխաններ, ուստի ստանդարտը չի պահանջում օգտատիրոջից լրացուցիչ ծրագրային ապահովում տեղադրել: OpenID-ն չի պահանջում cookie կամ որևէ այլ սեսիայի կառավարման մեխանիզմների օգտագործում: Տարբեր ընդլայնումներ կարող են պարզեցնել OpenID-ի օգտագործումը, բայց պարտադիր չեն ստանդարտն օգտագործելու համար:

## Արձանագրության սարք
### Տերմինաբանություն

* Նույնականացուցիչ (Identifier)`  HTTP կամ HTTPS URI (URL) կամ XRI (սկսած OpenID 2.0-ից): Արձանագրությունն օգտագործում է նույնականացման մի քանի տեսակներ։ 
* Ինտերնետ ծառայություն (Relying Party)` վեբ հավելված, որը ցանկանում է ստուգել օգտվողի ID-ի իսկությունը:
* Փրովայդեր OpenID (OpenID Provider)` OpenID նույնականացման սերվեր, որը ստուգում է վերջնական օգտատիրոջ ID-ի իսկությունը ինտերնետային ծառայության համար։
* OpenID մատակարարի փրովայդեր URL (OpenID Provider Endpoint URL)` URL, URL, որը ընդունում է OpenID նույնականացման հարցումներ և կարող է ստացվել տրամադրված ID-ից
* Մատակարարի փրովայդեր (OP Identifier)` նույնականացուցիչ, որի միջոցով կարելի է նույնականացնել OpenID մատակարարին։
* Ներկայացված նույնականացուցիչ (User-Supplied Identifier)`վերջնական օգտատիրոջ կողմից ինտերնետ ծառայությանը տրամադրված նույնականացուցիչ։ Ներկայացված նույնականացուցիչը կարող է համընկնել OP նույնականացուցչի հետ։
* Հայտարարված նույնականացուցիչ (Claimed Identifier)` նույնականացուցիչ, երբ օգտատերը պնդում է, որ իրեն է պատկանում: Այս հայտարարության ստուգումը OpenID արձանագրության հիմնական նպատակն է: Հայտարարված նույնականացուցիչը կարող է ստացվել ներկայացված նույնականացուցիչից՝ այն նորմալացնելով:

### Գործողության մեխանիզմ
# Վերջնական օգտատերը սկսում է նույնականացման գործընթացը ինտերնետային ծառայությունում՝ կայքում տրամադրված մուտքի ձևաթղթում մուտքագրելով ներկայացված նույնականացուցիչը։
# Ներկայացված նույնականացուցիչից ինտերնետ ծառայությունը որոշում է վերջնական օգտատիրոջ կողմից օգտագործվող OpenID մատակարարի վերջնակետի URL-ը: Ներկայացված նույնականացուցիչը կարող է պարունակել միայն մատակարարի նույնականացուցիչը: Այս դեպքում վերջնական օգտատերը մատակարարի հետ փոխազդելիս նշում է իր հայտարարած նույնականացուցիչը:
# Ըստ ցանկության, ինտերնետ ծառայությունը և OpenID մատակարարը ստեղծում են համատեղ գաղտնի բանալի Դիֆի-Հելլմանի հաղորդագրության նույնականացման կոդի համար: Հաղորդագրության նույնականացման կոդն օգտագործելով՝ ինտերնետ ծառայությունը նույնականացնում է մատակարարից ստացված հաղորդագրությունը՝ առանց մատակարարին նույնականացման լրացուցիչ հարցումների:
# `checkid_setup` ռեժիմում ինտերնետ ծառայությունը վերահղում է օգտատիրոջ բրաուզերը մատակարարի կայք՝ հետագա նույնականացման համար:  `checkid_immediate` ռեժիմում բրաուզերը կապ է հաստատում մատակարարի հետ՝ օգտատիրոջից աննկատ:
# Մատակարարը ստուգում է, թե արդյոք օգտատերը լիազորված է սերվերի վրա և ցանկանում է նույնականացվել ինտերնետային ծառայությունում: OpenID սպեցիֆիկացիան չի նկարագրում օգտատիրոջ նույնականացման գործընթացը մատակարարի կողմից:
# Մատակարարը վերահասցեագրում է օգտատիրոջ բրաուզերը դեպի ինտերնետային ծառայություն՝ նույնականացման արդյունքը փոխանցելով ծառայությանը։
# Ինտերնետային ծառայությունը ստուգում է ինտերնետ մատակարարից ստացված տեղեկատվության իսկությունը, ներառյալ վերադարձված URL-ը, օգտատիրոջ տեղեկությունները, ոչ մի բանալի և հաղորդագրության ստորագրությունը: Եթե 3-րդ քայլում ստեղծվել է համատեղ գաղտնի բանալի, ստուգումը կատարվում է դրա միջոցով: Եթե բանալի չի ստեղծվել, ինտերնետային ծառայությունը լրացուցիչ հարցում (`check_authentication`) է ուղարկում ինտերնետ մատակարարին՝ իսկությունը ստուգելու համար: Առաջին դեպքում ինտերնետային ծառայությունը կոչվում է համր, իսկ երկրորդ դեպքում՝ վստահելի կողմ՝ առանց հիշողության  (*stateless*):
# Եթե ստուգումը հաջող է, ինտերնետային ծառայությունը նույնականացնում է օգտատիրոջը:

## OpenID Foundation
OpenID Foundation (OIDF) առևտրային կազմակերպություն է, որը ստեղծվել է 2007 թվականի հունիսին՝ OpenID համայնքին վերաբերող հեղինակային իրավունքի, ապրանքանիշի, մարքեթինգի և այլ գործունեության կառավարման համար:

Կազմակերպության տնօրենների խորհուրդը բաղկացած է համայնքի 4 անդամից և կորպորատիվ 8 անդամից:

Միացյալ Նահանգներում OpenID Foundation-ը գրանցել է OpenID ապրանքանիշը 2008 թվականի մարտին: Նախկինում այն պատկանում էր NetMesh Inc.-ին: Եվրոպայում OpenID ապրանքանիշը գրանցել է OpenID Europe Foundation-ը 2007 թվականի օգոստոսի 31-ին:.

## Տարբերակների պատմություն
### OpenID 1.1
OpenID-ի վերջնական նույնականացումը օգտատիրոջը հնարավորություն է տալիս ապացուցել իր ինքնությունը կայքում՝ առանց մուտքագրելու իր գաղտնաբառը, էլ. փոստը կամ այլ տեղեկություններ, որոնք նա չի ցանկանում մուտքագրել այդ ռեսուրսում: OpenID 1.1 սպեցիֆիկացիան չի նախատեսում վերջնական օգտատիրոջ պրոֆիլի տեղեկատվության փոխանակման որևէ մեխանիզմ:

### OpenID 2.0
Վերջնական օգտագործողի համար OpenID 2.0-ի և OpenID 1.1-ի միջև հիմնական տարբերությունը XRI-ն որպես նույնականացուցիչ օգտագործելու հնարավորությունն է: OpenID 2.0-ն, ի տարբերություն OpenID 1.1-ի, աջակցում է HMAC-SHA256 ալգորիթմը՝ 256-բիթանոց ( թվային ստորագրություն, որը OpenID հաղորդագրությունների նույնականացումն ավելի անվտանգ է դարձնում: OpenID 2.0-ն ներմուծեց ընդլայնման մեխանիզմ, որը թույլ է տալիս լրացուցիչ տեղեկատվություն ավելացնել նույնականացման հարցումներին և պատասխաններին:

OpenID 2.0-ը համատեղելի է OpenID 1.1-ի հետ:

### OpenID Connect
OpenID տեխնոլոգիայի երրորդ սերունդը, որը OAuth 2.0 լիազորման արձանագրության նույնականացման լրացում է: OpenID Connect-ը թույլ է տալիս ինտերնետային ռեսուրսներին ստուգել օգտատիրոջ ինքնությունը՝ հիմնվելով լիազորման սերվերի կողմից կատարված նույնականացման վրա: Այն օգտագործում է RESTful API-ն, որը նկարագրված է սպեցիֆիկացիայում: OpenID Connect-ը նաև սահմանում է հուսալի կոդավորման և թվային ստորագրության լրացուցիչ մեխանիզմներ: Ստանդարտը թույլ է տալիս օգտագործել լրացուցիչ հնարավորություններ, ինչպիսիք են սեսիայի կառավարումը և OpenID մատակարարների հայտնաբերումը:

Թեև OAuth 1.0a ստանդարտը OpenID 2.0-ի հետ ինտեգրելու համար անհրաժեշտ է ընդլայնում, OpenID Connect-ը արդեն իսկ ինտեգրում է OAuth 2.0-ի հնարավորությունները արձանագրության մեջ:

## Խոցելիություններ
### Ֆիշինգային հարձակումներ
Որոշ հետազոտողներ կարծում են, որ OpenID արձանագրությունը խոցելի է ֆիշինգային հարձակումների համար, երբ մատակարարի փոխարեն հարձակվողները վերջնական օգտատիրոջն ուղղորդում են նմանատիպ դիզայն ունեցող կայք։ Եթե օգտատերը չի նկատում փոխարինումը, նա մուտքագրում է իր նույնականացման տվյալները (մուտք, գաղտնաբառ)։ Արդյունքում, հարձակվողները կարող են ներկայանալ ինտերնետային ռեսուրսներին որպես այս օգտատեր և մուտք գործել այդ ռեսուրսներում պահվող նրա տեղեկատվությանը:

Ֆիշինգային հարձակումներ նույնպես հնարավոր են, երբ OpenID-ի լիազորումը սատարող կայքը կեղծվում է՝ մատակարարից օգտատիրոջ տեղեկությունները ստանալու համար: Օգտագործելով «թաքնված վերահղման» խոցելիությունը՝ հարձակվողները կարող են օգտատիրոջ մոտ պատրանք ստեղծել, որ տեղեկատվությունը պահանջվում է իրական կայքի կողմից:

OpenID-ն չի պարունակում ֆիշինգային հարձակումները կանխելու որևէ մեխանիզմ։ Ֆիշինգային հարձակումների պատասխանատվությունը տեղափոխվում է OpenID մատակարարների վրա:

Ֆիշինգից պաշտպանվելու համար օգտատերերը կարող են օգտագործել լրացուցիչ ծրագրեր, ինչպիսին է Microsoft-ի Identity Selector-ը: Կան նաև լուծումներ, որոնք չեն պահանջում լրացուցիչ ծրագրերի տեղադրում, ինչպիսին է BeamAuth-ը, որն օգտագործում է բրաուզերի էջանիշերը աշխատանքի համար:

### «Մարդը մեջտեղում» հարձակում անպաշտպան կապի վրա
Եթե ​​TLS/SSL-ը չի օգտագործվում օգտատիրոջ և OpenID մատակարարի միջև կապը ապահովելու համար, ապա խոցելիություն է առաջանում նույնականացման վերջին փուլում: Օգտատիրոջը իրենից ինտերնետ ծառայություն վերահղելու համար մատակարարը հատուկ URL է ուղարկում օգտատիրոջը: Խնդիրն այն է, որ յուրաքանչյուր ոք, ով կարող է ստանալ այս URL-ը (օրինակ՝ ոլորված զույգը հոտոտելով), կարող է վերարտադրել այն և մուտք գործել կայք որպես օգտատեր: Որոշ մատակարարներ օգտագործում են միանգամյա կոդ (Nonce) այս հարձակումից պաշտպանվելու համար, որը թույլ է տալիս URL-ը օգտագործել միայն մեկ անգամ: Nonce լուծումը գործում է միայն այն դեպքում, եթե օգտատերը նախ օգտագործում է URL-ը: Այնուամենայնիվ, հարձակվողը, որը լսում է կապի ալիքը և գտնվում է օգտատիրոջ և մատակարարի միջև, կարող է ստանալ URL-ը և անմիջապես ընդհատել օգտատիրոջ TCP կապը, ապա իրականացնել հարձակում: Այսպիսով, միանգամյա կոդերը պաշտպանում են միայն պասիվ հարձակվողներից, բայց չեն կարող կանխել ակտիվ հարձակվողի հարձակումները: TLS / SSL-ի օգտագործումը նույնականացման գործընթացում վերացնում է այս ռիսկը:

### Նույնականացուցիչի վերօգտագործում
Օգտատերը կարող է փոխել իր OpenID մատակարարին՝ այդպիսով ազատելով իր ID-ն նախորդ մատակարարից։ Նոր օգտատերը կարող է վերցնել այս ID-ն և օգտագործել այն նույն կայքերում, ինչ նախորդ օգտատերը։ Սա նոր օգտատիրոջը հասանելիություն կտա այս ID-ի հետ կապված բոլոր տեղեկություններին։ Այս իրավիճակը կարող է առաջանալ պատահաբար. նոր օգտատերը պարտադիր չէ, որ լինի հարձակվող և ցանկանա մուտք գործել նշված տեղեկատվությանը:

OpenID 2.0 սպեցիֆիկացիան խորհուրդ է տալիս օգտագործել ֆրագմենտներ՝ նույնականացուցիչի վերօգտագործման խնդիրը լուծելու համար. նույնականացուցիչին պետք է ավելացվի յուրաքանչյուր օգտատիրոջ համար եզակի ֆրագմենտ:

### Նույնականացման սխալներ
2012 թվականին հետազոտողները հրապարակեցին մի հոդված, որում նկարագրվում էին OpenID-ի երկու խոցելիություններ։ Երկու խոցելիություններն էլ թույլ են տալիս հարձակվողին մուտք գործել զոհի հաշվին:

Առաջին խոցելիությունն օգտագործում է OpenID Attribute Exchange-ը։ Խնդիրն այն է, որ որոշ ինտերնետային ծառայություններ չեն ստուգում Attribute Exchange-ի միջոցով փոխանցված տվյալները։ Եթե Attribute Exchange-ն օգտագործվում է օգտատիրոջ այնպիսի տեղեկություններ փոխանցելու համար, որոնք զգայուն չեն փոխարինման նկատմամբ (օրինակ՝ սեռը), ապա այս խոցելիությունը չի կարող շահագործվել։ Այնուամենայնիվ, Attribute Exchange-ը կարող է օգտագործվել նաև, օրինակ, օգտատիրոջ էլեկտրոնային փոստը փոխանցելու համար։ Հարձակվողը փորձում է նույնականացվել կախյալ կողմի կայքում և պատասխանին ավելացնում է զոհի էլեկտրոնային փոստի մատակարարին։ Եթե կախյալ կողմը չի ստուգում այս տեղեկատվության իսկությունը, հարձակվողը կճանաչվի որպես զոհ։ Այսպիսով, հնարավոր է մուտք գործել ցանկացած գրանցված հաշիվ։ Հետազոտողների զեկույցի համաձայն, շատ հայտնի կայքեր, այդ թվում՝ Yahoo!-ն, ենթարկվել են այս հարձակմանը:

Երկրորդ խոցելիությունը կապված է մատակարարի կողմից թույլ տրված սխալի հետ և նաև թույլ է տալիս մուտք գործել կախյալ կողմի կայքում գտնվող հաշվին։ Մատակարարի պատասխանը պարունակում է openid.ext1.value.email դաշտը, որը կախյալ կողմը մշակում է որպես օգտատիրոջ էլ. փոստի հասցե։ Սակայն, այս դաշտին մատակարարի կողմից ավելացվող տվյալների տեսակը կարող է կառավարվել հարձակվողի կողմից. մատակարարին ուղղված հարցումը պարունակում է type.email դաշտը՝ այս դաշտը նկարագրող սխեմայի հղումով։ Հարձակվողը կարող է type.email-ի հղումը ավելացնել օգտատիրոջ անունը նկարագրող սխեմային։ Եթե հարձակվողը կարող է գրանցվել մատակարարի կայքում alice@example.com անունով, մատակարարը կավելացնի այս անունը openid.ext1.value.email դաշտին, և կախյալ կողմը կենթադրի, որ այս էլ. փոստով հաշիվը պատկանում է հարձակվողին։ Google-ի և Paypal-ի իրականացումները խոցելի են ճանաչվել:

OpenID-ն հրապարակել է երկու խոցելիությունների վերաբերյալ զեկույցներ, և թողարկվել են թարմացումներ դրանք շտկելու համար:

## Ծանոթագրություններ

## Գրականություն
* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

Կատեգորիա:Համակարգային ծրագրեր
Կատեգորիա:Համակարգչային ցանցեր
Կատեգորիա:Համացանց
Կատեգորիա:Նույնականացում
Կատեգորիա:Ոչ առևտրային կազմակերպություններ
Կատեգորիա:Վավերացում
Կատեգորիա:Տեղեկատվական անվտանգություն
Կատեգորիա:Տեղեկատվական տեխնոլոգիաներ
Կատեգորիա:Տերմինաբանություն
Կատեգորիա:Ցանցային հաղորդակարգեր