JWT: Многопользовательский сервер аутентификации, прекращающий использование jwt между разными клиентами?

Question

Кто-нибудь может помочь?

У меня есть многопользовательский сервер аутентификации, его работа заключается в создании JWT для конкретного клиента (клиентом является служба или приложение). Каждый клиент (сервис) имеет clientID и ClientSecret.

Сервер аутентификации подписывает все JWT с одним и тем же секретным ключом. Я хочу остановить использование JWT из системы A в системе B - например. Технически все JWT подписаны с одним и тем же секретом, так что это потенциальная проблема.

Мне было интересно, смогу ли я подключиться к аудитории и издателю?

Эмитентом будет сервер аутентификации, верно? Таким образом, для обоих разных токенов эмитент будет одинаковым, так что это, вероятно, не то, что я ищу.

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

Я не знаю, является ли это лучшим способом? Кроме того, формат аудитории - строка, но обычно содержит URL-адрес системы - это правильно?

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

Я немного озадачен лучшим способом реализации этого.

Я имею в виду, я мог бы просто создать собственное заявление, но я бы хотел использовать встроенные - если это их правильное использование.

У кого-нибудь есть опыт в этой области?

Итак, подведем итоги.

Маркер должен быть в состоянии быть идентифицированным, если он был передан Системе A или Системе B

Также токен должен быть активирован, если это токен доступа или токен обновления.

Есть идеи?

Заранее спасибо за любые идеи.

Answer 1

Я бы использовал аудиторию (aud) для этой цели в качестве целевой системы. Это может быть любая строка, и спецификации не важно, URL это или нет. Вы просто захотите, чтобы серверы обеспечивали соответствие аудитории (большинство библиотек делают это по умолчанию, но проверяют документацию).

Для обновления или доступа к токенам у вас есть несколько вариантов.

1) использовать эмитента. Опять же, это просто строка, так что это может быть host + «access» или host + «refresh» и убедитесь, что эмитенты соответствуют ожидаемым.

2) использовать пользовательскую заявку. JWT могут содержать любой тип JSON, поэтому создайте утверждение типа или что-то типа «доступ» против «обновить» (или используйте его только для маркеров «доступа»). Вам нужно будет вручную подтвердить

3) подписывать обновления и получать доступ к токенам с разными ключами. Это означает, что вы не сможете проверить подпись неправильного вида токена даже до того, как приступите к проверке утверждений.

Там может быть больше вариантов, чем это.