Понимание IAM, OAuth, OpenID Connect, SAML, SSO и JWT в одной статье

Область управления идентификацией и доступом (IAM) стала более сложной за последние годы. Пышные термины, такие как OAuth, OpenID Connect (OIDC), SAML, SSO и JWT, часто используются, но что они означают? Как они работают вместе? Давайте исследуем эти концепции и фреймворки, чтобы сделать их более понятными и практичными.

Что такое IAM?#

Управление идентификацией и доступом (IAM) - это широкое понятие, включающее управление цифровыми идентичностями и реализацию контроля доступа. Упомянутые ранее фреймворки и протоколы относятся к IAM, каждый из которых решает конкретные задачи в этой области.

По сути, IAM касается:

• Идентичности: Цифровое представление пользователя, услуги или устройства. Идентичность обычно включает атрибуты, такие как имя, электронная почта, роли и т.д., чтобы описать сущность.
• Доступа: Возможность взаимодействовать с ресурсами, выполнять действия или использовать услуги. Доступ определяет, какие действия могут быть выполнены с какими ресурсами.

На диаграмме выше пользователь (идентичность) хочет выполнить GET запрос к API (ресурс). Атрибуты пользователя - имя, электронная почта и роль - описывают идентичность.

Аутентификация против авторизации#

Аутентификация и авторизация часто появляются вместе в обсуждениях IAM. Давайте уточним их определения:

• Аутентификация: Процесс проверки владения идентичностью. Он отвечает на вопрос: "Какой идентичностью ты обладаешь?"
• Авторизация: Процесс определения, какие действия аутентифицированная идентичность может выполнять с ресурсом. Он отвечает на вопрос: "Что ты можешь сделать?"

В предыдущем примере:

• Прежде чем пользователь (идентичность) может выполнить любые действия, он должен завершить процесс аутентификации.
• После аутентификации система должна определить, может ли пользователь выполнить GET запрос (действие) на API (ресурс), то есть завершить процесс авторизации.

---

Имея основополагающие знания, давайте разберем другие аббревиатуры и протоколы.

OAuth#

OAuth 2.0, обычно называемый OAuth, это фреймворк авторизации, который позволяет приложению получать доступ к защищённым ресурсам в другом приложении (как правило, от имени пользователя).

Например, представьте, что у вас есть веб-приложение под названием MyApp, которое хочет получить доступ к Google Drive пользователя. Вместо того чтобы просить пользователя поделиться учётными данными к его Google Drive, MyApp может использовать OAuth 2.0 для запроса разрешения (авторизации) у Google на доступ к Google Drive пользователя.

Вот упрощенная схема, иллюстрирующая поток OAuth:

В этом потоке:

• MyApp — это клиент (идентичность), запрашивающий доступ к Google Drive (ресурс).
• Пользователь (владелец ресурса) предоставляет MyApp разрешение на шестом шаге, завершая процесс авторизации.

Ключевым элементом в OAuth 2.0 является токен доступа, который клиент использует, чтобы продемонстрировать авторизацию пользователя для доступа к ресурсам. Чтобы углубить знания, см. Токен доступа.

OpenID Connect (OIDC)#

OpenID Connect (OIDC) — это уровень аутентификации, построенный поверх OAuth 2.0. Он добавляет функции, специально предназначенные для аутентификации, такие как ID токены и конечная точка UserInfo, что делает его подходящим для аутентификации и авторизации.

Если мы вернёмся к потоку OAuth, добавление OIDC вводит ID токен. Этот токен содержит информацию об аутентифицированном пользователе и позволяет MyApp проверить идентичность пользователя.

Пример сценария: "Войти с Google"#

Давайте сменим примеры. Если MyApp хочет позволить пользователям входить с использованием своих аккаунтов Google, цель смещается на аутентификацию, а не на доступ к ресурсу. В этом случае OIDC более подходит. Вот как выглядит поток OIDC:

Ключевое различие: В дополнение к токену доступа, OIDC предоставляет ID токен, который позволяет MyApp аутентифицировать пользователя без необходимости в дополнительных запросах.

OIDC разделяет определения grant с OAuth 2.0, обеспечивая совместимость и согласованность между двумя фреймворками.

SAML#

Security Assertion Markup Language (SAML) — это XML-основанный фреймворк для обмена данными аутентификации и авторизации между сторонами. SAML, введенный в начале 2000-х годов, был широко принят в корпоративных средах.

Как SAML сравнивается с OIDC?#

SAML и OIDC функционально схожи, но различаются в деталях реализации:

• SAML: Использует XML-основанные утверждения и часто считается более сложным.
• OIDC: Использует JSON и JWT, делая его легче и более дружелюбным для разработчиков.

Современные приложения часто предпочитают OIDC за его простоту и гибкость, но SAML остается распространенным в устаревших системах и корпоративных случаях использования.

