Добавьте пользовательские претензии для JWT-токенов доступа с помощью Logto, чтобы повысить эффективность авторизации

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

Обычно информация, содержащаяся в JWT, определяется сервером аутентификации. Согласно протоколу OAuth 2.0, JWT обычно содержит такие поля, как sub (тема), aud (аудитория) и exp (срок действия), которые обычно называются претензиями (claims). Эти претензии могут помочь проверить валидность токена доступа.

Однако существует множество сценариев, в которых JWT используется для проверки, и стандартные претензии JWT часто могут не соответствовать потребностям пользователей. Часто люди задаются вопросом: если JWT может содержать определенную информацию, можем ли мы добавить в него дополнительную информацию, чтобы упростить процесс авторизации?

Ответ — ДА, мы можем добавить к JWT пользовательские претензии, такие как область действия (scope) и уровень подписки текущего пользователя. Таким образом, мы можем передавать информацию об идентичности пользователя между клиентом и сервером (здесь имеется в виду сервер, предоставляющий различные услуги, также называемый поставщиком услуг), чтобы обеспечить аутентификацию пользователя и контроль доступа.

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

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

Как работает пользовательская настройка претензий JWT в Logto?#

Вы можете перейти на страницу списка пользовательских претензий JWT, нажав на кнопку "JWT claims" на боковой панели.

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

В редакторе на левой панели вы можете настроить свою функцию getCustomJwtClaims. Этот метод имеет три входных параметра: token, data и envVariables.

• token — это оригинальный полезный груз токена доступа, полученный на основе учетных данных текущего пользователя и конфигураций вашей системы, а также информация о доступе пользователя в Logto.
• data — это вся информация о пользователе в Logto, включая все его роли, идентичности социальной аутентификации, SSO-идентичности, членство в организациях и т. д.
• envVariables — это переменные окружения, которые вы настроили в Logto для текущего сценария использования токена доступа конечным пользователем, такие как ключи АПИ внешних сервисов и т. д.

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

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

Ниже приведена диаграмма последовательности, показывающая процесс выполнения функции getCustomJwtClaims, когда конечный пользователь инициирует запрос на аутентификацию к Logto и в конечном итоге получает токен доступа в формате JWT, возвращаемый Logto.

Если функция Custom JWT не включена, шаг 3 на диаграмме будет пропущен, и шаг 4 будет выполнен сразу после завершения шага 2. В этом случае Logto примет возвращаемое значение getCustomJwtClaims как пустой объект и продолжит выполнение следующих шагов.

Увеличьте эффективность вашей авторизации с помощью настраиваемых претензий JWT: практический пример#

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

Настройка сценария#

Команда Джона разработала приложение AI Assistant App, которое позволяет пользователям общаться с AI-роботами для получения различных услуг.

Сервисы AI-ботов делятся на бесплатные и платные. В бесплатные услуги входят рекомендации по авиабилетам, а в платные — прогнозирование на фондовом рынке.

AI Assistant App использует Logto для управления всеми пользователями, которые делятся на три типа: бесплатные пользователи, пользователи с предоплатой и премиум-пользователи. Бесплатные пользователи могут использовать только бесплатные услуги, пользователи с предоплатой могут пользоваться всеми услугами (платными за использование), а премиум-пользователи могут пользоваться всеми услугами, но есть ограничения на запросы для предотвращения злоупотреблений.

Кроме того, AI Assistant App использует Stripe для управления оплатами пользователей и имеет собственный log-сервис для записи журналов операций пользователей.

Конфигурации Logto#

Сначала мы создаем API-ресурсы для сервиса AI Assistant App и создаем два области действия, recommend:flight и predict:stock.

Затем мы создаем две роли, free-user и paid-user, и назначаем соответствующие области действия:

• Назначаем область действия recommend:flight роли free-user.
• Назначаем обе области действия recommend:flight и predict:stock роли paid-user.

Наконец, мы создаем трех пользователей, free-user, prepaid-user и premium-user, и назначаем им соответствующие роли:

• Назначаем роль free-user пользователю free-user.
• Назначаем роль paid-user пользователям prepaid-user и premium-user.

Как показано на следующем изображении, для реализации информации об авторизации, необходимой для вышеописанного сценария, мы хотим включить в JWT информацию о roles, balance и numOfCallsToday текущего авторизованного пользователя. При проверке токена доступа в AI Assistant App эта информация может быть использована для быстрой проверки разрешений.

