Введення в OAuth 2

1. Вступ OAuth 2 являє собою фреймворк для авторизації, що дозволяє додаткам здійснювати обмежений доступ...
2. Власник ресурсу: Користувач
3. Сервер ресурсів / авторизації: API
4. Клієнт: Додаток
5. Абстрактне опис протоколу
6. Реєстрація додатки
7. Ідентифікатор клієнта і секрет клієнта
8. Дозвіл на авторизацію
9. Тип дозволу на авторизацію: Код авторизації
10. Крок 1: Посилання з кодом авторизації
11. Крок 2: Користувач авторизує додаток
12. Крок 3: Додаток отримує код авторизації
13. Крок 4: Додаток запитує токен доступу
14. Крок 5: Додаток отримує токен доступу
15. Тип дозволу на авторизацію: Неявний
16. Крок 1: Посилання для неявній авторизації
17. Крок 2: Користувач авторизує додаток
18. Крок 3: Призначений для користувача агент отримує токен доступу з URI перенаправлення
19. Крок 4: Призначений для користувача агент слід по URI перенаправлення
20. Крок 5: Додаток виконує скрипт вилучення токена доступу
21. Крок 6: Токен доступу передається з додатком
22. Тип дозволу на авторизацію: облікові дані власника ресурсу
23. Процес з обліковими даними власника ресурсу
24. Тип дозволу на авторизацію: Облікові дані клієнта
25. Процес з обліковими даними клієнта
26. Приклад використання токена доступу
27. Оновлення токена доступу
28. висновок

Вступ

Наша взаимовыгодная связь https://banwar.org/

OAuth 2 являє собою фреймворк для авторизації, що дозволяє додаткам здійснювати обмежений доступ до призначених для користувача аккаунтів на HTTP сервісах, наприклад, на Facebook, GitHub і DigitalOcean. Він працює за принципом делегування аутентифікації користувача сервісу, на якому знаходиться аккаунт користувача, дозволяючи сторонньому додатку отримувати доступ до аккаунту користувача. OAuth 2 працює в інтернеті, на десктопних і мобільних додатках.

Ця стаття призначена для розробників додатків і надає огляд ролей, типів авторизації і типових сценаріїв використання OAuth 2.

Почнемо з ролей OAuth!

ролі OAuth

OAuth визначає чотири ролі:

• власник ресурсу
• клієнт
• сервер ресурсів
• авторизаційний сервер

Далі ми розглянемо кожну з ролей.

Власник ресурсу: Користувач

Власником ресурсу є користувач, який авторизує додаток для доступу до свого облікового запису. Доступ до програми до призначеного для користувача аккаунту обмежений "областю видимості" (scope) наданих прав авторизації (наприклад, доступ на читання або запис).

Сервер ресурсів / авторизації: API

Сервер ресурсів безпосередньо зберігає захищені дані акаунтів користувачів, а авторизаційний сервер перевіряє справжність інформації, наданої користувачем, а потім створює авторизовані токени для програми, за допомогою яких додаток буде здійснювати доступ до призначених для користувача даних.

З точки зору розробника додатка API сервісу одночасно виконує і роль сервера ресурсів і роль сервера авторизації. Далі ми будемо вважати ці дві ролі однієї, і називати її Сервіс або API.

Клієнт: Додаток

Клієнтом є додаток, яке хоче здійснити доступ до аккаунту користувача. Перед здійсненням доступу додаток повинен бути авторизовано користувачем, а авторизація повинна бути схвалена з боку API.

Абстрактне опис протоколу

Тепер, коли у нас є уявлення про ролі, які використовуються в OAuth, розглянемо діаграму їх взаємодії один з одним.

Розглянемо опис послідовності кроків на цій діаграмі:

1. Додаток запитує у користувача авторизацію на доступ до сервера ресурсів.
2. Якщо користувач авторизує запит, додаток отримує дозвіл на авторизацію (authorization grant).
3. Додаток запитує авторизаційний токен у сервера авторизації (API) шляхом надання інформації про самого себе і дозвіл на авторизацію від користувача.
4. Якщо справжність додатки підтверджена і дозвіл на авторизацію дійсно, сервер авторизації (API) створює токен доступу для програми. Процес авторизації завершений.
5. Додаток запитує ресурс у сервера ресурсів (API), надаючи при цьому токен доступу для аутентифікації.
6. Якщо токен дійсний, сервер ресурсів (API) надає запитуваний ресурс з додатком.

