OAuth - OAuth

OAuth логотипі, американдық блогер жасаған Крис Мессина

OAuth болып табылады ашық стандарт қол жеткізу үшін делегация, әдетте Интернет-қолданушыларға веб-сайттарға немесе қолданбаларға басқа веб-сайттардағы ақпараттарға, бірақ оларға пароль бермей-ақ кіруге рұқсат беру тәсілі ретінде қолданылады.[1] Сияқты механизмдерді осы механизмді пайдаланады Amazon,[2] Google, Facebook, Microsoft және Twitter пайдаланушыларға өз шоттары туралы ақпаратты үшінші тарап қосымшаларымен немесе веб-сайттармен бөлісуге рұқсат беру.

Әдетте, OAuth клиенттерге ресурстар иесінің атынан серверлік ресурстарға «қауіпсіз өкілеттікті» ұсынады. Онда ресурстар иелеріне өздерінің серверлік ресурстарына тіркелу деректерін бөліспестен үшінші тараптың кіруіне рұқсат беру процесі көрсетілген. Жұмыс істеу үшін арнайы жасалған Гипермәтінді жіберу хаттамасы (HTTP), OAuth мәні бойынша мүмкіндік береді қол жетондары үшінші тарап клиенттеріне авторизация сервері, ресурстар иесінің мақұлдауымен беріледі. Одан кейін үшінші тарап ресурстар серверінде орналасқан қорғалған ресурстарға қол жеткізу үшін кіру таңбалауышын пайдаланады.[3]

OAuth - бұл бірін-бірі толықтыратын және ерекшеленетін қызмет OpenID. OAuth байланысты емес Ант, бұл а анықтамалық сәулет үшін аутентификация, а стандартты үшін авторизация. Алайда, OAuth тікелей байланысты OpenID Connect (OIDC), өйткені OIDC OAuth 2.0-нің жоғарғы жағында салынған аутентификация қабаты. OAuth сонымен байланысты емес XACML, бұл авторизациялау саясатының стандарты. OAuth-ті XACML-мен бірге қолдануға болады, мұнда OAuth меншік келісімі және рұқсат беру үшін пайдаланылады, ал XACML авторизациялау саясатын анықтау үшін қолданылады (мысалы, менеджерлер өз аймағындағы құжаттарды көре алады).

Тарих

OAuth 2006 жылдың қараша айында басталды Блэйн Кук дамытып отырды Twitter OpenID іске асыру. Сонымен қатар, Ma.gnolia оның OpenID иелері үшін авторизациялауға мүмкіндік беретін шешім қажет болды Бақылау тақтасының виджеттері олардың қызметіне қол жеткізу. Аспазшы, Крис Мессина және магнолиядан келген Ларри Халф кездесті Дэвид Рекордон Twitter мен Магнолиямен OpenID қолдану туралы талқылау API аутентификацияға өкілдік ету. Олар API қатынасу делегациясы үшін ашық стандарттар жоқ деген қорытындыға келді.[4]

OAuth пікірталас тобы 2007 жылдың сәуірінде шағын хаттама жасаушылар тобы үшін ашық хаттамаға ұсыныс жобасын жазу үшін құрылды. Дэвит Клинтон Google OAuth жобасы туралы біліп, күш-жігерді қолдауға қызығушылық білдірді. 2007 жылдың шілдесінде команда бастапқы спецификацияны жасады. Эран Хаммер OAuth-тің көптеген үлестерін біріктіріп, формальды сипаттаманы жасады. 2007 жылдың 4 желтоқсанында OAuth Core 1.0 соңғы жобасы шықты.[5]

73-те Интернет-инженерлік жұмыс тобы (IETF) кездесуі Миннеаполис 2008 жылдың қарашасында OAuth BoF одан әрі стандарттау жұмыстары үшін IETF-ке хаттаманы енгізуді талқылау үшін өткізілді. Іс-шараға көпшілік қатысып, IETF шеңберінде OAuth жұмыс тобын ресми түрде жалдауға кең қолдау болды.

