OAuth

OAuth що це з точки зору архiтектури – протокол, який дозволяє користувачу надати стороннього застосунку доступ до своїх даних на iншому сервiсi, не розкриваючи при цьому логiн i пароль. Що таке OAuth на практицi, найкраще пояснити через задачу: користувач хоче дозволити сервiсу планування публiкацiй постити вiд його iменi в соцiальнiй мережi. До OAuth єдиним варiантом була передача пароля – що означало повний доступ без будь-яких обмежень. OAuth замiнює пароль на тимчасовий токен з чiтко визначеними правами, який можна вiдкликати в будь-який момент.

Протокол не займається автентифiкацiєю – перевiркою особи користувача. Це зона вiдповiдальностi OpenID Connect, який побудований поверх OAuth 2.0. OAuth вирiшує суто завдання авторизацii: що саме i в яких межах дозволено робити стороннього застосунку. Для розробки мобiльних застосункiв i веб-продуктiв це базовий стандарт, без якого неможлива жодна iнтеграцiя з зовнiшнiми сервiсами.

До появи OAuth стороннi застосунки отримували доступ до даних користувача єдиним способом – через логiн i пароль. Це означало, що застосунок мiг робити з акаунтом що завгодно, а користувач не мав можливостi обмежити або вiдкликати доступ без змiни пароля. OAuth 1.0 з'явився у 2007 роцi i вирiшив цю проблему через механiзм пiдписаних токенiв, однак виявився надто складним для реалiзацii. OAuth 2.0, прийнятий у 2012 роцi, спростив протокол i ввiв концепцiю scope – явного перелiку дозволiв, якi застосунок запитує у користувача.

Сьогоднi OAuth 2.0 пiдтримується Google, Apple, Meta, GitHub, Microsoft i практично будь-яким великим сервiсом з публiчним API. Протокол став де-факто стандартом тому, що вирiшує реальну задачу безпеки без зайвої складностi для кiнцевого користувача. Людина бачить лише дiалог з перелiком дозволiв i кнопку пiдтвердження – все iнше вiдбувається пiд капотом.

OAuth автентифiкацiя у широкому сенсi – це назва всього процесу делегованого входу, хоча технiчно OAuth вiдповiдає лише за авторизацiю. OAuth 2.0 описує чотири ролi, взаємодiя мiж якими i утворює протокол. Resource Owner – користувач, якому належать данi i який надає дозвiл на доступ до них. Client – застосунок, який запитує цей доступ: наприклад, сервiс аналiтики, що хоче читати данi з Google Analytics. Resource Server – сервер, де зберiгаються данi користувача i який перевiряє токени перед тим, як вiдповiсти на запит. Authorization Server – сервер, який автентифiкує користувача, отримує його згоду i видає токени доступу.

На практицi Authorization Server i Resource Server часто є частинами одного сервiсу – наприклад, Google одночасно видає токени i надає доступ до Gmail API. Однак у великих архiтектурах це роздiленi компоненти. Розумiння цих ролей критично важливо при проєктуваннi серверної частини застосунку або при iнтеграцii з будь-яким зовнiшнiм OAuth-провайдером.

OAuth як працює в базовому сценарii – це Authorization Code Flow, найпоширенiший i найбезпечнiший варiант. Застосунок перенаправляє користувача на Authorization Server з параметрами: client_id, redirect_uri, scope i state. Користувач автентифiкується на серверi авторизацii i пiдтверджує запитанi дозволи. Сервер перенаправляє користувача назад на redirect_uri з тимчасовим кодом авторизацii. Застосунок обмiнює цей код на пару токенiв – Access Token i Refresh Token – у прямому запитi мiж серверами, без участi браузера.

Ключовий момент: код авторизацii передається через браузер, але сам Access Token – нiколи. Обмiн вiдбувається server-to-server з використанням client_secret, що унеможливлює перехоплення токена в браузерi. Цей патерн є основою безпечної iнтеграцii через REST API i застосовується скрiзь, де клiєнтська частина не може зберiгати секрети.

Access Token – це короткоживучий токен, який застосунок передає разом iз кожним запитом до Resource Server. Вiн пiдтверджує, що доступ було авторизовано, i визначає його межi через scope. Зазвичай час життя Access Token становить вiд 15 хвилин до кiлькох годин: короткий термiн мiнiмiзує ризики у разi перехоплення. 

Refresh Token – довгоживучий токен, який зберiгається на боцi застосунку i використовується виключно для отримання нового Access Token пiсля закiнчення термiну його дii. Refresh Token нiколи не передається до Resource Server i не включається до звичайних API-запитiв. Якщо користувач вiдкликає доступ, Authorization Server iнвалiдує Refresh Token – i застосунок бiльше не зможе отримати новий Access Token без повторної авторизацii. Цей механiзм забезпечує баланс мiж зручнiстю i безпекою в мобiльних застосунках i SPA.

OAuth 2.0 описує кiлька flow пiд рiзнi сценарii. Authorization Code Flow – для серверних застосункiв i мобiльних клiєнтiв; найбезпечнiший, оскiльки client_secret зберiгається на серверi. Authorization Code Flow з PKCE (Proof Key for Code Exchange) – розширення для публiчних клiєнтiв: SPA i мобiльних застосункiв, де неможливо безпечно зберiгати secret. Client Credentials Flow – для мiжсервiсної взаємодii без участi користувача: наприклад, мiкросервiс запитує данi в iншого мiкросервiсу всерединi Node.js-iнфраструктури.

Implicit Flow, якийранiше використовувався для SPA, сьогоднi вважається застарiлим через вразливостi, пов'язанi з передачею токена через URL. Device Authorization Flow застосовується для пристроїв без браузера – Smart TV, CLI-утилiт. Вибiр правильного flow залежить вiд типу клiєнта, рiвня довiри i того, чи може застосунок безпечно зберiгати секрети.

OAuth приклад, з яким стикався кожен, – кнопки соцiального входу: «Увiйти через Google», «Увiйти через Apple», «Увiйти через GitHub». За кожною з них стоїть OAuth 2.0 у поєднаннi з OpenID Connect. Але застосування протоколу значно ширше. SaaS-платформи використовують OAuth для надання партнерам доступу до даних клiєнтiв без передачi облiкових даних. Корпоративнi системи iнтегруються через OAuth з Active Directory i identity-провайдерами.

У мобiльнiй розробцi OAuth з PKCE є стандартом для нативних застосункiв на iOS i Android. Iнструменти автоматизацii та власнi iнтеграцii мiж CRM, ERP i маркетинговими платформами також будуються на OAuth. Будь-який продукт, що розробляється в рамках веб-розробки i передбачає роботу з зовнiшнiми API, неминуче стикається з OAuth як з базовим шаром авторизацii.

Для користувача OAuth означає контроль: вiн бачить, якi саме дозволи запитує застосунок, i може вiдкликати доступ у будь-який момент через налаштування акаунта – без змiни пароля. Не потрiбно створювати окремий акаунт для кожного нового сервiсу: один провайдер iдентичностi покриває сотнi застосункiв.

Для бiзнесу це зниження вiдповiдальностi за зберiгання паролiв i зменшення ризику витоку даних. Платформи, якi надають OAuth-доступ до свого API, отримують екосистему партнерiв i iнтеграцiй без додаткових витрат на пiдтримку. Для розробникiв OAuth – це готовий, перевiрений стандарт, який пiдтримується бiблiотеками в усiх мовах: вiд Node.js i Python до мобiльних SDK. Реалiзацiя авторизацii з нуля завжди поступається перевiреному протоколу за рiвнем безпеки i надiйностi.