Как сгенерировать JWT/JWS с JWE

Question

Я разрабатываю систему аутентификации/авторизации j2ee. Я хочу использовать токены JWT, подписать полезную нагрузку с помощью JWS и зашифровать ее с помощью JWE.

I found a decent tutorial from bitbuckets jose4j

Этот пример показывает, что они генерируют JWK с помощью EllipticCurveJsonWebKey. Я не понимаю, как это можно использовать для аутентификации/авторизации. Вам не нужно будет хранить секретный ключ в файле свойств или в записи JNDI, а затем использовать этот ключ для подписания/шифрования JWT? Таким образом, когда я получаю HTTP-запрос, я могу использовать тот же ключ для проверки JWT. Большинство учебных пособий, которые я нашел, используют аналогичный пример.

Как это сделать с помощью того же секретного ключа на стороне сервера?

Answer 1

Первое, что нужно сделать - зайдите в эту статью о authentication with OAuth2.0. В зависимости от вашего фона вам может потребоваться некоторое чтение в OAuth & OpenID Connect.

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

• когда сеанс создается (IAT)
• как долго сессия остается в силе (ехр)
• , который создал сессии, что ваша система аутентификации (ISS)
• , который проходит проверку подлинности этой сессии, что ваш идентификатор пользователя или что-то (суб)

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

Как правило, рекомендуется ссылаться на предлагаемые заявки в the OIDC core spec.

И вот где это становится сложно. У вас в основном есть два варианта: вы можете либо создать серверную строку, которая абсолютно непрозрачна для всех приложений и станет сеансом. Затем предложите конечную точку интроспекции маркера, где клиенты могут отправить эту строку и получить описанные выше претензии (плюс все дополнительные, которые вы решите отобразить на свой сеанс). Это также означает, что вам понадобится некоторое хранилище, где эти непрозрачные строки сохраняются вместе с требованиями пользователей, к которым они привязаны.

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

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

Также проверьте this article за очень хороший обзор того, что есть в токене auth.