Когда вы решите использовать JWT, примите природу JWT. Это означает, что единственный способ получить информацию в режиме реального времени - истечь токен, когда информация устарела. Установите время жизни токена доступа в маленьком окне, например, менее пяти минут. Таким образом, вы знаете, что информация всегда действительна, и вам не нужно ничего менять в текущей обработке. Это «почти в режиме реального времени», так как изменения вступают в силу в течение пяти минут.
Преимущество короткого срока службы заключается в том, что это также повышает безопасность вашего сайта. Когда токен скомпрометирован, его можно использовать только в течение короткого времени.
Вам нужно будет добавить поддержку для маркера обновления, потому что вы не хотите, чтобы пользователь заходил каждые пять минут. Поэтому, когда срок действия маркера доступа истекает, используйте токен обновления для запроса нового токена доступа. Это будет работать только для приложений, которые могут держать в секрете. Потому что токен обновления очень мощный, и вы не хотите, чтобы он попал в чужие руки. Вы можете использовать только одноразовые токены обновления, чтобы ограничить риски и добавить стратегии для обнаружения различного поведения. Для более подробной информации читайте мой ответ здесь .
Вы также можете удалить заявки на авторизацию из JWT и перенести авторизацию на ваше промежуточное ПО, где вы можете в реальном времени проверять разрешения пользователя. В этом случае JWT включает только заявки пользователей, которые идентифицируют и моделируют пользователя. Претензии, которые вряд ли будут меняться очень часто. В результате токен доступа не должен быть недолговечным, но по соображениям безопасности я думаю, что это все еще рекомендуется.
Минимальное требование - претензия sub или userid. Этого достаточно, чтобы идентифицировать пользователя и предоставить пользователю доступ к веб-сайту.
Я думаю, что Policy Server является хорошим примером возможной реализации авторизации промежуточного программного обеспечения. Здесь промежуточное ПО считывает разрешения из файла json и добавляет разрешения в качестве заявлений на удостоверение. Где политики решают, что пользователю разрешено делать. Также реализуйте авторизацию на основе ресурсов .
Альтернативой является использование эталонных токенов , как это реализовано IdentityServer. IdentityServer сохраняет содержимое токена в хранилище данных и выдает клиенту только уникальный идентификатор для этого токена. API, получающий эту ссылку, должен затем открыть связь по обратному каналу с IdentityServer для проверки токена.
Преимущество здесь в том, что вы можете отозвать эталонный токен в любое время, используя конечную точку отзыва.