В платформе идентификации Azure AD предусмотрены следующие типы токенов:
- access token
- refresh token
- ID token
Разные типы токенов используются в разных сценариях аутентификации и авторизации. Как мы помним, для авторизации используется протокол OAuth 2.0, в то время как функцию аутентификации пользователя выполняет OpenID Connect, который является своеобразной надстройкой над OAuth.
Access token (токен доступа) используется сервером авторизации и содержит информацию о пользователе и приложении, для которого данный токен предназначен.
Токен доступа валиден короткое время (1 час по умолчанию), поэтому серверы авторизации также выдают refresh token (токен обновления) вместе с токеном доступа. После этого клиентское приложение может обмениваться этим токеном и запрашивать его продление.
ID tokensпосылаются как часть потока аутентификации OpenID Connect. Они могут передаваться вместе с access token или независимо и используются для аутентификации пользователя. Такой токен не должен использоваться для авторизация доступа вместо токена доступа! В тоже время такие токены содержат информацию о ролях и использоваться для ограничения доступа внутри приложения.
Структура токена
Все токены безопасности представляются в формате JWT (JSON Web Tokens), которые закодированы в base64. Декодировать токен с целью отладки можно на сайте https://jwt.ms/
Такой тип токенов содержит клеймы (claims) и метаданные. Метаданные включают срок действия токена доступа и области (scopes), для которых он действителен. Благодаря этим данным приложение может выполнять интеллектуальное кэширование маркеров доступа, не анализируя сам маркер.
Claims — это пары имя/значение, которые предоставляют информацию в виде утверждений об одном объекте, таком как клиентское приложение или владелец ресурса, другому, такому как, сервер ресурсов. Проще сказать, они содержат факты (характеристики) объектов и субъектов авторизации.
Scopes — это типы разрешений, определённых для ресурса. Часто их просто называют правами (permissions), хотя это не совсем точное определение.
Типы утверждений в токенах доступа
JWT access token состоит из 3 частей:
- Заголовок — содержит информацию о том, какой тип токена используется, как он подписан и как его проверить.
- Полезная информация — тело токена, которое содержит всю информацию об объекте и субъекте, для которого выдан токен, о пользователе и приложении.
- Подпись — используется для проверки токена.
Claims передаются только если они содержат непустые значения. Список доступных утверждений по умолчанию доступен по ссылке. Самые главные клеймы:
- aud, appid — это Application ID приложения в вашем тенанте;
- iss — Issuer ID, URL и ID тенанта, выписавшего токен;
- oid — Object ID пользователя.
- preferred_username — идентификатор пользователя, чаще
UPN или email, для кого токен выдан; - scp — набор скоупов в вашем приложении, для которых приложение запрашивает разрешение.
- tid — GUID Azure AD тенанта (Tenant ID), откуда пришел пользователь
- groups — сам клейм является еще одним JSON объектом, который перечисляет группы пользователя. Если групп больше 150 для SAML протокола и больше 200 для JWT, то вместо списка групп Azure AD предоставляет ссылку на Graph API запрос, чтобы получить полный список групп.
Помимо базовых, существуют опциональные клеймы для каждой версии платформы — v.1.0 и v.2.0. Список доступен здесь.
Типы утверждений в ID tokens
ID токены, как и access токены имеют почти такие же клеймы, но имеют и дополнительные, в частности, email, roles, sub.
Для идентификации пользователя необходимо использовать oid + sub. В обоих случаях это GUID пользователя, разница в том, что oid содержит immutable значение, которое одинаково для всех приложений, в то время как GUID в токене sub (subject) в двух разных приложениях будет разных, так как характеризует пользователя (principal) в каждом конкретном приложении.
Roles содержит список ролей пользователя, определяемый в манифесте приложения.
Для передачи данных о пользователе меду тенантами необходимо использовать комбинацию oid+sub+tid.
Области в OpenID Connect
Существует ряд заранее предопределенных областей (scopes), используемых в протоколе OpenID Connect: openid, email, profile, и offline_access.
openid используется при sign-in пользователя в приложение, используя протокол OpenID Connect. Это генерирует страницу согласия для пользователя (user consent), где пользователь дает разрешение на определенные права, запрашиваемые приложением, если user consent включен в вашем тенанте. Поучив такое разрешение, приложение получит идентификатор пользователя в клейме sub. Также этот скоуп используется для получения ID токена для аутентификации пользователя. Для чтения клейма sub требуются права user.read, которые Azure AD присваивает по умолчанию приложению, иначе нельзя будет залогиниться в него.
profile — эта область, которая позволяет приложению получить информацию о профиле пользователя, такую как given name, surname, preferred username, и object ID.
offline_access дает доступ к ресурсам приложению от имени пользователя на определенное время. Фактически, при наличии такого скоупа приложение может получать refresh tokens от имени пользователя.
Помимо базовых областей с помощью Graph API для каждого приложения можно определить индивидуальные скоупы. Они будут выглядеть как Gprah API URL скопа, например, для чтения почты пользователя скоуп выглядит как:
https://graph.microsoft.com/mail.send
Параметр scope, передаваемый в запросе выглядит как список делегированных прав (delegated permisisons), которые запрашивает приложение, разделенных пробелом:
GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?<br> client_id=6731de76-14a6-49ae-97bc-6eba6914391e<br> &response_type=code<br> &redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F<br> &response_mode=query<br> &scope=<br> https%3A%2F%2Fgraph.microsoft.com%2Fcalendars.read%20<br> https%3A%2F%2Fgraph.microsoft.com%2Fmail.send<br> &state=12345
После ввода креденшелов пользователем, конечная точка Microsoft identity platform проверяет согласия пользователем (user consent) для приложения и админское согласие (admin consent) на уровне тенанта для данного приложения, выданные ранее. Если ранее согласие не дано, то или тенант запросит разрешение у пользователя, или, если user consent отключен на уровне тенанта (что рекомендуется с точки зрения безопасности корпоративных пользователей), то доступ приложения будет блокирован.
Типы токенов и разные потоки аутентификации и авторизации
Для разных типов flow (поток авторизации) в Azure AD предусмотрено использование разных типов токенов. Соответственно, в зависимости от вашего клиента и приложения вам нужно выбрать правильный flow и тип токена.
