Запис архітектурного рішення: варіанти автентифікації та авторизації

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

Автентифікація — це процес перевірки особи користувача або системи.
Авторизація — це процес визначення того, до яких ресурсів або дій має доступ автентифікований користувач або система.

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

1. OAuth (Open Authorization)

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

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

OAuth не виконує автентифікацію безпосередньо; він стосується надання доступу. Для автентифікації OAuth часто поєднують з іншими протоколами, як-от OpenID Connect.

2. OpenID Connect (OIDC)

OpenID Connect (OIDC) — це шар ідентифікації, побудований поверх OAuth 2.0, що додає автентифікацію до можливостей авторизації OAuth. По суті, OpenID Connect розширює OAuth, щоб виконувати автентифікацію користувачів, і надає застосункам стандартизований спосіб перевірки особи користувача.

Потік: коли користувач входить за допомогою OpenID Connect, сторонній застосунок запитує токен ідентифікатора (ID token) (на додачу до токена доступу OAuth). Токен ідентифікатора містить інформацію про користувача (таку як ім’я користувача, електронна пошта та інші твердження). Це дозволяє застосунку знати, хто такий користувач і чи він автентифікований.
Приклад: вхід до сервісу на кшталт Slack за допомогою облікового запису Google (Google тут — провайдер OpenID Connect) передбачає автентифікацію через OpenID Connect, тоді як OAuth керує доступом до ваших ресурсів Google.

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

3. SAML (Security Assertion Markup Language)

SAML — це старіший стандарт на основі XML, що використовується для обміну даними автентифікації та авторизації між сторонами, зокрема в сценаріях єдиного входу (Single Sign-On, SSO). Його переважно використовують у корпоративних середовищах, щоб користувачі могли автентифікуватися один раз і отримувати доступ до кількох застосунків, не вводячи облікові дані повторно.

Потік: користувач спершу автентифікується в провайдері ідентифікації (IdP). IdP генерує підписане твердження SAML, що містить ідентичність користувача та пов’язані атрибути. Твердження надсилається провайдерові послуг (SP), який використовує його для авторизації доступу до застосунку.
Приклад: працівник входить до корпоративного порталу (IdP) і автоматично входить до інших систем, як-от електронна пошта, CRM тощо, не вводячи облікові дані повторно. Процес автентифікації ґрунтується на твердженні SAML, надісланому IdP.

SAML зазвичай використовують у корпоративних рішеннях SSO, і він добре працює для вебзастосунків у корпоративних середовищах, але менш зручний для мобільних пристроїв порівняно з OAuth/OIDC.

4. WS-Federation (Web Services Federation)

WS-Federation — ще один протокол, що використовується для єдиного входу (SSO), особливо в корпоративних середовищах на основі Microsoft. Він входить до родини специфікацій WS- (Web Services)* і забезпечує федерацію ідентифікації між різними доменами безпеки (наприклад, між різними організаціями або різними сервісами).

Потік: WS-Federation дозволяє довіреному провайдерові ідентифікації (IdP) автентифікувати користувачів і видавати токени, які провайдер послуг може використовувати для авторизації. Він подібний до SAML, але його часто використовують у сценаріях, що значною мірою спираються на технології Microsoft.
Приклад: користувач входить до корпоративного застосунку, розміщеного в Microsoft Azure Active Directory (AD), і його ідентичність можна використовувати для доступу до інших федеративних сервісів, зокрема застосунків, розміщених у сторонніх постачальників.

Хоча в багатьох сучасних вебсередовищах WS-Federation значною мірою замінили новіші протоколи, такі як OAuth 2.0 і OpenID Connect, його все ще використовують у застарілих системах, особливо в корпораціях, орієнтованих на Microsoft.

5. LDAP (Lightweight Directory Access Protocol)

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

Автентифікація: LDAP дозволяє застосунку автентифікувати користувачів, запитуючи в служби каталогів облікові дані (як-от паролі).
Авторизація: він також керує ролями та дозволами користувачів, допомагаючи визначити, чи має користувач доступ до певних ресурсів.
Приклад: багато підприємств використовують каталоги на основі LDAP (напр., Active Directory) для автентифікації та авторизації, особливо в середовищах Windows.

LDAP має вирішальне значення для підприємств, щоб керувати доступом користувачів до внутрішніх систем, але в сучасному вебконтексті LDAP часто інтегрують з іншими протоколами, як-от SAML чи OAuth, для повнішого керування ідентичністю.

6. Провайдери соціального SSO

Провайдери соціального єдиного входу (SSO), такі як Facebook, Google, Twitter, GitHub та інші, дозволяють користувачам автентифікуватися в сторонніх застосунках за допомогою своїх облікових даних із соціальних мереж. Це різновид автентифікації на основі OAuth, де сторонній сервіс (напр., Google) є провайдером ідентифікації.

Потік: користувач натискає «Увійти через Google» (наприклад). Застосунок перенаправляє на Google, де користувач входить (якщо ще не ввійшов). Потім Google надає стороннєму застосунку токен доступу або токен ідентифікатора, який можна використати для автентифікації користувача та, можливо, доступу до його даних.
Приклад: багато застосунків дозволяють входити за допомогою облікових даних Google чи Facebook. Застосунок використовуватиме OAuth або OpenID Connect за лаштунками, щоб перевірити вашу особу та, в окремих випадках, отримати доступ до певних даних соціальних мереж.

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

Підсумок відмінностей:

OAuth: використовується для авторизації, дозволяє стороннім застосункам отримувати доступ до даних користувача без розкриття облікових даних.
OpenID Connect: розширює OAuth, щоб забезпечити автентифікацію, даючи застосункам змогу перевіряти особу користувача.
SAML: протокол на основі XML, що використовується для SSO, часто в корпоративних середовищах.
WS-Federation: протокол, специфічний для Microsoft, для федерації ідентифікації, що використовується в застарілих системах.
LDAP: протокол для запитів до служб каталогів з метою автентифікації користувачів і керування авторизацією.
Провайдери соціального SSO: системи на основі OAuth (як-от Google, Facebook), що дозволяють стороннім застосункам автентифікувати користувачів за допомогою їхніх облікових даних із соціальних мереж.

Кожна з цих технологій має власні сильні сторони та сценарії використання, і в сучасних застосунках ви можете побачити їхнє поєднання для різних аспектів безпеки (напр., OAuth/OIDC для доступу до API, SAML для корпоративного SSO).