Что такое OIDC: от причин его необходимости до принципов работы

Определение OpenID Connect (OIDC)#

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

Проще говоря: OIDC = Протокол авторизации + Аутентификация личности.

Зачем нужен OIDC?#

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

Ключевые концепции и поток авторизации OAuth 2.0#

OAuth 2.0 (Open Authorization) — это протокол авторизации, который позволяет пользователям предоставлять сторонним приложениям доступ к своим ресурсам, не делясь своими учетными данными, такими как имена пользователей и пароли. Он включает четыре основные роли:

• Владелец ресурса: Пользователь, который владеет ресурсами
• Сервер ресурсов: Сервер, хранящий пользовательские ресурсы
• Клиент: Стороннее приложение, запрашивающее доступ к ресурсам пользователя
• Сервер авторизации: Сервер, который проверяет личность пользователя и выдаёт токены доступа

Типичный поток авторизации OAuth 2.0 выглядит так:

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

Ограничения OAuth 2.0#

Протокол OAuth 2.0 сосредоточен только на выдаче токенов доступа. Сервер ресурсов проверяет эти токены и возвращает авторизованные ресурсы. Однако сервер ресурсов не знает личность пользователя.

Это не было значительной проблемой в ранней интернет-экосистеме.

Тем не менее, когда такие платформы, как Google, Facebook, Twitter и Github, развились, они начали предлагать богатые пользовательские ресурсы, которые стали ценными для сторонних приложений.

Хотя OAuth 2.0 отлично справляется с авторизацией стороннего доступа к ресурсам пользователя, он имеет ограничения. Типичный сценарий: поскольку информация о пользователе также является ресурсом, когда сторонним приложениям нужно получить основную информацию о пользователе, разные платформы (как Google, Facebook, Twitter) возвращают информацию о пользователе в разных форматах, создавая проблемы для разработчиков.

OIDC был создан для решения этих проблем.

Роли в OIDC#

Для того чтобы обеспечить аутентификацию пользователей поверх OAuth 2.0 и устранить его ограничения, OIDC ввел три роли:

• Конечный пользователь (EU): Окончательный пользователь, соответствующий Владельцу ресурса в OAuth 2.0
• Доверяющая сторона (RP): Зависимая сторона, соответствующая Клиенту в OAuth 2.0
• Поставщик OpenID (OP): Провайдер услуги аутентификации личности, соответствующий Серверу авторизации и Серверу ресурсов в OAuth 2.0

OP является основной ролью, предоставляющей обе функции авторизации OAuth 2.0 и рассматривая информацию о пользователе как отдельный ресурс.

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

Процесс аутентификации OIDC схож с OAuth 2.0, но так как OP объединяет роли Сервер авторизации и Сервер ресурсов, она возвращает как токен доступа, так и токен личности (ID Token). Токен ID содержит информацию о личности пользователя, и RP может проверить личность пользователя, проверив токен ID.

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

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

Токен ID (токен личности) в OIDC#

Когда пользователи авторизуют сторонние приложения, OP возвращает как токен доступа OAuth 2.0, так и токен ID в формате JWT. Этот токен ID содержит информацию о личности пользователя, такую как ID пользователя, имя пользователя, email и аватар. RP может подтвердить личность пользователя, проверив токен ID.

Как JWT, токен ID содержит стандартизированные притязания, включая эти обязательные основные притязания:

• iss (Issuer): Уникальный идентификатор Поставщика OpenID, выдающего токен ID
• sub (Subject): Уникальный идентификатор пользователя
• aud (Audience): Идентификатор клиентского приложения, получающего токен ID
• exp (Expiration Time): Когда истекает токен ID
• iat (Issued At): Когда был выдан токен ID

Для получения подробной информации о токенах ID, пожалуйста, обратитесь к: Токен ID.

Конечная точка userinfo#

Конечная точка UserInfo — это стандартизированный HTTP API, предоставляемый OP для получения сведений об аутентифицированном пользователе. Отправив GET или POST запросы с токеном доступа на эту конечную точку, вы можете получить информацию о пользователе в формате JSON. Возвращенные данные включают стандартизированные поля, такие как уникальный ID пользователя (sub), имя пользователя (name), email и изображение.

Процесс получения информации о пользователе следует тому же шаблону, что и доступ к защищенным ресурсам в OAuth 2.0. Как правило, информация о пользователе, полученная из конечной точки userinfo, более обширна, чем в токене ID, поскольку токен ID в первую очередь служит для аутентификации личности и базовой информации о пользователе.

Для подробной информации о конечной точке Userinfo, пожалуйста, обратитесь к: Userinfo endpoint.

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

Области действия в OIDC#

Области действия в OIDC определяют, какую информацию о пользователе RP может получить. OIDC определяет стандартные области действия, с openid областью, обязательной в потоках аутентификации OIDC.

Общие стандартные области действия включают:

• openid: Указывает запрос аутентификации OIDC
• profile: Основная информация о пользователе, такая как имя и аватар
• email: Информация о email пользователя
• phone: Номер телефона пользователя
• address: Информация об адресе пользователя

Разные области действия возвращают разную информацию о пользователе. Например, запрос openid profile email возвращает основную информацию о пользователе и email в токене ID и Userinfo, в то время как openid profile email phone address включает информацию о номере телефона и адресе.

Управление личностью на основе OIDC#

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

• Единый вход (SSO): OIDC естественно поддерживает SSO через расширенную информацию о пользователе сессии, что позволяет управлять единым состоянием входа и делиться идентификацией между приложениями
• Управление структурой организации: Расширенная информация об организации пользователя может управлять сложными организационными структурами, включая иерархии отделов и отношения пользовательских групп
• Управление разрешениями: Расширенные атрибуты разрешений пользователя позволяют контролировать доступ к ресурсам с высокой гранулярностью, включая информацию о ролях и конфигурацию политики разрешений

Гибкость OIDC адаптируется к изменяющимся потребностям управления личностью. Многие системы управления личностью строятся на основе OIDC, такие как Logto, которая предоставляет функции SSO, управления организацией и управления разрешениями.