Какие токены JWT следует хранить для дальнейшего использования?

Я смотрю на реализованный Cognito для входа пользователя и хотел бы немного лучше понять процесс проверки JWT.

Рассматриваемое приложение находится на asp.net 4.5 MVC и не связано с .NET Core. Единственная информация об AWS Cognito, которую я могу найти в Интернете, касается ядра .NET.

Я понимаю значение каждого типа токена, как описано здесь: https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html#amazon-ognito-user-pool-using-the-id-token.

Я также понимаю необходимые шаги для проверки JWT: https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-verifying-a-jwt.html

У меня вопрос: какой JWT нужно проверить и на каком этапе?

Пример 1.
Пользователь входит в систему, после входа в систему ему возвращаются токены доступа, идентификатора и обновления.
Все ли токены должны быть проверены на этом этапе или только токен доступа?

Проверяется ли токен обновления только перед попыткой его использования (для получения новых токенов доступа и идентификатора)?
ИЛИ должны ли все токены проверяться при любом авторизованном запросе контента?

Какие токены должны храниться в файле cookie FormsAuthentication для дальнейшего использования? Мы используем стандартный шаблон [Authorize] в asp.net.


authentication jwt asp.net-mvc amazon-cognito jwt-auth
person StuartM    schedule 17.01.2020    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Вопрос: Все ли токены должны быть проверены на этом этапе или только токен доступа?

Ответ. Проверка всегда выполняется только по токену доступа.

Сам токен обновления не нужно проверять. Он просто используется для получения нового набора идентификаторов и маркеров доступа.

Вопрос: Какие токены следует хранить в файле cookie FormsAuthentication для дальнейшего использования?

Ответ: Это относится к реализации. Нет правила, какой токен нужно сохранять.

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

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

Если требуется предоставить пользователю доступ к ресурсу на срок до 30 дней без запроса пароля, то необходимо сохранить токен обновления.

person Gopinath    schedule 26.01.2020
comment
Спасибо @Gopinath. Требуется, чтобы пользователь оставался в системе в течение периода времени, в течение которого токен доступа доступен до (зависит от конфигурации IDP). Следовательно, стоит ли сохранять токен доступа? Более того, нужно ли нам проверять этот токен при каждом запросе страницы [Authorize] или мы проверяем его только при первоначальном получении токена от IDP? - person StuartM; 27.01.2020
comment
Спасибо, @StuartM. В этом случае, когда пользователю разрешается оставаться в системе на протяжении срока действия токена доступа, только токен токена доступа должен быть сохранен и подтвержден для каждого входящего запроса, сделанного из пользовательского интерфейса в серверную часть. Маркер может быть сохранен двумя способами - либо как файл cookie, либо как встроенный «Заголовок авторизации» (обычно называемый токеном-носителем). Серверная часть должна будет проверять токен, выбранный из файла cookie или из заголовка авторизации, для каждого входящего запроса, поступающего из пользовательского интерфейса. Это защищает весь путь пользователя, а также позволяет легко предлагать пользователю войти в систему по истечении срока действия токена. - person Gopinath; 27.01.2020
comment
спасибо, следует ли установить срок действия cookie на дату / время истечения срока действия токена доступа? Должен ли я защищаться от этого изменения, по соображениям безопасности, проверять токен и вместо этого проверять дату истечения срока его действия? - person StuartM; 28.01.2020
comment
Да, Стюарт. Ты прав. Установка срока действия cookie, соответствующего сроку действия токена, является хорошей практикой. Это повысит безопасность, а также сократит количество ненужных обращений к серверу. - person Gopinath; 28.01.2020

arrow_upward
0
arrow_downward

Рекомендуемый подход - проверить токен доступа, поскольку он включает как аутентификацию, так и авторизацию. Перед предоставлением доступа к защищенным ресурсам вы должны проверить токен доступа.

Токен id содержит утверждения (информацию) аутентифицированного пользователя. Его также можно использовать для проверки, но использование токенов доступа дает больше возможностей, поскольку вы можете создавать области для определения разрешений и ролей. Маркер доступа также является входом для многих пользовательских операций Cognito API.

AWS Cognito следует протоколу OpenID Connect, основанному на протоколе Oauth2, для которого возникла эта терминология.

Токен обновления - это долгоживущий токен для получения новых короткоживущих токенов (токен идентификатора, токен доступа). В настоящее время с реализацией Cognito срок действия более короткоживущих токенов истекает каждые 1 час, а токены обновления настраиваются в пользовательском пуле. В случае, когда токен обновления становится недействительным / просроченным, попытки получить новые недолговечные токены завершатся ошибкой, поэтому вам не нужно проверять токен обновления самостоятельно.

Вы можете сохранить токен обновления (в каком-то сеансе), чтобы помочь с получением нового доступа, токенов идентификатора без повторной аутентификации. Вы также можете сохранить токен доступа, чтобы токен обновления использовался только один раз в час (когда срок действия токена доступа истекает), чтобы предотвратить выдачу ненужных токенов и циклических обращений к Cognito. Хранилище токенов id действительно зависит от вашего варианта использования, если вы заинтересованы в сохранении утверждений пользователя (информация о пользователе, хранящаяся в JWT токена id).

person Armin    schedule 22.01.2020