Фактичний порядок кроків описаного процесу може відрізнятися в залежності від використовуваного типу дозволу на авторизацію, але в цілому процес буде виглядати описаним чином. Далі ми розглянемо різні типи дозволів на авторизацію.

Реєстрація додатки

Перед тим, як почати використовувати OAuth в вашому додатку, вам необхідно зареєструвати своє додатки в сервісі. Це робиться шляхом реєстрації в розділі "developer" або "API" сайту сервісу, де вам необхідно надати наступну інформацію (можливо, включаючи деякі деталі про вашому додатку):

• Назва додатка
• сайт додатки
• Redirect URL або callback URL

Redirect URL - це URL, на який сервіс буде перенаправляти користувача після авторизації (або відмови в авторизації) прикладної програми.

Ідентифікатор клієнта і секрет клієнта

Після реєстрації додатки сервіс створить облікові дані клієнта - ідентифікатор клієнта (client ID) і секрет клієнта (client secret). Ідентифікатор клієнта є публічно доступну рядок, яка використовується API сервісу для ідентифікації додатка, а також використовується для створення авторизаційних URL для користувачів. Секрет клієнта використовується для аутентифікації справжності додатки для API сервісу, коли додаток запитує доступ до аккаунту користувача. Секрет клієнта повинен бути відомий тільки з додатком і API.

Дозвіл на авторизацію

В абстрактному описі протоколу вище перші чотири кроки стосуються питань створення дозволу на авторизацію і токена доступу. Тип дозволу на авторизацію залежить від використовуваного додатком методу запиту авторизації, а також від того, які типи дозволу підтримуються з боку API. OAuth 2 визначає чотири різних типи, кожен з яких корисний в певних ситуаціях:

• Код авторизації (Authorization Code): використовується з серверними додатками (server-side applications).
• Неявний (Implicit): використовується мобільними або веб-додатками (додатки, що працюють на пристрої користувача).
• Облікові дані власника ресурсу (Resource Owner Password Credentials): використовуються довіреними додатками, наприклад додатками, які є частиною самого сервісу.
• Облікові дані клієнта (Client Credentials): використовуються при доступі додатки до API.

Далі ми розглянемо ці типи дозволу на авторизацію, приклади їх використання.

Тип дозволу на авторизацію: Код авторизації

Код авторизації є одним з найбільш поширених типів дозволу на авторизацію, оскільки він добре підходить для серверних додатків, де вихідний код програми і секрет клієнта не доступні стороннім. Процес в даному випадку будується на перенаправлення (redirection), що означає, що програма має бути в стані взаємодіяти з призначеним для користувача агентом (user-agent), наприклад, веб-браузером, і отримувати коди авторизації API, перенаправляти через призначений для користувача агент.

Опишемо процес на діаграмі:

Крок 1: Посилання з кодом авторизації

Спочатку користувачеві надається посилання наступного виду:

• https://cloud.digitalocean.com/v1/oauth/authorize?response_type=code&client_id= CLIENT_ID & redirect_uri = CALLBACK_URL & scope = read

Розглянемо компоненти посилання:

• https://cloud.digitalocean.com/v1/oauth/authorize : Вхідні точка API авторизації (API authorization endpoint).
• client_id = CLIENT_ID: ідентифікатор клієнта додатка (за допомогою цього ідентифікатора API розуміє, яке додаток запитує доступ).
• redirect_uri = CALLBACK_URL: URL, на який сервіс перенаправить користувача агент (браузер) після видачі авторизационного коду.
• response_type = code: вказує на те, що додаток запитує доступ за допомогою коду авторизації.
• scope = read: задає рівень доступу додатки (в даному випадку - доступ на читання).

Крок 2: Користувач авторизує додаток

Коли користувач натискає на посилання, він повинен спершу здійснити вхід в систему для підтвердження своєї особи (якщо він, звичайно, ще не залогінені). Після цього сервіс запропонує користувачеві авторизувати або відмовити в авторизації додатком для доступу до аккаунту користувача. Приклад такого діалогу представлений нижче:

На цьому скріншоті екрану авторизації DigitalOcean ми можемо бачити, що додаток "Thedropletbook App" запитує доступ на читання до аккаунту " [email protected] ".

Крок 3: Додаток отримує код авторизації

