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

Аутентификация и авторизация веб-приложений — две важнейшие концепции защиты доступа к приложениям и сервисам. Обе связаны с идентичностью пользователей и тем, как предоставляются разрешения, но сосредоточены на разных аспектах:

Аутентификация — процесс проверки идентичности пользователя или системы.
Авторизация — процесс определения того, к каким ресурсам или действиям может получить доступ аутентифицированный пользователь или система.

А теперь перейдём к конкретным протоколам и технологиям, которые вы упомянули и которые обычно используются в современных веб-приложениях для управления аутентификацией и авторизацией.

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, используемый для обмена данными аутентификации и авторизации между сторонами, особенно в сценариях единого входа (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).