OAuth 1.0 хаттамасы келесідей жарияланды RFC 5849, ақпараттық Пікірлерді сұрау, 2010 жылдың сәуірінде.

2010 жылдың 31 тамызынан бастап барлық үшінші тарап Twitter қосымшаларына OAuth пайдалану қажет болды.[6]

OAuth 2.0 жақтауы келесі түрде жарияланды RFC 6749, және Bearer Token Usage ретінде RFC 6750, стандарттардың екеуі де қадағаланады Түсініктемелерді сұрау, 2012 жылдың қазанында.

OAuth 2.0

OAuth 2.0 OAuth 1.0-мен кері үйлесімді емес. OAuth 2.0 веб-қосымшалар, жұмыс үстелі қосымшалары, ұялы телефондар және үшін арнайы авторизация ағындарын ұсынады ақылды құрылғылар. Техникалық сипаттаманы және байланысты RFC-ді IETF OAuth WG әзірледі;[7] негізгі құрылым 2012 жылдың қазан айында жарияланған.

Facebook Келіңіздер Graph API тек OAuth 2.0 қолдайды.[8] Google OAuth 2.0-ді ұсынылатын авторизациялау механизмі ретінде қолдайды API.[9] Microsoft OAuth 2.0-ді әр түрлі API және оның Azure Active Directory қызметіне қолдайды,[10] бұл көптеген Microsoft және үшінші тарап API интерфейстерін қорғау үшін қолданылады.

OAuth 2.0 Framework[11] және тасымалдаушының таңбалауыштарын пайдалану[12] 2012 жылдың қазанында жарық көрді.

OAuth 2.1 авторизациялау негіздері жобалау сатысында[13].

Қауіпсіздік

OAuth 1.0

2009 жылдың 23 сәуірінде а сессияны бекіту 1.0 хаттамасындағы қауіпсіздік ақаулығы жарияланды. Бұл OAuth Core 1.0 6 бөліміндегі OAuth авторизация ағынына әсер етеді («3-аяқты OAuth» деп те аталады).[14]Осы мәселені шешу үшін OAuth Core хаттамасының 1.0a нұсқасы шығарылды.[15]

OAuth 2.0

2013 жылдың қаңтарында Internet Engineering Task Force OAuth 2.0 үшін қауіп моделін жариялады.[16] Қауіптердің арасында «Ашық бағыттаушы» деген қауіп те бар; 2014 жылдың көктемінде оның нұсқасы Ван Цзиннің «Жасырын бағыттау» атауымен сипатталған.[17][18][19][20]

OAuth 2.0 ресми веб-хаттама талдауы көмегімен талданды. Бұл талдау бірнеше авторизация серверлері бар қондырғыларда, оның біреуі зиянды әрекетте болса, клиенттер авторизация серверін пайдалану туралы түсініксіз болып, құпияларды зиянды авторизация серверіне жібере алатындығын анықтады (AS Mix-Up Attack).[21] Бұл жаңасын жасауға түрткі болды үздік тәжірибе OAuth 2.0 үшін жаңа қауіпсіздік стандартын анықтауға арналған интернет жобасы.[22] AS Mix-Up шабуылына қарсы түзетуді қабылдаған кезде, OAuth 2.0 қауіпсіздігі ресми талдаудың көмегімен шабуылдаушылардың күшті модельдерінде дәлелденді.[21]

OAuth 2.0 бағдарламасының көптеген қауіпсіздік ақаулары бар екендігі анықталды.[23]

2017 жылдың сәуір-мамыр айларында миллионға жуық қолданушы Gmail (2017 жылдың мамырындағы жағдай бойынша пайдаланушылардың 0,1% -дан азы) OAuth-қа негізделген фишингтік шабуылға ұшырады, олар Google Docs құжатымен бөліскісі келетін әріптесінен, жұмыс берушісінен немесе досынан келген электрондық поштаны алды.[24] Электрондық поштадағы сілтемені басқандар жүйеге кіріп, «Google Apps» деп аталатын ықтимал зиянды бөгде бағдарламаның «электрондық пошта тіркелгісіне, контактілеріне және желідегі құжаттарына» кіруіне рұқсат берілді.[24] «Шамамен бір сағат ішінде»,[24] фишингтік шабуылды Google тоқтатты, ол «Google Apps» -ке электрондық поштаға кіруге рұқсат бергендерге мұндай кіруді алып тастауға және парольдерін өзгертуге кеңес берді.

