Как клиент, использующий Owin / Katana / OIDC, использует токен обновления?

У меня есть веб-приложение ASP.net MVC, которое использует промежуточное ПО Microsoft Owin (Microsoft.Owin.Security.OpenIdConnect) для настройки аутентификации OpenID Connect. Мой поставщик удостоверений (Okta) настроен для поддержки токенов обновления, и я подтвердил, что он работает. При входе в систему мое приложение получает токен доступа, идентификатора и обновления, как и ожидалось. Эти токены проверяются и возвращаются клиенту в файле cookie с именем .AspNet.Cookies (по умолчанию). При каждом запросе cookie и эти токены разбираются в набор утверждений. Пока отлично. ????

Похоже, что промежуточное программное обеспечение Owin (Katana) больше ничего не делает с токеном обновления, поэтому я реализовал клиент токена для запроса нового токена доступа у моего IdP с помощью токена обновления. Это работает, как ожидалось. ????

Два вопроса:

  1. Когда и где приложение должно проверить, не истек ли токен доступа, и запросить новый?
  2. После получения нового токена доступа, идентификатора и обновления, как и где приложение должно обновлять удостоверение пользователя, утверждения и файл cookie?

asp.net-mvc openid-connect owin katana
person Mark Good    schedule 20.07.2020    source источник

Ответы (1)


arrow_upward
2
arrow_downward

ОБНОВЛЕНИЯ OWIN COOKIE

Я считаю, что комментарий в конце этого сообщения имеет тип кода, который вы можете написать - я помню, как использовал аналогичный код несколько лет назад.

С OWIN вы используете стек на стороне сервера, защищенный файлами cookie, поэтому я не уверен, где на самом деле используются токены доступа, но, может быть, один из них верен?

  • Серверная часть C # использует токены для вызова API.
  • Веб-интерфейс загружает токены из веб-сервера и выполняет Ajax-вызовы API.

ШАБЛОН ДЛЯ ОБРАБОТКИ ТОКЕНОВ С истекшим сроком действия

Единственный надежный шаблон для обработки истечения срока - это сделать это в клиентском коде API:

  • Когда вы получаете ответ 401 от API
  • Попробуйте обновить токен и повторите вызов API с новым токеном доступа.
  • Если вы не можете обновить токен, перенаправьте пользователя для повторного входа в систему.

Я всегда реализую это с помощью двух классов, как в этом моем коде SPA:

Если веб-интерфейс получает токены из веб-сервера, а затем вызывает API, ваш веб-интерфейс может предоставлять операции MVC, аналогичные тем, которые используются в моем классе аутентификатора:

  • getAccessToken - получить текущий токен доступа, хотя он может завершиться ошибкой с 401
  • refreshAccessToken - используйте это, если получено 401 и вам нужен новый токен

СРОК ЭКСПЛУАТАЦИИ ТОКЕНОВ

Также можно проверять время истечения срока действия токена в фоновом режиме - чтобы уменьшить количество клиентских 401. Однако это не полное решение, поскольку ошибки 401 могут возникать по другим причинам, помимо истечения срока действия.

person Gary Archer    schedule 20.07.2020
comment
Привет @Gary, спасибо за ответ! Я реализовал нечто очень похожее на этот ответ (stackoverflow.com/a/36992935/97276), на который вы ссылались, и пока он похоже, работает, похоже, он не обновляет файл cookie, поэтому при следующем обновлении токен в файле cookie все еще истек. Я надеялся, что .GetOwinContext (). Authentication.SignIn (newIdentity) запустит промежуточное программное обеспечение для установки нового файла cookie, но похоже, что оно это делает. Не уверен, что мне не хватает? - person Mark Good; 21.07.2020
comment
Возможно, вам не хватает флага AllowRefresh, как описано в здесь - person Gary Archer; 21.07.2020
comment
Я был очень взволнован, увидев этот комментарий, и надеялся, что это сработает, но это не так. Я открыл проблему с Okta на GitHub здесь: github.com/okta/okta-aspnet / issues / 130 - person Mark Good; 22.07.2020
comment
Я думаю, что комментарий Лауры о ReplaceIdentity - это ответ. Я знаю, что у меня это работало в моей последней компании - просто у меня больше нет доступа к исходному коду, и прошло много времени с тех пор, как я использовал технический стек. Я знал, что звонить в "Войти" было неправильно ... - person Gary Archer; 22.07.2020
comment
Привет @Gary. Спасибо за продолжение. Использование ReplaceIdentity не было ответом, потому что оно происходит после установки файла cookie, поэтому последующие запросы содержат старый файл cookie, утверждения и токены. Но я нашел отличное решение, похожее на то, на которое вы указали ссылку. Используйте метод .SignIn (), но вместо создания нового ClaimsIdentity используйте текущее удостоверение и просто удалите старые утверждения токенов и добавьте новые. Затем вызовите SignIn (), который запускает метод промежуточного программного обеспечения cookie, который срабатывает ДО того, как файл cookie будет создан. Задача решена! Я описываю это в ветке GitHub. - person Mark Good; 22.07.2020