Претензии для аутентификации сторонних лиц с помощью JWT

Мы разработали рабочий процесс, позволяющий сторонним системам (1) использовать нашу (2) без необходимости дополнительной аутентификации, как показано здесь:

Рабочий процесс JWT

Вот описание:

  1. Стороннее клиентское приложение (веб) хочет запустить наше приложение. Он запрашивает токен на собственном сервере.

  2. Сторонний бэкэнд генерирует JWT со случайным значением токена, связанным с текущим пользователем.

  3. Сторонний бэкэнд отправляет JWT в нашу систему через специальный API.

  4. После регистрации JWT отправляется обратно в стороннее клиентское приложение (веб).

  5. Стороннее приложение запускает наше клиентское приложение (веб), передавая JWT

  6. Наше приложение вызывает наш backend API, используя зарегистрированный JWT

Вопросы следующие:

  • Если этот рабочий процесс действительный / обычный
  • Каковы правильные утверждения для использования в JWT для user_email, organization_id, token

person Jaime    schedule 15.01.2020    source источник
comment
Токены JWT представляют собой простой json с хешем. Поэтому я бы снова предложил user_email как часть JWT, я предпочитаю использовать UUID, которые представляют пользователя. Также я бы посоветовал вам использовать разные ключи для каждой третьей стороны. Таким образом, токены, сгенерированные вами и третьей стороной, должны иметь разные хэши, а также у вас должно быть поле, в котором указывается, какой клиент сгенерировал JWT, чтобы различать. Отдыхайте, ваша архитектура хорошо выглядит как таковая   -  person Tarun Lalwani    schedule 17.01.2020


Ответы (1)


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

UPD похоже, что я неверно истолковал вопрос, и вы скорее предоставляете API для пользователей, авторизованных третьей стороной. Я удалил часть oAuth, которая сейчас кажется неуместной

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

Если вы выберете это, поток может быть таким:

  1. Стороннее клиентское приложение (веб) хочет запустить наше приложение. Он запрашивает токен на собственном сервере.
  2. Сторонний бэкэнд генерирует JWT с правильными issuer, audience другими необходимыми утверждениями и подписывает его своим закрытым ключом.
  3. Сторонний бэкэнд возвращает подписанный JWT клиенту
  4. Стороннее приложение запускает наше клиентское приложение (веб), передавая JWT
  5. Наше приложение вызывает наш серверный API с помощью зарегистрированного JWT (серверная часть будет проверять подпись токена с помощью эмитента токена и стороннего открытого ключа).

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

person timur    schedule 21.01.2020
comment
Привет @timur, вы исходите из неверной предпосылки: это не наш пользователь. Вся цель состоит в том, чтобы позволить третьей стороне запускать наше приложение для своих пользователей без необходимости входа в нашу систему. По крайней мере, не через интерфейс. - person Jaime; 21.01.2020
comment
Верно. Значит, вы достаточно доверяете третьим сторонам, чтобы авторизовать любого пользователя, которого они вам предоставляют? В этом случае, возможно, третьи стороны сгенерируют подписанный jwt (для вас как аудитории) с необходимыми утверждениями и подтвердят, что он исходит от указанных третьих сторон? Я обновлю ответ, как только перейду на правильный компьютер. - person timur; 21.01.2020
comment
да, это соединение B2B (по договоренности). Мы можем проверить, что он исходит от определенного защищенного сервера. Спасибо. - person Jaime; 21.01.2020