Якщо користувач вибирає "Авторизувати додаток", сервіс перенаправляє користувача агент (браузер) по URL перенаправлення (redirect URL), який був заданий на етапі реєстрації клієнта (разом з кодом авторизації). Посилання буде виглядати схожим чином (в даному прикладі додаток називається "dropletbook.com"):

• https://dropletbook.com/callback?code= AUTHORIZATION_CODE

Крок 4: Додаток запитує токен доступу

Додаток запитує токен доступу у API шляхом відправки авторизационного коду і аутентификационной інформації (включаючи секрет клієнта) сервісу. Нижче представлений приклад POST-запиту для отримання токена DigitalOcean:

• https://cloud.digitalocean.com/v1/oauth/token?client_id= CLIENT_ID & client_secret = CLIENT_SECRET & grant_type = authorization_code & code = AUTHORIZATION_CODE & redirect_uri = CALLBACK_URL

Крок 5: Додаток отримує токен доступу

Якщо авторизація пройшла успішно, API повертає токен доступу (а також, опціонально, токен для поновлення токена доступу - refresh token). Весь відповідь сервера може виглядати наступним чином:

• { "Access_token": "ACCESS_TOKEN", "token_type": "bearer", "expires_in": 2592000, "refresh_token": "REFRESH_TOKEN", "scope": "read", "uid": 100101, "info": { "name": "Mark E. Mark", "email": "[email protected]"}}

Тепер додаток авторизовано! Воно може використовувати токен для доступу до призначеного для користувача аккаунту через API сервісу з заданими обмеженнями доступу до тих пір, поки не закінчиться термін дії токена або токен не буде відкликано. Якщо був створений токен для поновлення токена доступу, він може бути використаний для отримання нових токенов доступу, коли закінчиться термін дії старого токена.

Тип дозволу на авторизацію: Неявний

Неявний тип дозволу на авторизацію використовується мобільними і веб-додатками (програмами, які працюють в веб-браузері), де конфіденційність секрету клієнта не може бути гарантована. Неявний тип дозволу також заснований на перенаправлення користувача агента, при цьому токен доступу передається призначеному для користувача агенту для подальшої передачі з додатком. Це, в свою чергу, робить токен доступним користувачеві і іншим додаткам на пристрої користувача. Також при цьому типі дозволу на авторизацію не провадиться аутентифікація справжності додатки, а сам процес покладається на URL перенаправлення (зареєстрований раніше в сервісі).

Неявний тип дозволу на авторизацію не підтримує токени поновлення токена доступу (refresh tokens).

Процес виглядає наступним чином: додаток просить користувача авторизувати себе, потім сервер авторизації передає токен доступу до призначеного для користувача агенту, який передає токен з додатком. Далі ми опишемо процес в деталях.

Крок 1: Посилання для неявній авторизації

При неявному типу дозволу на авторизацію користувачеві надається посилання, яка запитує токен у API. Це посилання виглядає майже так само, як посилання для попереднього способу (з кодом авторизації), за винятком того, що запитується токен замість коду (зверніть увагу на response type "token"):

• https://cloud.digitalocean.com/v1/oauth/authorize?response_type=token&client_id= CLIENT_ID & redirect_uri = CALLBACK_URL & scope = read

Крок 2: Користувач авторизує додаток

Коли користувач натискає на посилання, він повинен спершу здійснити вхід в систему для підтвердження своєї особи (якщо він, звичайно, ще не залогінені). Після цього сервіс запропонує користувачеві авторизувати або відмовити в авторизації додатком для доступу до аккаунту користувача. Приклад такого діалогу представлений нижче:

На цьому скріншоті екрану авторизації DigitalOcean ми можемо бачити, що додаток "Thedropletbook App" запитує доступ на читання до аккаунту " [email protected] ".

Крок 3: Призначений для користувача агент отримує токен доступу з URI перенаправлення

Якщо користувач вибирає "Авторизувати додаток", сервіс перенаправляє користувача агент по URI пренправленія додатки і включає в URI фрагмент, що містить токен доступу. Це виглядає приблизно ось так:

• https://dropletbook.com/callback#token= ACCESS_TOKEN

Крок 4: Призначений для користувача агент слід по URI перенаправлення

Призначений для користувача агент слід по URI перенаправлення, зберігаючи при цьому токен доступу.

Крок 5: Додаток виконує скрипт вилучення токена доступу

Додаток повертає веб-сторінку, яка містить скрипт для вилучення токен доступу з повного URI перенаправлення, збереженого призначеним для користувача агентом.

Крок 6: Токен доступу передається з додатком

