Как сервер идентификации проверяет токен в API или когда мы используем атрибут авторизации?

Я использую Identity Server 4 в качестве поставщика удостоверений.

Получив токен для успешного входа в систему, мы передаем этот токен на сервер ресурсов.

У меня вопрос: как провайдер Identity Server на стороне сервера ресурсов проверяет отправленный токен?

Когда я наблюдал за трафиком с помощью fiddler, я не видел ни одного запроса, отправляющего токен провайдеру для проверки.

Что означает, что провайдер Identity Server на стороне сервера ресурсов сам проверяет токен?

Тогда зачем нам предоставлять Власть, если она не проверяет ее?

Как провайдер сервера идентификации в конце ресурса убеждается, что он выпущен действительным провайдером токенов?


person Mahesh Gupta    schedule 08.03.2017    source источник


Ответы (2)


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

Вы можете настроить своего клиента для запроса reference tokens (и настроить свой API для их приема), и эти токены будут включать круговой обход каждый раз, когда они используются. Затем у вас есть возможность отзывать токены, чего нельзя сделать с JWT.

person Mashton    schedule 08.03.2017
comment
Так как же происходит проверка подписи? Обязательно ли хранить какой-то ключ на сервере ресурсов для проверки текста на соответствие подписи? - person Ankush Jain; 08.12.2020
comment
jwt.io/introduction - person Mashton; 15.12.2020
comment
Конечная точка обнаружения Identity Server - это то, что я искал, потому что у нее есть информация об открытом ключе RSA. - person Ankush Jain; 16.12.2020

Сервер ресурсов не будет отправлять токен по сети провайдеру удостоверений для проверки токена. Это приведет к значительным накладным расходам для вашего сервера ресурсов.

Вместо этого сервер ресурсов извлекает (и может кэшировать) ваш документ обнаружения поставщиков идентификаторов, расположенный по адресу {identityserverUrl}./well-known/openid-configuration. Этот документ содержит материалы, которые позволяют серверу ресурсов проверять токен в своем собственном контексте. Это, конечно, при условии, что токен является access_token (_2 _, _ 3_)

Если ваш сервер ресурсов использует что-то вроде промежуточного программного обеспечения JwtBearerAuthentication или промежуточного программного обеспечения IdentityServer4.AccessTokenValidation, эти вещи сделают это за вас.

person Lutando    schedule 08.03.2017