Профиль токена носителя OAuth 2.0 против профиля токена MAC

Почти все реализации, которые я вижу сегодня, основаны на OAuth 2.0 Bearer Token Profile. Конечно, это стандарт RFC, предложенный сегодня. Профиль OAuth 2.0 Bearer Token предоставляет упрощенную схему аутентификации. В этой спецификации описывается, как использовать токены носителя в HTTP-запросах для доступа к защищенным ресурсам OAuth 2.0. Любая сторона, владеющая токеном-носителем («носителем»), может использовать его для получения доступа к связанным ресурсам (без демонстрации владения криптографическим ключом). Чтобы предотвратить неправильное использование, жетоны на предъявителя должны быть защищены от раскрытия при хранении и при транспортировке. Прежде чем перейти к профилю MAC OAuth 2.0, давайте кратко рассмотрим поток сообщений OAuth 2.0. OAuth 2.0 имеет в основном три этапа.

1. Запрос разрешения.

2. Обмен разрешения авторизации на токен доступа.

3. Получите доступ к ресурсам с помощью токена доступа.

Откуда берется тип токена? Спецификация ядра OAuth 2.0 не требует никакого типа токена. В то же время в любой момент запросчик токена — клиент — не может решить, какой тип токена ему нужен. Сервер авторизации должен решить, какой тип токена должен быть возвращен в ответе токена доступа. Таким образом, тип токена вступает в действие на этапе 2, когда сервер авторизации возвращает обратно токен доступа OAuth 2.0.

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

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

Например, следующее — это то, что вы получаете за ответ токена доступа независимо от того, какой тип предоставления вы используете.

Выше для Bearer — следующее для MAC.

Здесь вы видите, что ответ MAC Access Token имеет два дополнительных атрибута. mac_key и mac_algorithm. Позвольте мне перефразировать это — «Каждое определение типа токена доступа определяет дополнительные атрибуты (если таковые имеются), отправляемые клиенту вместе с параметром ответа« access_token ».

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

В отличие от Bearer, профиль MAC-токена никогда не передается по секрету.

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

Mac_key — это общий симметричный секрет, используемый в качестве ключа алгоритма MAC. Сервер не будет переиздавать ранее выданную комбинацию ключа MAC и идентификатора ключа MAC. Теперь посмотрим, что происходит на этапе 3. Ниже показано, как выглядит HTTP-заголовок авторизации при использовании токена носителя.

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

Это требует немного большего внимания. id — это идентификатор ключа MAC или access_token из фазы 2. отметка времени запроса. Значение представляет собой положительное целое число, установленное клиентом при отправке каждого запроса на количество секунд, прошедших с фиксированного момента времени (например, 1 января 1970 г. 00:00:00 по Гринвичу). Это значение уникально для всех запросов с одинаковой комбинацией меток времени и идентификатора ключа MAC. nonce — это уникальная строка, сгенерированная клиентом. Это значение уникально для всех запросов с одинаковой комбинацией меток времени и идентификатора ключа MAC. Клиент использует алгоритм MAC и ключ MAC для вычисления запроса mac . Вот как вы выводите нормализованную строку для генерации HMAC. Нормализованная строка запроса представляет собой согласованную воспроизводимую конкатенацию нескольких элементов HTTP-запроса в одну строку. Нормализовав запрос в воспроизводимую строку, клиент и сервер могут оба рассчитать MAC запроса по одному и тому же значению. Строка создается путем объединения, по порядку, следующих элементов HTTP-запроса, за каждым из которых следует символ новой строки (% x0A):

1. Значение метки времени, рассчитанное для запроса.
2. Одноразовое значение, сгенерированное для запроса.
3. Метод HTTP-запроса в верхнем регистре. Например: «HEAD», «GET», «POST» и т. Д.
4. HTTP-URI запроса, как определено в разделе [RFC2616] 5.1.2.
5. Имя хоста, включенное в HTTP-запрос с использованием поля заголовка запроса «Host» в нижнем регистре.
6. Порт, указанный в HTTP-запросе с использованием поля заголовка запроса «Host». Если поле заголовка не включает порт, ДОЛЖНО использоваться значение по умолчанию для схемы (например, 80 для HTTP и 443 для HTTPS).
7. Значение атрибута поля заголовка запроса ‘ext’ ‘Authorization’, если он был включен в запрос (это необязательно), в противном случае — пустая строка.

За каждым элементом следует символ новой строки (% x0A), включая последний элемент, и даже если значение элемента является пустой строкой. Либо вы используете Bearer of MAC — конечный пользователь или владелец ресурса идентифицируется с помощью access_token. Авторизация, регулирование, мониторинг или любые другие операции качества обслуживания могут выполняться с access_token независимо от того, какой профиль токена вы используете.

Ссылка: Профиль токена носителя OAuth 2.0 против профиля токена MAC от нашего партнера JCG Прабата Сиривардены в блоге Facile Login .