2016-02-16 3 views
2

Я пытаюсь понять, должен ли мой веб-Api, поддерживаемый Owin, проверять сертификат, используемый для подписи JWT-токена.Проверка сертификата подписи при использовании OpenId Connect

Я установил поставщика удостоверений, используя IdentityServer. На стороне «полагающейся стороны» у меня есть ASP.NET WebApi, где используется Owin. На стороне RP я использую UseOpenIdConnectAuthentication для установки OpenIdConnectAuthenticationMiddleware в конвейере Owin.

Что работает до сих пор:

  1. Любой неаутентифицированное пользователя посетив веб-приложение будет перенаправлен на страницу входа на IdentityServer
  2. Пользователь регистрируется на
  3. пользователь перенаправляется обратно на мой веб-приложение
  4. Мое веб-приложение получает JWT, содержащий токен доступа и токен доступа
  5. Мое веб-приложение вызывает конечную точку информации пользователя, чтобы получить претензии, используя токен доступа

Отсутствует логика для проверки сертификата, который использовался для подписи JWT, содержащего токен идентификации.

Использование Фидлер, я был в состоянии видеть, что OpenIdConnectAuthenticationMiddleware получает ключи от сервера идентичности (вызывая https://myidentityserver.example.com/core/.well-known/jwks HTTP/1.1)

ли OpenIdConnectAuthenticationMiddleware выполнения какой-то проверки сертификата? Или я должен сам писать этот код?

ответ

0

Найдено некоторые пояснения here

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

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

+0

Я не думаю, что это действительно так. Похоже, что это используется, когда у вас есть только API, и вы предполагаете, что входящие запросы уже содержат токен с самого начала. В моем случае я хочу полный неявный поток. Кажется, что валидатор должен использоваться в потоке учетных данных владельца ресурса/клиента. – Martin

1

Поток вы охарактеризовали полагается о том, что сертификат проверки выведен из защищенной конечной точки TLS (URL-адрес JWK), который представляет действительный сертификат сервера SSL. Этот сертификат SSL-сервера гарантирует, что вы разговариваете с правильным провайдером OpenID Connect.

Смежные вопросы