JWT - асимметричное c шифрование - PullRequest
Новая
       72

JWT - асимметричное c шифрование

1 голос
/ 18 февраля 2020

У меня есть три сервера: - сервер авторизации - сервер api - внешний сервер

Сервер авторизации возвращает автономный токен доступа JWT (+ refre sh токен). JWT нигде не хранятся на сервере авторизации. Я хочу защитить JWT с помощью асимметричного шифрования c, и я не уверен, верна ли моя идея. Позвольте мне описать поток:

  1. После входа с Fronted Server сервер авторизации получает учетные данные пользователя, затем генерирует токен JWT и кодирует его с помощью ключа publi c.
  2. Fronted Server получает зашифрованный Токен JWT и клиент (веб-браузер) сохраняют его как готовый к использованию только по протоколу HTTP ie.
  3. Клиент отправляет запрос на защищенный ресурс, поэтому FrontEnd на основе полученного закодированного токена JWT запрашивает защищенный API данных сервера.
  4. API-сервер на основе защищенного значения JWT и расшифровки секретного ключа и проверяет, достаточно ли у пользователя доступа для выполнения операции.
  5. Если срок действия токена JWT истекает, интерфейс отправляет запрос на сервер авторизации с рефреном sh получить новый токен JWT.

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

1 Ответ

1 голос
/ 19 февраля 2020

Я хочу защитить JWT с помощью асимметричного c шифрования, и я не уверен, верна ли моя идея.

В общем, шифрование данных - это хорошая идея. Особенно, если вы транспортируете конфиденциальные данные.

Позвольте мне описать поток […]. В этом случае Серверу авторизации и Серверу API потребуется хранить закрытый ключ для расшифровки. Это решение достаточно безопасно? Можно ли хранить один и тот же закрытый ключ на двух серверах? Вы знаете, правильный ли поток? Или, может быть, поток данных должен быть другим?

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

Этот поток абсолютно нормален. И AS, и сервер API будут иметь общий секрет, чтобы они могли зашифровать или расшифровать токен.

Я предлагаю вам прочитать больше о JWE (зашифрованном JWT) и связанных с ним RFC7516. . Эта спецификация описывает стандартный способ шифрования токенов. В зависимости от языка программирования, который вы используете, вы можете найти библиотеки, которые поддерживают JWE. https://jwt.io/ перечисляет множество библиотек, и некоторые из них поддерживают больше, чем подписанные токены (JWS). Например, com.nimbusds / nimbus-jose-jwt (Java) или web-token / jwt-framework (PHP).

A возможно поток может быть следующим. Обратите внимание, что это, несомненно, создаст сложность в коде вашего сервера AS и API. Поэтому, прежде чем реализовать его, вы должны убедиться, что необходимо зашифровать ваши токены! (например, вы транспортируете конфиденциальные данные)

  • AS подписывает токен своим закрытым ключом (например, алгоритм RSxxx). , PSxxx или ESxxx) => JWS
  • JWS шифруется в соответствии с RFC7516 с помощью алгоритма шифрования asymmetri c (например, AxxxKW или AxxxGCMKW) и общим ключом => Вложенный токен (JWS в JWE). )
  • Вложенный токен отправляется клиенту
  • Клиент не может прочитать содержимое, но токен можно отправить на сервер API как обычно
  • Сервер API расшифровывает JWE с общим ключом для получения JWS
  • Сервер API проверяет JWS с помощью AS publi c key
...