OAuth 2.1 Draft 1.00: изменения типа клиента

OAuth 2.1 Draft 1.00: изменения типа клиента

конфиденциальный, сертифицированный и общедоступный

С момента публикации OAuth 2.0 в 2012 году были опубликованы различные RFC для расширения существующего протокола, а также для выявления проблем безопасности с типами грантов. Пришло время для OAuth 2.1 очень хорошо подводит итог.

Если вы хотите внедрить безопасное решение OAuth сегодня, необходимо прочитать: RFC 6749 (OAuth 2.0 Core), RFC 6750 (токены-носители), RFC 6819 (модель угроз и вопросы безопасности), RFC 8252 (OAuth для собственных приложений), RFC 8628 (предоставление устройства), OAuth для браузерных приложений, передовой опыт безопасности OAuth 2.0, RFC 7009 (отзыв токена), RFC 8414 (метаданные сервера авторизации), и если вы также внедряете сервер OAuth, вам необходимо прочитайте RFC 7519 (JWT), JWT Best Current Practice, JWT Profile for Access Tokens и, возможно, некоторые другие, которые я забыл. Это много материала.

Источник: https://aaronparecki.com/2019/12/12/21/its-time-for-oauth-2-dot-1

OAuth 2.1 пытается использовать лучшие практики из оригинальной работы и последующего расширения. Прошло 8 лет с момента первоначального RFC, так что это очень своевременно. В этом посте я расскажу об одном конкретном разделе: Типы клиентов.

Типы клиентов OAuth 2.0

Раздел 2.1 исходного RFC определяет только два типа клиентов на основе двух критериев:

1. Способность сохранять конфиденциальность своих учетных данных. Проще говоря, если клиент способен защитить учетные данные клиента, такие как client_secret или пароль, выданные сервером авторизации.
2. Возможность безопасной аутентификации клиента с помощью других средств: если клиент может безопасно аутентифицировать себя.

В исходном RFC определены три примера метода аутентификации клиента. Хотя аутентификация клиента не ограничивается только этими методами, и сервер авторизации может принимать любую аутентификацию, если метод соответствует требованиям безопасности.

1. Пароль клиента: клиент с паролем может использовать для этой цели схему аутентификации HTTP Basic.
2. Секрет клиента: клиент может передать client_id (неконфиденциально) и client_secret в тексте запроса, если ему разрешено использовать пароль клиента со схемой аутентификации HTTP Basic.
3. Схемы аутентификации HTTP: любая другая схема аутентификации HTTP, если применимо.

Конфиденциальные клиенты

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

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

Публичные клиенты

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

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

Нужно ли нам больше типов клиентов?

Со временем стало очевидно, что существует потребность в большем количестве типов клиентов. OAuth широко использовался в последнее десятилетие, и были общедоступные клиенты, которым будут предоставлены учетные данные, хотя RFC явно выступает против этого:

Сервер авторизации НЕ ДОЛЖЕН выдавать пароли клиентов или другие
учетные данные клиента собственным приложениям или клиентам приложений на основе агента пользователя
с целью аутентификации клиента. Сервер авторизации
МОЖЕТ выдать пароль клиента или другие учетные данные
для конкретной установки собственного клиента приложения на конкретном
устройстве.

Источник: https://tools.ietf.org/html/rfc6749#section-10.1

Особенно мобильные нативные и одностраничные приложения активно используют OAuth с учетными данными, хотя предоставление учетных данных не делает их конфиденциальными. Еще один момент, который неправильно понимают, заключается в том, что безопасная разработка не делает приложение конфиденциальным в сфере OAuth. Кроме того, иногда мобильные приложения считались достаточно безопасными для защиты учетных данных клиента, даже если исходный RFC запрещает это. Резюме:

1. Публичные клиенты получили учетные данные и считались конфиденциальными в силу наличия учетных данных.
2. Безопасная разработка клиентов, считающихся их конфиденциальными

Типы клиентов OAuth 2.1

Одна из основных проблем, которую решает OAuth 2.1, заключается в различении клиентов независимо от того, есть ли у них учетные данные или нет. Критерии для клиентов следующие:

1. Наличие у клиента учетных данных
2. Подтверждена ли личность клиента

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

Сервер авторизации МОЖЕТ установить метод аутентификации клиентов
с общедоступными клиентами, который преобразует их в клиентов с учетными данными.
Однако сервер авторизации НЕ ДОЛЖЕН полагаться на аутентификацию клиентов с учетными данными
в целях идентификации клиент.

Есть еще несколько уточнений для варианта использования нативных приложений:

За исключением случаев использования такого механизма, как динамическая регистрация клиентов
[RFC7591] для предоставления секретов для каждого экземпляра, нативные приложения
классифицируются как общедоступные клиенты, как определено в разделе 2.1; они ДОЛЖНЫ быть
зарегистрированы на сервере авторизации как таковые. Серверы авторизации
ДОЛЖНЫ записывать тип клиента в сведениях о регистрации
клиента, чтобы соответствующим образом идентифицировать и обрабатывать запросы.

Источник: https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00#section-9.2

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

Наконец, есть три типа клиентов:

Конфиденциальные клиенты

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

Авторизованные клиенты

Клиенты, у которых есть учетные данные, и их личность не была подтверждена AS, назначаются как клиенты с учетными данными.

Публичные клиенты

Клиенты без учетных данных называются публичными клиентами.

Вывод

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