Призначений для користувача агент запускає скрипт вилучення токена доступу, а потім передає витягнутий токен з додатком.

Тепер додаток авторизовано! Воно може використовувати токен для доступу до призначеного для користувача аккаунту через API сервісу з заданими обмеженнями доступу до тих пір, поки не закінчиться термін дії токена або токен не буде відкликано.

Тип дозволу на авторизацію: облікові дані власника ресурсу

При цьому типі дозволу на авторизацію користувач надає додатком безпосередньо свої авторизовані дані в сервісі (ім'я користувача і пароль). Додаток, в свою чергу, використовує отримані облікові дані користувача для отримання токена доступу від сервісу. Цей тип дозволу на авторизацію повинен використовуватися тільки в тому випадку, коли інші варіанти не доступні. Крім того, цей тип дозволу варто використовувати тільки в разі, коли додаток користується довірою користувача (наприклад, є частиною самого сервісу, або операційної системи користувача).

Процес з обліковими даними власника ресурсу

Після того, як користувач передасть свої облікові дані з додатком, додаток запросить токен доступу у авторизационного сервера. Приклад POST-запиту може виглядати наступним чином:

• https://oauth.example.com/token?grant_type=password&username= USERNAME & password = PASSWORD & client_id = CLIENT_ID

Якщо облікові дані коректні, сервер авторизації поверне токен доступу з додатком. Тепер додаток авторизовано!

Увага: DigitalOcean в даний час не підтримує тип дозволу на авторизацію з використанням облікових даних власника ресурсу, тому посилання вище веде на уявний авторизаційний сервер "oauth.example.com".

Тип дозволу на авторизацію: Облікові дані клієнта

Тип дозволу на авторизацію з використанням облікових даних клієнта дозволяє додатку здійснювати доступ до свого власного аккаунту сервісу. Це може бути корисно, наприклад, коли додаток хоче оновити власну реєстраційну інформацію на сервісі або URI перенаправлення, або ж здійснено доступ до іншої інформації, що зберігається в акаунті додатки на сервісі, через API сервісу.

Процес з обліковими даними клієнта

Додаток запитує токен доступу шляхом відправки своїх облікових даних, ідентифікатора клієнта і секрету клієнта авторизационному серверу. Приклад POST-запиту може виглядати наступним чином:

• https://oauth.example.com/token?grant_type=client_credentials&client_id= CLIENT_ID & client_secret = CLIENT_SECRET

Якщо облікові дані клієнта коректні, авторизаційний сервер поверне токен доступу для програми. Тепер додаток авторизовано для використання власного облікового запису!

Увага: DigitalOcean в даний час не підтримує тип дозволу на авторизацію з використанням облікових даних клієнта, тому посилання вище веде на уявний авторизаційний сервер "oauth.example.com".

Приклад використання токена доступу

Після того, як додаток отримає токен доступу, воно може використовувати цей токен для доступу до призначеного для користувача аккаунту через API сервісу з заданими обмеженнями доступу до тих пір, поки не закінчиться термін дії токена або токен не буде відкликано.

Нижче представлений приклад запиту до API з використанням curl. Зверніть увагу, що він містить токен доступу:

• curl -X POST -H "Authorization: Bearer ACCESS_TOKEN" "https://api.digitalocean.com/v2/ $ OBJECT"

Якщо токен доступу валиден, API обробить отриманий запит. Якщо термін дії токена доступу закінчився або токен є коректним, API поверне помилку "invalid_request".

Оновлення токена доступу

Після закінчення терміну дії токена доступу всі запити до API з його використанням повертатимуть помилку "Invalid Token Error". Якщо при створенні токена доступу був створений і токен для поновлення токена доступу (refresh token), останній може бути використаний для отримання нового токена доступу від авторизационного сервера.

Нижче представлений приклад POST-запиту, що використовує токен для поновлення токена доступу для отримання нового токена доступу:

• https://cloud.digitalocean.com/v1/oauth/token?grant_type=refresh_token&client_id= CLIENT_ID & client_secret = CLIENT_SECRET & refresh_token = REFRESH_TOKEN

висновок

На цьому ми завершуємо наш огляд OAuth 2. Тепер у вас є загальне уявлення про те, як працює OAuth 2, а також про те, коли і як використовувати існуючі типи дозволу на авторизацію.

Якщо ви хочете дізнатися більше про OAuth 2, дотримуйтеся таких статтями: