Идентификационный токен и токен доступа: в чем разница?

«Давайте воспользуемся токеном для защиты вызова API. Что мне использовать: ID-токен или Access токен? ID токен мне кажется предпочтительнее. В конце концов, если я знаю, кто является пользователем, я могу принимать более обоснованные решения об авторизации, верно?»

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

«Что в конце концов изменится? Это всего лишь токены. Я могу использовать их по своему усмотрению. Что такого плохого может случиться?»

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

Что такое идентификационный токен?

ID токен — это артефакт, подтверждающий, что пользователь прошел аутентификацию. Он был представлен OpenID Connect (OIDC), открытым стандартом аутентификации, используемым многими системами идентификации такими, как Google, Facebook и, конечно же, Auth0. Ознакомьтесь с этим документом для получения дополнительных сведений об OpenID Connect. Давайте кратко рассмотрим проблему, которую призван решить OIDC.

Рассмотрим следующую схему:

 

Здесь пользователь со своим браузером аутентифицируется через провайдер OpenID и получает доступ к веб-приложению. Результатом процесса аутентификации на основе OpenID Connect является ID токен, который передается приложению в качестве доказательства того, что пользователь прошел аутентификацию.

Подтверждение аутентификации пользователя это всего лишь базовое представление об ID токене. Рассмотрим это подробнее.

Идентификационный токен JSON Web Token (JWT) — стандартный формат, который позволяет вашему приложению легко проверить его содержимое и убедиться, что оно исходит от ожидаемого эмитента и что никто другой его не менял. Если вы хотите узнать больше о JWT, посмотрите «The JWT Handbook».

Проще говоря, пример ID токена выглядит так:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwOi8vbXktZG9tYWluLmF1dGgwLmNvbSIsInN1YiI6
ImF1dGgwfDEyMzQ1NiIsImF1ZCI6IjEyMzRhYmNkZWYiLCJleHAiOjEzMTEyODE5NzAsImlhdCI6MTMxMTI4MDk3MCwibm
FtZSI6IkphbmUgRG 9lIiwiZ2l2ZW5fbmFtZSI6IkphbmUiLCJmYW1pbHlfbmFtZSI6IkRvZSJ9

Конечно, просто «на глазок» это не прочесть, поэтому вам нужно расшифровать его, чтобы увидеть, какой контент содержит JWT. Между прочим, ID токен не зашифрован, а закодирован только в Base 64. Вы можете использовать одну из множества доступных библиотек для его декодирования или самостоятельно проверить его с помощью сайта jwt.io.

Не вдаваясь в подробности, соответствующая информация, содержащаяся в указанном выше ID токене, выглядит следующим образом:

{ 

  "iss": "http://my-domain.auth0.com", 

  "sub": "auth0|123456", 

  "aud": "1234abcdef", 

  "exp": 1311281970, 

  "iat": 1311280970, 

  "name": "Jane Doe", 

  "given_name": "Jane", 

  "family_name": "Doe"

}

Эти свойства JSON называются «claims (заявки)», и они представляют собой заявления о пользователе и самом токене. Заявки о пользователе позволяют определить его личность.

Фактически, спецификации OpenID Connect не требуют, чтобы ID токен содержал заявку о пользователе. В своей минимальной структуре он содержит данные только для аутентификации.

Одним из важных требований является «aud» заявка. Оно определяет получателя, то есть веб-приложение, которое должно быть конечным получателем токена. В случае с использованием ID токена, значением «aud» будет Client ID приложения, которое должно использовать токен.

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

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

Наконец, возможно, самое важное: ID токен подписывает эмитент своим закрытым ключом. Для вас это гарантия происхождения токена и того, что он не был подделан. Это можно проверить, используя открытый ключ эмитента.

Здорово! Теперь вы знаете, что такое идентификационный токен. Но что вы можете с ним делать?

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

Кроме того, ваше приложение может персонализировать взаимодействие с пользователями, используя данные о пользователе, включенные в ID токен. Например, вы можете показать имя в пользовательском интерфейсе или отобразить сообщение «С наилучшими пожеланиями» в день рождения. Самое интересное в том, что вам не нужно делать дополнительных запросов, поэтому вы можете немного повысить производительность своего приложения.

Что такое токен доступа?

Теперь, когда вы знаете, что такое идентификационный токен, давайте попробуем понять, что такое Access токен.

Начнем с описания сценария, в который вписывается токен доступа:

 

На схеме выше клиентское приложение хочет получить доступ к ресурсу, например API или чему-либо еще, что защищено от несанкционированного доступа. Два других элемента на этой диаграмме — это пользователь, который является владельцем ресурса, и сервер авторизации. В этом сценарии Access токен является артефактом, позволяющим клиентскому приложению получить доступ к ресурсу пользователя. Он выдается сервером авторизации после успешной аутентификации пользователя и получения его согласия.

В контексте OAuth 2 Access токен позволяет клиентскому приложению получать доступ к определенному ресурсу для выполнения определенных действий от имени пользователя. Что известно как сценарий делегированной авторизации: пользователь делегирует клиентскому приложению доступ к ресурсу от своего имени. Это значит, например, что вы можете от своего имени разрешить приложению LinkedIn доступ к API Twitter для перекрестной публикации на обеих социальных платформах. Заметьте, что вы разрешаете LinkedIn только публиковать свои сообщения в Twitter. Вы не разрешаете ему удалять их, изменять данные вашего профиля или делать что-то еще. Это ограничение очень важно в сценарии делегированной авторизации и достигается с помощью областей действия, или scopes. Области действия — это механизм, позволяющий пользователю авторизовать стороннее приложение для выполнения только определенных операций.

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

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

В спецификации OAuth 2 ничего не говорится о формате Access токена. Это может быть строка в любом формате. Распространенным форматом, используемым для токенов доступа, является JWT, и на данный момент этот стандарт в разработке. Однако это не значит, что Access токены должны быть именно в этом формате.

Хорошо! Теперь вы знаете, что такое ID-токен и Access токен. Итак, вы готовы использовать их, не боясь ошибиться. Но подождите. Мне кажется, вы не уверены. Возможно, вам нужна другая информация. Ok. Итак, давайте посмотрим, для чего эти токены не подходят.

Для чего НЕ подходит ID-токен?

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

Как сказано выше, ID токен доказывает, что пользователь прошел аутентификацию. В собственном сценарии, то есть в сценарии, в котором клиент и API контролируются вами, вы можете решить, что ваш идентификационный токен подходит для принятия решений об авторизации и, возможно, все, что вам нужно знать — это личность пользователя.

Однако даже в этом сценарии безопасность вашего приложения, состоящего из клиента и API, может быть под угрозой. Фактически, не существует механизма, который привязывает ID токен к каналу клиентского API. Если злоумышленнику удастся украсть вашу «личность», он может использовать ее для вызова вашего API как законного клиента.

С другой стороны, для Acces токена существует набор методов, известных как ограничение отправителя (sender constraint), которые позволяют привязать токен доступа к определенному отправителю. Это гарантия того, что даже если злоумышленник украдет Access токен, он не сможет использовать его для доступа к вашему API, поскольку токен привязан к клиенту, который изначально его запросил.

В сценарии делегированной авторизации, когда сторонний клиент хочет вызвать ваш API, нельзя использовать ID токен для вызова API. Помимо отсутствия механизмов привязки к клиенту есть несколько других причин, по которым этого не следует делать.

Если ваш API принимает ID токен в качестве токена авторизации, вы сначала игнорируете предполагаемого получателя, указанного в aud (audience claim). В этом утверждении говорится, что он предназначен для вашего клиентского приложения, а не для сервера ресурсов (т. е. API).

Можно подумать, что это всего лишь формальность, но такой подход может повлечь за собой риски для безопасности.

Прежде всего, кроме прочих проверок, ваш API не должен принимать токен, который для него не предназначен. Если это произойдет, его безопасность окажется под угрозой. Фактически, если вашему API все равно, предназначен ли для него токен, для доступа к нему может быть использован ID токен, украденный из любого клиентского приложения, может быть использован для доступа к вашему API. Разумеется, для предотвращения несанкционированного доступа, проверка aud — это всего лишь одна из проверок, которую должен выполнять ваш API.

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

Для чего НЕ подходит Access токен?

Что касается Access токена, то он был задуман, чтобы продемонстрировать, что вы авторизованы для доступа к ресурсу, например, для вызова API.

Ваше клиентское приложение должно использовать его только с этой целью. Другими словами, Access токен не должен проверяться клиентским приложением. Он предназначен для сервера ресурсов, и клиентское приложение должно обрабатывать Access токены как непрозрачные строки, то есть строки без определенного значения. Даже если вам известен формат Access токена, не следует пытаться интерпретировать его содержимое в клиентском приложении. Как уже говорилось, формат Access токена — это соглашение между сервером авторизации и сервером ресурсов, и клиентское приложение не должно вмешиваться. Подумайте, что может случиться, если однажды формат Access токена изменится. Если ваш клиентский код (client code) проверял этот Access токен, в этом случае он будет тотчас сломан.

Краткий обзор

Путаница с использованием ID и Access токенов очень распространена, и, возможно, трудно понять различия между ними. Может быть, это в основном связано с отсутствием четкого понимания различных целей каждого артефакта, определенных в спецификациях OAuth и OpenID Connect. Кроме того, понимание сценариев, в которых изначально должны были действовать эти артефакты, играет важную роль в предотвращении путаницы при их использовании. Тем не менее, я надеюсь, что теперь эта тема немного прояснилась.

В иллюстрации кратко изложено то, что можно и чего нельзя делать с ID и Access токенами:

 

Переведено со статьи, полный текст доступен по ссылке.