Қолданады

OAuth қауіпсіздікті тұтынудың авторизациясы ретінде қолданыла алады RSS /ATOM арналар. Аутентификацияны қажет ететін RSS / ATOM арналарын пайдалану әрдайым мәселе болып келді. Мысалы, қорғалғаннан RSS легі Google сайты пайдалану арқылы тұтыну мүмкін емес еді Google Reader. Оның орнына үш аяқты OAuth RSS клиентіне Google сайтындағы лентаға кіруге рұқсат беру үшін қолданылған болар еді, оны кез-келген сайтта тіркелгі жасамай кіру құралы және хост хостының барлық артықшылықтары ретінде пайдалануға болады. OAuth жүйесі.

OAuth және басқа стандарттар

OAuth көмегімен псевдоутентификацияға қарсы OpenID

OAuth - бұл авторизация емес, протокол аутентификация хаттама. Аутентификация әдісі ретінде OAuth-ті өздігінен пайдалану псевдо-аутентификация деп аталуы мүмкін.[дәйексөз қажет ] Келесі сызбаларда қолдану арасындағы айырмашылықтар көрсетілген OpenID (аутентификация протоколы ретінде арнайы жасалған) және авторизация үшін OAuth.

Екі процестегі байланыс ағыны ұқсас:

  1. (Суретте жоқ) Пайдаланушы қосымшадан ресурсты немесе сайтқа кіруді сұрайды.
  2. Сайт қолданушының аутентификацияланбағанын көреді. Ол сәйкестендіру провайдеріне арналған сұранысты құрастырады, оны кодтайды және URL мекенжайы аясында пайдаланушыға жібереді.
  3. Пайдаланушының браузері сәйкестендіру провайдері үшін қайта бағыттау URL мекенжайын, оның ішінде қосымшаның сұрауын сұрайды
  4. Қажет болса, сәйкестендіру провайдері пайдаланушының түпнұсқалығын растайды (мүмкін олардан пайдаланушы аты мен паролін сұрау арқылы)
  5. Сәйкестендіру провайдері пайдаланушының жеткілікті аутентификацияланғанына көз жеткізгеннен кейін, ол қолданбаның сұранысын өңдейді, жауабын тұжырымдайды және оны қолданушыға қайта бағыттау URL мекенжайымен бірге қолданбаға жібереді.
  6. Пайдаланушының браузері қолданбаға қайта бағытталатын URL мекенжайын, оның ішінде жеке куәліктің жауабын сұрайды
  7. Бағдарлама сәйкестендіру провайдерінің жауабын декодтайды және сәйкесінше орындайды.
  8. (Тек OAuth) Жауапта қолданушы пайдаланушының атынан сәйкестендіру провайдерінің қызметтеріне тікелей қол жеткізу үшін пайдалана алатын қол жетімділік белгісі бар.

Айырмашылық айырмашылығы - бұл OpenID аутентификация қолдану жағдайы, сәйкестендіру провайдерінің жауабы жеке тұлғаны растау болып табылады; OAuth кезінде авторизация use case, жеке куәліктің провайдері де API провайдер, ал сәйкестендіру провайдерінің жауабы - қолданушы атынан жеке куәліктің провайдерінің кейбір API интерфейстеріне тұрақты қол жетімділікті бере алатын қол жетімділігі. Қатынасу маркері қолданушыға жеке куәлікті жеткізушіге өзінің сұраныстарымен қоса, «валет кілті» ретінде қызмет етеді, ол пайдаланушыдан оған қол жеткізуге рұқсаты бар екенін растайды API.

