Аутентификация Owin: токен SSO против токена ID

Question

Я реализовал вход в Microsoft в своем веб-приложении ASP. NET. Все работает как задумано, но я изо всех сил пытаюсь понять, как работают сеансы. Я использую промежуточное ПО OWIN и соединение OpenID.

1. В чем разница между SSO-Token и ID-token? Какой из них позволяет мне оставаться в системе?

2. Что произойдет, если я попытаюсь получить доступ к утверждениям (например, userClaims? .FindFirst (System.Security.Claims.ClaimTypes.sid) ?. Value) из токен с истекшим сроком действия?

3. Как! Request.IsAuthenticated понимает, что текущий пользователь аутентифицирован после входа в систему Microsoft? Это потому, что Generic Identity теперь является идентификатором утверждений, который возвращает true?

4. Если я вошел в систему и продолжаю обновлять сайт, в какой момент я буду вынужден аутентифицироваться очередной раз? И что контролирует на этот раз?

Я понимаю, что такое ID-токен, и что он содержит утверждения, и как я получаю доступ и использую утверждения. Я просто не понимаю, как работает сеанс после того, как пользователь вошел в систему со своей учетной записью Microsoft.

Answer 1

1. Нет токена SSO. Токен id представляет собой доказательство аутентификации, и в него включена некоторая базовая c информация о пользователе. Таким образом, ваше веб-приложение может получить имя, адрес электронной почты и т. Д. c.

2. Срок действия основан на auth cook ie, которую выдают библиотеки MS. Он привязан к другому токену, токену refre sh, который представляет время сеанса.

3. Токен id имеет цифровую подпись, которая криптографически проверена. Также ваше приложение предоставляет секрет клиента, чтобы гарантировать, что токенам можно доверять.

4. Cook ie получает срок действия, связанный с токеном refre sh. Когда срок действия повара ie истекает, пользователь должен снова войти в систему.

ДЛЯ ЛУЧШЕГО ПОНИМАНИЯ

Я настоятельно рекомендую отслеживать сообщения с помощью такой инструмент, как Fiddler, как в этом сообщении в блоге мое.

Лично я предпочитаю одностраничные приложения, которые используют только токены, а не файлы cookie. Они делают аспекты OAuth более понятными, а код может быть проще, хотя есть еще много тонкостей.