После настройки envVariables мы реализуем функцию getCustomJwtClaims и нажимаем кнопку "Run test", чтобы увидеть результат дополнительных претензий JWT на основе текущих тестовых данных.

Поскольку мы не настроили тестовые данные для data.user.roles, roles, показанный в результате, представляет собой пустой массив.

Проверка срабатывания функции пользовательских JWT#

В соответствии с вышеуказанными настройками Logto, мы получили соответствующие результаты в тесте. Далее мы используем пример приложения, предоставленный Logto, чтобы проверить, действует ли наш пользовательский JWT. Найдите SDK, с которым вы знакомы, на Logto SDKs и разверните пример приложения согласно документации и соответствующему репозиторию на GitHub.

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

После входа пользователя free_user в пример приложения, которое имитирует AI Assistant App, мы можем увидеть информацию о roles, balance, numOfCallsToday, isPaidUser и isPremiumUser, добавленную нами, просмотрев часть полезного груза токена доступа JWT.

Значения balance, numOfCallsToday, isPaidUser и isPremiumUser совпадают с предыдущими тестами, а roles равно ["free-user"]. Это потому, что в процессе фактического входа конечного пользователя мы получаем всю доступную информацию о пользователе и обрабатываем ее соответствующим образом.

Для премиум-пользователей мы можем увидеть, что roles равно ["paid-user"], а isPaidUser и isPremiumUser равны true.

Обновление логики авторизации поставщика услуг#

На предыдущих шагах мы добавили пользовательские претензии в токен доступа пользователя на основе потребностей бизнеса. Далее мы можем использовать эти претензии для быстрой проверки разрешений.

Здесь мы предоставляем логику проверки JWT-токенов доступа на стороне API Logto. Полная реализация кода доступна в репозитории GitHub:

Вы можете ориентироваться на логику API Logto для проверки токенов доступа и настроить ее под свои бизнес-цели. Например, для рассматриваемого здесь сценария AI Assistant App можно добавить логику проверки пользовательских претензий, таких как roles, balance, numOfCallsToday, isPaidUser и isPremiumUser, в функцию verifyBearerTokenFromRequest.

Приведенный выше пример относится к сценарию, где это влияет на вход пользователя и получение токена доступа JWT. Если ваше применение связано с взаимодействием машины с машиной (M2M), вы также можете настроить пользовательские претензии JWT для M2M-приложений отдельно.

Настройка пользовательских JWT для пользователей не повлияет на результат получения токенов доступа M2M-приложениями и наоборот.

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

Зачем использовать настраиваемые претензии JWT?#

Мы рассмотрели сценарий AI Assistant App для Джона и объяснили, как использовать функцию настраиваемых JWT в Logto для достижения более гибкой проверки авторизации. В этом процессе мы можем увидеть преимущества функции настраиваемых JWT:

1. Без функции кастомных JWT пользователи должны запрашивать внешний API (например, то, что вы делаете в getCustomJwtClaims) каждый раз, когда они проверяют разрешения. Для поставщика услуг, предоставляющего этот API, это может увеличить дополнительную нагрузку. С функцией настраиваемых JWT, эта информация может быть включена напрямую в JWT, что уменьшает частые вызовы внешнего API.
2. Для поставщиков услуг функция настраиваемых JWT может помочь им быстрее проверять разрешения пользователей, особенно когда клиент часто обращается к поставщику услуг, улучшая производительность услуг.
3. Функция настраиваемых JWT может помочь вам быстро реализовать дополнительную информацию о разрешениях, требуемую бизнесом, и эту информацию можно безопасно передать между клиентом и поставщиком услуг, так как JWT сам по себе содержит данные и может быть зашифрован, что затрудняет фальсификацию токена.

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

Заключение#

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

Мы предоставили сценарий AI Assistant App Джона и продемонстрировали, как использовать функцию настраиваемых JWT в Logto для достижения более гибкой проверки авторизации. Мы также указали на некоторые ключевые моменты использования настраиваемых JWT. Исходя из фактических бизнес-сценариев, пользователи могут включать в JWT токен доступа различную информацию, связанную с пользователями, в соответствии с потребностями их бизнеса, чтобы поставщик услуг мог быстро проверять разрешения пользователя.