1. Аутентифікація по паролю
2. HTTP authentication
3. Forms authentication
4. Інші протоколи аутентифікації по паролю
5. Поширені уразливості і помилки реалізації
6. Аутентифікація за сертифікатами
7. Аутентифікація за одноразовими паролями
8. Аутентифікація по ключам доступу
9. Аутентифікація по токені
10. формати токенов
11. стандарт SAML
12. Стандарти WS-Trust і WS-Federation
13. Стандарти OAuth і OpenID Connect
14. Висновок

Я розповім про застосування різних способів аутентифікації для веб-додатків, включаючи аутентифікацію за паролем, за сертифікатами, за одноразовими паролями, по ключам доступу і по токені. Торкнуся технології єдиного входу (Single Sign-On), розгляну різні стандарти і протоколи аутентифікації.

Перед тим, як перейти до технічних деталей, давайте трохи освіжимо термінологію.

• Ідентифікація - це заява про те, ким ви є. Залежно від ситуації, це може бути ім'я, адреса електронної пошти, номер облікового запису, ітд.
• Аутентифікація - надання доказів, що ви насправді є той, ким ідентифікувалися (від слова "authentic" - істинний, справжній).
• Авторизація - перевірка, що вам дозволено доступ до запитуваного ресурсу.

Наприклад, при спробі потрапити в закритий клуб вас ідентифікують (запитають ваше ім'я і прізвище), аутентифицируют (попросять показати паспорт і звірять фотографію) і авторизують (перевірять, що прізвище знаходиться в списку гостей), перш ніж пустять усередину.

Аналогічно ці терміни вживаються в комп'ютерних системах, де традиційно під ідентифікацією розуміють отримання вашого профілю (identity) по username або email; під аутентифікацією - перевірку, що ви знаєте пароль від цього облікового запису, а під авторизацією - перевірку вашої ролі в системі і рішення про надання доступу до запитаної сторінці або ресурсу.

Однак в сучасних системах існують і більш складні схеми аутентифікації і авторизації, про які я розповім далі. Але почнемо з простого і зрозумілого.

Аутентифікація по паролю

Цей метод грунтується на тому, що користувач повинен надати username і password для успішної ідентифікації і аутентифікації в системі. Пара username / password задається користувачем при його реєстрації в системі, при цьому в якості username може виступати адреса електронної пошти користувача.

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

HTTP authentication

Цей протокол, описаний в стандартах HTTP 1.0 / 1.1, існує дуже давно і до цих пір активно застосовується в корпоративному середовищі. Стосовно до веб-сайтам працює наступним чином:

1. Сервер, при зверненні неавторизованого клієнта до захищеного ресурсу, відсилає HTTP статус "401 Unauthorized" і додає заголовок "WWW-Authenticate" із зазначенням схеми і параметрів аутентифікації.
2. Браузер, при отриманні такої відповіді, автоматично показує діалог введення username і password. Користувач вводить деталі свого облікового запису.
3. У всіх наступних запитах до цього веб-сайту браузер автоматично додає HTTP заголовок "Authorization", в якому передаються дані користувача для аутентифікації сервером.
4. Сервер аутентифікує користувача за даними з цього заголовка. Рішення про надання доступу (авторизація) проводиться окремо на підставі ролі користувача, ACL або інших даних облікового запису.

Весь процес стандартизований і добре підтримується всіма браузерами і веб-серверами. Існує кілька схем аутентифікації, що відрізняються за рівнем безпеки:

1. Basic - найбільш проста схема, при якій username і password користувача передаються в заголовку Authorization в незашифрованому вигляді (base64-encoded). Однак при використанні HTTPS (HTTP over SSL) протоколу, є відносно безпечною.
   
   Приклад HTTP аутентифікації з використанням Basic схеми.
2. Digest - challenge-response-схема, при якій сервер посилає унікальне значення nonce, а браузер передає MD5 хеш пароля користувача, обчислений з використанням зазначеного nonce. Більш безпечна альтернатівв Basic схеми при незахищених з'єднаннях, але схильна до man-in-the-middle attacks (з заміною схеми на basic). Крім того, використання цієї схеми не дозволяє застосувати сучасні хеш-функції для зберігання паролів користувачів на сервері.
3. NTLM (відома як Windows authentication) - також заснована на challenge-response підході, при якому пароль не передається в чистому вигляді. Ця схема не є стандартом HTTP, але підтримується більшістю браузерів і веб-серверів. Переважно використовується для аутентифікації користувачів Windows Active Directory в веб-додатках. Вразлива до pass-the-hash-атакам.
4. Negotiate - ще одна схема з сімейства Windows authentication, яка дозволяє клієнтові вибрати між NTLM і Kerberos аутентифікації. Kerberos - більш безпечний протокол, заснований на принципі Single Sign-On. Однак він може функціонувати, тільки якщо і клієнт, і сервер знаходяться в зоні intranet і є частиною домену Windows.

Варто відзначити, що при використанні HTTP-аутентифікації у користувача немає стандартної можливості вийти з веб-додатки, крім як закрити всі вікна браузера.

Forms authentication

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

Працює це за наступним принципом: в веб-додаток включається HTML-форма, в яку користувач повинен ввести свої username / password і відправити їх на сервер через HTTP POST для аутентифікації. У разі успіху веб-додаток створює session token, який зазвичай поміщається в browser cookies. При наступних веб-запитах session token автоматично передається на сервер і дозволяє додатком отримати інформацію про поточного користувача для авторизації запиту.

Приклад forms authentication.

Додаток може створити session token двома способами:

1. Як ідентифікатор аутентифицироваться сесії користувача, яка зберігається в пам'яті сервера або в базі даних. Сесія повинна містити всю необхідну інформацію про користувача для можливості авторизації його запитів.
2. Як зашифрований і / або підписаний об'єкт, що містить дані про користувача, а також вказано термін. Цей підхід дозволяє реалізувати stateless-архітектуру сервера, однак вимагає механізму поновлення сесійного токена після закінчення терміну дії. Кілька стандартних форматів таких токенов розглядаються в секції «Аутентифікація по токені».

Необхідно розуміти, що перехоплення session token часто дає аналогічний рівень доступу, що і знання username / password. Тому всі комунікації між клієнтом і сервером у разі forms authentication повинні проводитися тільки по захищеному з'єднанню HTTPS.

Інші протоколи аутентифікації по паролю

Два протоколу, описаних вище, успішно використовуються для аутентифікації користувачів на веб-сайтах. Але при розробці клієнт-серверних додатків з використанням веб-сервісів (наприклад, iOS або Android), поряд з HTTP аутентифікації, часто застосовуються нестандартні протоколи, в яких дані для аутентифікації передаються в інших частинах запиту.

Існує всього декілька місць, де можна передати username і password в HTTP запитах:

1. URL query - вважається небезпечним варіантом, т. К. Рядки URL можуть запам'ятовуватися браузерами, проксі і веб-серверами.
2. Request body - безпечний варіант, але він застосовується лише для запитів, що містять тіло повідомлення (такі як POST, PUT, PATCH).
3. HTTP header-оптимальний варіант, при цьому можуть використовуватися і стандартний заголовок Authorization (наприклад, з Basic-схемою), та інші довільні заголовки.

Поширені уразливості і помилки реалізації

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

Нижче представлений список найбільш часто зустрічаються вразливостей в разі використання аутентифікації по паролю:

• Веб-додаток дозволяє користувачам створювати прості паролі.
• Веб-додаток не захищене від можливості перебору паролів (brute-force attacks).
• Веб-додаток саме генерує і поширює паролі користувачам, однак не вимагає зміни пароля після першого входу (тобто поточний пароль десь записаний).
• Веб-додаток допускає передачу паролів по незахищеному HTTP-з'єднання або в рядку URL.
• Веб-додаток не використовує безпечні хеш-функції для зберігання паролів користувачів.
• Веб-додаток не надає користувачам можливість зміни пароля або не нотифікує користувачів про зміну їх паролів.
• Веб-додаток використовує вразливу функцію відновлення пароля, яку можна використовувати для отримання несанкціонованого доступу до інших облікових записів.
• Веб-додаток не вимагає повторної аутентифікації користувача для важливих дій: зміна пароля, зміни адреси доставки товарів і т. П.
• Веб-додаток створює session tokens таким чином, що вони можуть бути підібрані або передбачені для інших користувачів.
• Веб-додаток допускає передачу session tokens по незахищеному HTTP-з'єднання, або в рядку URL.
• Веб-додаток вразливе для session fixation-атак (т. Е. Не замінює session token при переході анонімної сесії користувача в аутентифицироваться).
• Веб-додаток не встановлює прапори HttpOnly і Secure для browser cookies, що містять session tokens.
• Веб-додаток не знищує сесії користувача після короткого періоду неактивності або не надає функцію виходу з аутентифицироваться сесії.

Аутентифікація за сертифікатами

Сертифікат являє собою набір атрибутів, що ідентифікують власника, підписаний certificate authority (CA). CA виступає в ролі посередника, який гарантує справжність сертифікатів (за аналогією з ФМС, що випускає паспорта). Також сертифікат криптографически пов'язаний з закритим ключем, яких зберігається у власника сертифіката і дозволяє однозначно підтвердити факт володіння сертифікатом.

На стороні клієнта сертифікат разом з закритим ключем можуть зберігатися в операційній системі, в браузері, в файлі, на окремому фізичному пристрої (smart card, USB token). Зазвичай закритий ключ додатково захищений паролем або PIN-кодом.

У веб-додатках традиційно використовують сертифікати стандарту X.509. Аутентифікація за допомогою X.509-сертифіката відбувається в момент з'єднання з сервером і є частиною протоколу SSL / TLS. Цей механізм також добре підтримується браузерами, які дозволяють користувачеві вибрати і застосувати сертифікат, якщо веб-сайт допускає такий спосіб аутентифікації.

Використання сертифікату для аутентифікації.

Під час аутентифікації сервер виконує перевірку сертифіката на підставі наступних правил:

1. Сертифікат повинен бути підписаний довіреною certification authority (перевірка ланцюжка сертифікатів).
2. Сертифікат повинен бути дійсним на поточну дату (перевірка терміну дії).
3. Сертифікат не повинен бути відкликаний відповідним CA (перевірка списків виключення).

Приклад X.509 сертифікату.

Після успішної аутентифікації веб-додаток може виконати авторизацію запиту на підставі таких даних сертифіката, як subject (ім'я власника), issuer (емітент), serial number (серійний номер сертифіката) або thumbprint (відбиток відкритого ключа сертифіката).

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

Аутентифікація за одноразовими паролями

Аутентифікація за одноразовими паролями зазвичай застосовується додатково до аутентифікації по паролів для реалізації two-factor authentication (2FA). У цій концепції користувачеві необхідно надати дані двох типів для входу в систему: щось, що він знає (наприклад, пароль), і щось, чим він володіє (наприклад, пристрій для генерації одноразових паролів). Наявність двох факторів дозволяє в значній мірі збільшити рівень безпеки, що м. Б. затребуване для певних видів веб-додатків.

Інший популярний сценарій використання одноразових паролів - додаткова аутентифікація користувача під час виконання важливих дій: переказ грошей, зміна налаштувань і т. П.

Існують різні джерела для створення одноразових паролів. Найбільш популярні:

1. Апаратні або програмні маркери, які можуть генерувати одноразові паролі на підставі секретного ключа, введеного в них, і поточного часу. Секретні ключі користувачів, які є фактором володіння, також зберігаються на сервері, що дозволяє виконати перевірку введених одноразових паролів. Приклад апаратної реалізацій токенов - RSA SecurID ; програмної - додаток Google Authenticator .
2. Випадково генеруються коди, що передаються користувачеві через SMS або інший канал зв'язку. У цій ситуації фактор володіння - телефон користувача (точніше - SIM-карта, прив'язана до певного номера).
3. Роздруківка або scratch card зі списком заздалегідь сформованих одноразових паролів. Для кожного нового входу в систему потрібно ввести новий одноразовий пароль з зазначеним номером.

Апаратний токен RSA SecurID генерує новий код кожні 30 секунд.

У веб-додатках такий механізм аутентифікації часто реалізується за допомогою розширення forms authentication: після первинної аутентифікації по паролю, створюється сесія користувача, проте в контексті цієї сесії користувач не має доступу до додатка до тих пір, поки він не виконає додаткову аутентифікацію за одноразовим паролем.

Аутентифікація по ключам доступу

Цей спосіб найчастіше використовується для аутентифікації пристроїв, сервісів або інших додатків при зверненні до веб-сервісів. Тут в якості секрету застосовуються ключі доступу (access key, API key) - довгі унікальні рядки, що містять довільний набір символів, по суті замінюють собою комбінацію username / password.

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

Хороший приклад застосування аутентифікації по ключу - хмара Amazon Web Services. Припустимо, у користувача є веб-додаток, що дозволяє завантажувати і переглядати фотографії, і він хоче використовувати сервіс Amazon S3 для зберігання файлів. В такому випадку, користувач через консоль AWS може створити ключ, що має обмежений доступ до хмари: тільки читання / запис його файлів в Amazon S3. Цей ключ в результаті можна застосувати для аутентифікації веб-додатки в хмарі AWS.

Приклад застосування аутентифікації по ключу.

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

З технічної точки зору, тут не існує єдиного протоколу: ключі можуть передаватися в різних частинах HTTP-запиту: URL query, request body або HTTP header. Як і в випадку аутентифікації по паролю, найбільш оптимальний варіант - використання HTTP header. У деяких випадках використовують HTTP-схему Bearer для передачі токена в заголовку (Authorization: Bearer [token]). Щоб уникнути перехоплення ключів, з'єднання з сервером має бути обов'язково захищене протоколом SSL / TLS.

Приклад аутентифікації по ключу доступу, переданого в HTTP заголовку.

Крім того, існують більш складні схеми аутентифікації по ключам для незахищених з'єднань. В цьому випадку, ключ зазвичай складається з двох частин: публічної і таємної. Публічна частина використовується для ідентифікації клієнта, а секретна частина дозволяє згенерувати підпис. Наприклад, за аналогією з digest authentication схемою, сервер може послати клієнту унікальне значення nonce або timestamp, а клієнт - повернути хеш або HMAC цього значення, обчислений з використанням секретної частини ключа. Це дозволяє уникнути передачі всього ключа в оригінальному вигляді і захищає від replay attacks.

Аутентифікація по токені

Такий спосіб аутентифікації найчастіше застосовується при побудові розподілених систем Single Sign-On (SSO), де один додаток (service provider або relying party) делегує функцію аутентифікації користувачів іншому додатку (identity provider або authentication service). Типовий приклад цього способу - вхід в додаток через обліковий запис в соціальних мережах. Тут соціальні мережі є сервісами аутентифікації, а додаток довіряє функцію аутентифікації користувачів соціальних мереж.

Реалізація цього способу полягає в тому, що identity provider (IP) надає достовірні відомості про користувача в вигляді токена, а service provider (SP) додаток використовує цей токен для ідентифікації, аутентифікації і авторизації користувача.
На загальному рівні, весь процес виглядає наступним чином:

1. Клієнт аутентифицирующей в identity provider одним із способів, специфічним для нього (пароль, ключ доступу, сертифікат, Kerberos, ітд.).
2. Клієнт просить identity provider надати йому токен для конкретного SP-додатки. Identity provider генерує токен і відправляє його клієнту.
3. Клієнт аутентифицирующей в SP-додатку за допомогою цього токена.

Приклад аутентифікації «активного» клієнта за допомогою токена, переданого за допомогою Bearer схеми.

Процес, описаний вище, відображає механізм аутентифікації активного клієнта, т. Е. Такого, який може виконувати запрограмовану послідовність дій (наприклад, iOS / Android програми). Браузер ж - пасивний клієнт в тому сенсі, що він тільки може відображати сторінки, запитані користувачем. В цьому випадку аутентифікація досягається за допомогою автоматичного перенаправлення браузера між веб-додатками identity provider і service provider.

Приклад аутентифікації «пасивного» клієнта за допомогою перенаправлення запитів.

Існує кілька стандартів, в точності що визначають протокол взаємодії між клієнтами (активними і пасивними) і IP / SP-додатками і формат підтримуваних токенов. Серед найбільш популярних стандартів - OAuth, OpenID Connect, SAML, і WS-Federation. Деяка інформація про ці протоколах - нижче в статті.

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

При аутентифікації за допомогою токена SP-додаток повинен виконати наступні перевірки:

1. Токен був виданий довіреною identity provider додатком (перевірка поля issuer).
2. Токен призначається поточному SP-додатком (перевірка поля audience).
3. Термін дії токена ще не закінчився (перевірка поля expiration date).
4. Токен справжній і не був змінений (перевірка підпису).

У разі успішної перевірки SP-додаток виконує авторизацію запиту на підставі даних про користувача, що містяться в токені.

формати токенов

Існує кілька поширених форматів токенов для веб-додатків:

1. Simple Web Token (SWT) - найбільш простий формат, який представляє собою набір довільних пар ім'я / значення в форматі кодування HTML form. Стандарт визначає кілька зарезервованих імен: Issuer, Audience, ExpiresOn і HMACSHA256. Токен підписується за допомогою симетричного ключа, таким чином обидва IP- і SP-додатки повинні мати цей ключ для можливості створення / перевірки токена.
   Приклад SWT токена (після декодування).
   Issuer = http: // auth. myservice. com & Audience = http: // m yservice. com & ExpiresOn = 1435937883 & UserName = John Smith & UserRole = Admin & HMACSHA256 = KOUQRPSpy64rvT2KnYyQKtFFXUIggnesSpE7ADA4o9w
2. JSON Web Token (JWT) - містить три блоки, між якими ставлять крапку: заголовок, набір полів (claims) і підпис. Перші два блоки представлені в JSON-форматі і додатково закодовані в формат base64. Набір полів містить довільні пари ім'я / значення, до того ж стандарт JWT визначає кілька зарезервованих імен (iss, aud, exp і інші). Підпис може генеруватися за допомогою і симетричних алгоритмів шифрування, і асиметричних. Крім того, існує окремий стандарт, відписувався формат зашифрованого JWT-токена.
   Приклад підписаного JWT токена (після декодування 1 і 2 блоків).
   { «Alg»: «HS256», «typ»: «JWT»}. { «Iss»: «auth. myservice. com »,« aud »:« myservice. com »,« exp »:« 1435937883 »,« userName »:« John Smith »,« userRole »:« Admin »}. S9Zs / 8 / uEGGTVVtLggFTizCsMtwOJnRhjaQ2BMUQhcY
   
3. Security Assertion Markup Language (SAML) - визначає токени (SAML assertions) в XML-форматі, що включає інформацію про емітента, про суб'єкта, необхідні умови для перевірки токена, набір додаткових тверджень (statements) про користувача. Підпис SAML-токенів здійснюється за допомогою асиметричної криптографії. Крім того, на відміну від попередніх форматів, SAML-токени містять механізм для підтвердження володіння токеном, що дозволяє запобігти перехоплення токенов через man-in-the-middle-атаки при використанні незахищених з'єднань.

стандарт SAML

Стандарт Security Assertion Markup Language (SAML) описує способи взаємодії і протоколи між identity provider і service provider для обміну даними аутентифікації і авторизації за допомогою токенів. Спочатку версії 1.0 і 1.1 були випущені в 2002 - 2003 рр., В той час як версія 2.0, значно розширює стандарт і назад несумісна, опублікована в 2005 р

Цей основоположний стандарт - досить складний і підтримує багато різних сценаріїв інтеграції систем. Основні «будівельні блоки» стандарту:

1. Assertions - власний формат SAML токенов в XML форматі.
2. Protocols - набір підтримуваних повідомлень між учасниками, серед яких - запит на створення нового токена, отримання існуючих токенів, вихід із системи (logout), управління ідентифікаторами користувачів, і інші.
3. Bindings - механізми передачі повідомлень через різні транспортні протоколи. Підтримуються такі способи, як HTTP Redirect, HTTP POST, HTTP Artifact (посилання на повідомлення), SAML SOAP, SAML URI (адреса отримання повідомлення) та інші.
4. Profiles - типові сценарії використання стандарту, що визначають набір assertions, protocols і bindings необхідних для їх реалізації, що дозволяє досягти кращої сумісності. Web Browser SSO - один із прикладів таких профілів.

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

Розглянемо короткий приклад використання SAML для сценарію Single Sign-On. Користувач хоче отримати доступ на захищений ресурс сервіс-провайдера (крок № 1 на діаграмі аутентифікації пасивних клієнтів). Т. к. Користувач не був аутентифікований, SP відправляє його на сайт identity provider'а для створення токена (крок № 2). Нижче наведено приклад відповіді SP, де останній використовує SAML HTTP Redirect binding для відправки повідомлення із запитом токена:

У разі такого запиту, identity provider аутентифікує користувача (кроки №3-4), після чого генерує токен. Нижче наведено приклад відповіді IP з використанням HTTP POST binding (крок № 5):

Після того як браузер автоматично відправить цю форму на сайт service provider'а (крок № 6), останній декодує токен і аутентифікує користувача. За результатами успішної авторизації запиту користувач отримує доступ до запитаного ресурсу (крок № 7).

Стандарти WS-Trust і WS-Federation

WS-Trust і WS-Federation входять в групу стандартів WS- *, що описують SOAP / XML-веб сервіси. Ці стандарти розробляються групою компаній, куди входять Microsoft, IBM, VeriSign і інші. Поряд з SAML, ці стандарти досить складні, використовуються переважно в корпоративних сценаріях.

Стандарт WS-Trust описує інтерфейс сервісу авторизації, іменованого Secure Token Service (STS). Цей сервіс працює по протоколу SOAP і підтримує створення, оновлення та анулювання токенов. При цьому стандарт допускає використання токенов різного формату, проте на практиці в основному використовуються SAML-токени.

Стандарт WS-Federation стосується механізмів взаємодії сервісів між компаніями, зокрема, протоколів обміну токенов. При цьому WS-Federation розширює функції та інтерфейс сервісу STS, описаного в стандарті WS-Trust. Серед іншого, стандарт WS-Federation визначає:

• Формат і способи обміну метаданими про сервіси.
• Функцію єдиного виходу з усіх систем (single sign-out).
• Сервіс атрибутів, що надає додаткову інформацію про користувача.
• Сервіс псевдонімів, що дозволяє створювати альтернативні імена користувачів.
• Підтримку пасивних клієнтів (браузерів) за допомогою перенаправлення.

Можна сказати, що WS-Federation дозволяє вирішити ті ж завдання, що і SAML, проте їх підходи і реалізація в деякій мірі відрізняються.

Стандарти OAuth і OpenID Connect

На відміну від SAML і WS-Federation, стандарт OAuth (Open Authorization) не описує протокол аутентифікації користувача. Замість цього він визначає механізм отримання доступу однієї програми до іншого від імені користувача. Однак існують схеми, що дозволяють здійснити аутентифікацію користувача на базі цього стандарту (про це - нижче).

Перша версія стандарту розроблялася в 2007 - 2010 рр., А поточна версія 2.0 опублікована в 2012 р Версія 2.0 значно розширює і в той же час спрощує стандарт, але назад несумісна з версією 1.0. Зараз OAuth 2.0 дуже популярний і використовується повсюдно для надання делегованого доступу і третє-сторонньої аутентифікації користувачів.

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

> Попросити користувача вказати дані свого облікового запису? - поганий варіант.
> Попросити користувача створити ключ доступу? - можливо, але дуже складно.

Якраз цю проблему і дозволяє вирішити стандарт OAuth: він описує, як додаток подорожей (client) може отримати доступ до пошти користувача (resource server) з дозволу користувача (resource owner). У загальному вигляді весь процес складається з декількох кроків:

1. Користувач (resource owner) дає дозвіл додатком (client) на доступ до певного ресурсу у вигляді гранту. Що таке грант, розглянемо трохи нижче.
2. Додаток звертається до сервера авторизації та отримує токен доступу до ресурсу в обмін на свій грант. У нашому прикладі сервер авторизації - Google. При виклику додаток додатково аутентифицирующей за допомогою ключа доступу, виданим йому за попередньою реєстрацією.
3. Додаток використовує цей токен для отримання необхідних даних від сервера ресурсів (в нашому випадку - сервіс Gmail).

Взаємодія компонентів в стандарті OAuth.

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

1. Authorization Code - цей грант користувач може отримати від сервера авторизації після успішної аутентифікації і підтвердження згоди на надання доступу. Такий спосіб найбільш часто використовується в веб-додатках. Процес отримання гранту дуже схожий на механізм аутентифікації пасивних клієнтів в SAML і WS-Federation.
2. Implicit - застосовується, коли у додатки немає можливості безпечно отримати токен від сервера авторизації (наприклад, JavaScript-додаток в браузері). В цьому випадку грант є токен, отриманий від сервера авторизації, а крок № 2 виключається зі сценарію вище.
3. Resource Owner Password Credentials - грант є пару username / password користувача. Може застосовуватися, якщо додаток є «інтерфейсом» для сервера ресурсів (наприклад, додаток - мобільний клієнт для Gmail).
4. Client Credentials - в цьому випадку немає ніякого користувача, а додаток отримує доступ до своїх ресурсів за допомогою власних джерел доступу (виключається крок № 1).

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

1. Найчастіше API сервера ресурсів включає операцію, яка надає інформацію про самому користувача (наприклад, / me в Facebook API). Додаток може виконувати цю операцію кожен раз після отримання токена для ідентифікації клієнта. Такий метод іноді називають псевдо-аутентифікацією.
2. Використовувати стандарт OpenID Connect, розроблений як шар облікових даних поверх OAuth (опублікований в 2014 р). Відповідно до цього стандарту, сервер авторизації надає додатковий identity token на кроці № 2. Цей токен в форматі JWT буде містити набір певних полів (claims) з інформацією про користувача.

Варто зауважити, що OpenID Connect, який замінив попередні версії стандарту OpenID 1.0 і 2.0, також містить набір необов'язкових доповнень для пошуку серверів авторизації, динамічної реєстрації клієнтів і управління сесією користувача.

Висновок

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

спосіб
Основне застосування
протоколи
за паролю

аутентифікація користувачів
HTTP, Forms
за сертифікатами
Аутентифікація користувачів в безпечних додатках; аутентифікація сервісів
SSL / TLS
За одноразовим паролів
Додаткова аутентифікація користувачів (для досягнення two-factor authentication)
Forms
За ключам доступу
Аутентифікація сервісів і додатків
-
за токені
Делегована аутентифікація користувачів; делегована авторизація додатків
SAML, WS-Federation, OAuth, OpenID Connect

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