Сәйкестендіру провайдері әдетте (бірақ әрқашан емес) OAuth қол жетонын беру процесінің бөлігі ретінде пайдаланушының түпнұсқалығын растайтындықтан, сәтті OAuth қол жетонының сұранысын аутентификация әдісі ретінде қарауға азғырады. Алайда, OAuth осы пайдалану жағдайын ескере отырып жасалмағандықтан, бұл болжам қауіпсіздіктің үлкен кемшіліктеріне әкелуі мүмкін.[25]

OAuth көмегімен псевдоутентификацияға қарсы OpenID

OAuth және XACML

XACML саясатқа негізделген, атрибутқа негізделген қатынасты басқару авторизациялау негізі. Онда:

  • Ан кіруді басқару архитектурасы.
  • OAuth арқылы өңделетін / анықталған келісімдерді қолдана алатын саясатты қоса алғанда, кіруді басқару саясатының кең спектрін көрсететін саясат тілі.
  • Авторизация сұрауларын жіберуге және алуға арналған сұраныс / жауап схемасы.

XACML мен OAuth біріктіріліп, авторизациялаудың анағұрлым кешенді тәсілін ұсынады. OAuth қол жетімділікті басқару саясатын анықтайтын саясат тілін бермейді. XACML-ді саясат тілі үшін қолдануға болады.

OAuth өкілдікке қол жеткізуге (мен, қолданушы, Twitter-ге Facebook-тің қабырғасына кіруге рұқсат беремін) және жеке куәлікке негізделген авторизацияға назар аударатын жерде, XACML пайдаланушының, әрекеттің, ресурстардың және атрибуттардың ерекшеліктерін ескере алатын атрибутқа негізделген тәсілді қолданады. контекст (кім, не, қайда, қашан, қалай). XACML көмегімен саясатты анықтауға болады

  • Менеджерлер құжаттарды өз бөлімінде қарай алады
  • Менеджерлер меншіктегі құжаттарды жоба режимінде өңдей алады

XACML OAuth-қа қарағанда қол жетімді басқаруды ұсынады. OAuth түйіршіктілігі бойынша мақсатты қызмет көрсететін өрескел функционалдылықпен (ауқымымен) шектелген. Нәтижесінде, көбінесе OAuth пен XACML-ді біріктіру мағынасы бар, бұл жерде OAuth рұқсат етілген пайдалану жағдайларын және келісімді басқаруды қамтамасыз етеді, ал XACML қосымшаларда, процестерде және деректерде жұмыс істейтін авторизация саясатын ұсынады.

Соңында, XACML бірнеше стектерде мөлдір түрде жұмыс істей алады (API, веб SSO, ESB, үйде өндірілетін қосымшалар, мәліметтер базасы ...). OAuth тек HTTP негізіндегі бағдарламаларға бағытталған.

Даулар

Эран Хаммер OAuth 2.0 жобасының жетекші авторы рөлінен бас тартты IETF жұмыс тобы және оның атын 2012 жылдың шілдесінде спецификациядан алып тастады. Хаммер кету себебі ретінде веб пен кәсіпорын мәдениеттері арасындағы қақтығысты атап, IETF - бұл «кәсіпорынды пайдалану жағдайлары туралы» және «қарапайымға қабілетті емес» қоғамдастық екенін атап өтті. «Қазір ұсынылатыны - авторизациялау хаттамасының жоспары, - деп атап өтті ол, - бұл« консалтингтік қызметтерді және интеграциялық шешімдерді сатудың жаңа шекарасын »ұсына отырып,« бұл кәсіпорын тәсілі ».[26]

OAuth 2.0-ді OAuth 1.0-мен салыстыра отырып, Хаммер оның «күрделенген, өзара әрекеттесу қабілеті төмен, пайдалы емес, толық емес, ең бастысы қауіпсіз емес» болып қалғанын көрсетеді. Ол клиенттерден 2.0 байланыстырылмаған таңбалауыштарының архитектуралық өзгертулерін, протокол деңгейінде барлық қолтаңбалар мен криптографияны қалай алып тастағанын және авторизациялауды өңдеуді қиындата отырып, жарамдылық мерзімі өтіп жатқан жетондарды (токендерді қайтарып алу мүмкін болмады) қалай қосқанын түсіндіреді. Техникалық сипаттамада көптеген заттар анықталмаған немесе шектеусіз қалдырылған, өйткені «осы жұмыс тобының сипаты бойынша, ешқандай мәселе тығырыққа тірелу үшін өте ұсақ емес немесе әр іске асыру шешімі үшін ашық қалмайды».[26]

Дэвид Рекордон кейінірек оның есімін анықталмаған себептермен спецификациядан алып тастады. Дик Хардт редактор рөлін қабылдады, ал рамка 2012 жылдың қазанында жарияланды.[11]

Сондай-ақ қараңыз

Пайдаланылған әдебиеттер

  1. ^ Уитсон, Гордон. «OAuth туралы түсінік: сайтқа Google, Twitter немесе Facebook арқылы кіргенде не болады». Лайфхакер. Мұрағатталды түпнұсқасынан 2014 жылғы 24 сәуірде. Алынған 15 мамыр 2016.
  2. ^ «Amazon & OAuth 2.0». Мұрағатталды түпнұсқадан 2017 жылғы 8 желтоқсанда. Алынған 15 желтоқсан 2017.
  3. ^ «RFC 6749 - OAuth 2.0 авторизациялау негіздері». Мұрағатталды түпнұсқадан 2016 жылғы 14 мамырда. Алынған 15 мамыр 2016.
  4. ^ «Кіріспе». oauth.net. Мұрағатталды түпнұсқадан 2018 жылғы 21 қарашада. Алынған 21 қараша 2018.
  5. ^ «OAuth Core 1.0». 4 желтоқсан 2007. Мұрағатталды түпнұсқадан 2015 жылғы 25 қарашада. Алынған 16 қазан 2014.
  6. ^ Крис Крам (31 тамыз 2010). «Twitter қосымшалары бүгінде жарайды». WebProNews.com. Мұрағатталды түпнұсқадан 2017 жылғы 31 шілдеде. Алынған 31 шілде 2017.
  7. ^ «Веб-авторизациялау хаттамасы (oauth)». Интернет-инженерлік жұмыс тобы. Мұрағатталды түпнұсқадан 2 шілде 2014 ж. Алынған 8 мамыр 2013.
  8. ^ «Аутентификация - Facebook әзірлеушілері». Әзірлеушілерге арналған Facebook. Мұрағатталды түпнұсқасынан 2014 жылғы 23 қаңтарда. Алынған 5 қаңтар 2020.
  9. ^ «OAuth 2.0-ті Google API-ге кіру үшін пайдалану | Google Identity Platform». Google Developers. Мұрағатталды түпнұсқадан 2020 жылғы 4 қаңтарда. Алынған 4 қаңтар 2020.
  10. ^ «v2.0 протоколдары - OAuth 2.0 авторизациялау кодының ағыны». Microsoft Docs. Мұрағатталды түпнұсқадан 2020 жылғы 29 маусымда. Алынған 29 маусым 2020.
  11. ^ а б Хардт, Дик (қазан 2012). «RFC6749 - OAuth 2.0 авторизациялау негіздері». Интернет-инженерлік жұмыс тобы. Мұрағатталды түпнұсқадан 2012 жылғы 15 қазанда. Алынған 10 қазан 2012.
  12. ^ Джонс, Майкл; Хардт, Дик (қазан 2012). «RFC6750 - OAuth 2.0 авторизациялау негіздері: тасымалдаушының таңбалауышын пайдалану». Интернет-инженерлік жұмыс тобы. Мұрағатталды түпнұсқадан 2012 жылғы 15 қазанда. Алынған 10 қазан 2012.
  13. ^ Лодерштедт, Торстен; Хард, Дик; Парекки, Аарон. «OAuth 2.1 авторизациялау негіздері». tools.ietf.org. Алынған 22 қараша 2020.
  14. ^ «OAuth қауіпсіздік кеңесі: 2009.1». oauth.net. 23 сәуір 2009 ж. Мұрағатталды түпнұсқадан 2016 жылғы 27 мамырда. Алынған 23 сәуір 2009.
  15. ^ «OAuth Core 1.0a». oauth.net. Мұрағатталды түпнұсқадан 2009 жылғы 30 маусымда. Алынған 17 шілде 2009.
  16. ^ Лодерштедт, Торстен; Макглойн, Марк; Хант, Фил (қаңтар 2013). «RFC6819 - OAuth 2.0 қауіп моделі және қауіпсіздік мәселелері». Интернет-инженерлік жұмыс тобы. Мұрағатталды түпнұсқадан 2020 жылғы 30 маусымда. Алынған 29 маусым 2020.[rfc: 6819 OAuth 2.0 қауіп моделі және қауіпсіздік мәселелері]. Интернет-инженерлік жұмыс тобы. 2015 жылдың қаңтарында қол жеткізілді.
  17. ^ «OAuth қауіпсіздік кеңесі: 2014.1» жасырын бағыттау"". oauth.net. 4 мамыр 2014. Мұрағатталды түпнұсқадан 2015 жылғы 21 қарашада. Алынған 10 қараша 2014.
  18. ^ «OAuth, OpenID қауіпсіздігінің қателігі анықталды». CNET. 2 мамыр 2014. Мұрағатталды түпнұсқадан 2015 жылғы 2 қарашада. Алынған 10 қараша 2014.
  19. ^ «Математика оқушысы OAuth, OpenID қауіпсіздік осалдығын анықтады». Phys.org. 3 мамыр 2014. Мұрағатталды түпнұсқадан 2015 жылғы 6 қарашада. Алынған 11 қараша 2014.
  20. ^ «Жасырын бағыттау». Тетраф. 1 мамыр 2014. Мұрағатталды түпнұсқадан 2016 жылғы 10 наурызда. Алынған 10 қараша 2014.
  21. ^ а б Фетт, Даниел; Кюстерс, Ральф; Шмитц, Гвидо (2016). «OAuth 2.0 қауіпсіздігін кешенді формальды талдау». 2016 жылғы ACM SIGSAC компьютерлік және коммуникациялық қауіпсіздік конференциясының материалдары - CCS'16. Нью-Йорк, Нью-Йорк, АҚШ: ACM Press: 1204–1215. arXiv:1601.01229. Бибкод:2016arXiv160101229F. дои:10.1145/2976749.2978385. ISBN  9781450341394. S2CID  1723789.
  22. ^ Брэдли, Джон; Лабунеттер, Андрей; Лодерштедт, Торстен; Фетт, Даниэль. «OAuth 2.0 қауіпсіздігі бойынша ең жақсы тәжірибе». Интернет-инженерлік жұмыс тобы. Мұрағатталды түпнұсқадан 2020 жылғы 17 қаңтарда. Алынған 29 шілде 2019.
  23. ^ «Facebook-ті OAuth 2.0 және Chrome көмегімен бұзу». 12 ақпан 2013. Мұрағатталды түпнұсқадан 2016 жылғы 23 сәуірде. Алынған 6 наурыз 2013.
  24. ^ а б c «Google Docs фишингтік электрондық поштасының» құны Миннесотаға 90 000 доллар тұрады'". BBC News. 8 мамыр 2017. Мұрағатталды түпнұсқадан 2020 жылғы 30 маусымда. Алынған 29 маусым 2020.
  25. ^ «OAuth 2.0 көмегімен пайдаланушының түпнұсқалық растамасы». oauth.net. Мұрағатталды түпнұсқадан 2015 жылғы 19 қарашада. Алынған 8 наурыз 2016.
  26. ^ а б Hammer, Eran (28 шілде 2012). «OAuth 2.0 және тозаққа апаратын жол». Hueniverse. Архивтелген түпнұсқа 25 наурыз 2013 ж. Алынған 17 қаңтар 2018.

Сыртқы сілтемелер