Единый вход (SSO)#

Единый вход (SSO) — это схема аутентификации, позволяющая пользователям получить доступ к нескольким приложениям и услугам с помощью одного набора учетных данных. Вместо того чтобы входить в каждое приложение отдельно, пользователь входит один раз и получает доступ ко всем подключенным системам.

Как работает SSO?#

SSO опирается на централизованного поставщика идентификации (IdP) для управления пользовательскими идентичностями. IdP аутентифицирует пользователя и предоставляет услуги, такие как аутентификация и авторизация, подключенным приложениям.

IdP может использовать протоколы, такие как OIDC, OAuth 2.0, SAML или другие, чтобы предоставлять эти услуги. Один IdP может поддерживать несколько протоколов для удовлетворения разнообразных потребностей различных приложений.

Пример SSO на основе OIDC#

Давайте рассмотрим пример SSO на основе OIDC:

В этом потоке пользователь входит в IdP один раз и аутентифицирован во множестве приложений (AppA и AppB).

Корпоративный SSO#

Хотя SSO является широким понятием, вы также можете встретить термин корпоративный SSO, который относится к конкретному типу SSO, разработанному для корпоративных сред (как правило, для сотрудников и партнеров).

Когда клиент запрашивает SSO для вашего приложения, важно уточнить его потребности и используемые протоколы. В большинстве случаев это означает, что для определенных доменов электронной почты они хотят, чтобы ваше приложение перенаправляло пользователей на их IdP (который реализует корпоративный SSO) для аутентификации.

Пример: Добавление корпоративного SSO-поставщика#

Вот упрощенный пример интеграции корпоративного SSO-поставщика (Banana) с вашим приложением (MyApp):

JWT#

JSON Web Token (JWT) — это открытый стандарт, определенный в RFC 7519, который обеспечивает безопасную коммуникацию между двумя сторонами. Это стандартный формат для ID токенов в OIDC и широко используется для токенов доступа в OAuth 2.0.

Вот ключевые характеристики JWT:

• Компактность: JWT - это JSON-объекты, закодированные в компактном формате, что делает их простыми для передачи и хранения.
• Самодостаточность: JWT содержат всю необходимую информацию о пользователе и самом токене.
• Подтвержденность и шифруемость: JWT могут быть подписаны и зашифрованы, чтобы обеспечить целостность данных и конфиденциальность.

Типичный JWT выглядит так:

Этот JWT состоит из трех частей, разделенных точками:

• Заголовок: Содержит метаданные о токене, такие как тип токена и алгоритм подписи.
• Полезная нагрузка: Содержит информацию об идентичности и о самом токене.
• Подпись: Подтверждает целостность токена.

И заголовок, и полезная нагрузка представляют собой закодированные в base64 JSON-объекты. Приведенный выше JWT может быть декодирован следующим образом:

С помощью JWT клиент может декодировать токен и извлечь информацию о пользователе без дополнительных запросов к поставщику идентификации. Чтобы узнать больше о JWT, посетите JSON Web Token (JWT).

Подведение итогов#

В этой статье мы охватили много материала. Давайте резюмируем ключевые моменты с помощью примера:

Представьте, что у вас есть веб-приложение, AppA, которому требуется решение для управления идентификацией и доступом (IAM). Вы выбираете Logto, поставщика идентификационных услуг, который использует OpenID Connect (OIDC) для аутентификации. Поскольку OIDC построен поверх OAuth 2.0, Logto также поддерживает авторизацию для вашего приложения.

Чтобы уменьшить трение для ваших пользователей, вы включаете "Войти с Google" в Logto. Это использует OAuth 2.0 для обмена данными авторизации и пользовательской информации между Logto и Google.

После того как пользователь входит в AppA через Logto, AppA получает ID токен, который является JSON Web Token (JWT), содержащим информацию о пользователе.

По мере роста вашего бизнеса вы запускаете новое приложение, AppB, которое также нуждается в аутентификации пользователей. Поскольку Logto уже настроен, вы можете повторно использовать ту же схему аутентификации для AppB. Теперь ваши пользователи могут войти в AppA и AppB с одним набором учетных данных, что называется единым входом (SSO).

Позже бизнес-партнер просит подключить их корпоративную SSO систему, которая использует Security Assertion Markup Language (SAML). Вы обнаруживаете, что Logto поддерживает подключения SAML, поэтому вы настраиваете подключение между Logto и SSO системой партнера. Теперь пользователи из организации партнера могут также входить в AppA и AppB, используя свои существующие учетные данные.

---

Надеюсь, эта статья прояснила для вас эти концепции. Для более глубоких объяснений и примеров обратитесь к Auth Wiki. Если вы ищете решение IAM для вашего приложения, рассмотрите возможность использования управляемого сервиса, такого как Logto, чтобы сэкономить время и усилия.