Назначение идентификационного токена - PullRequest
1 голос
/ 28 октября 2019

После того, как RP получит токены (токен ID / доступа / обновления) от OP и проверит токен идентификатора, должен ли RP хранить токен идентификатора в сеансе владельца ресурса?

Если да, для какой целиидентификатор токена используется?

Я думаю, что токен доступа и обновления должен храниться по следующей причине, например:

  • токен доступа: используется для получения информации о пользователе из Userinfoконечная точка.
  • Обновить токен: используйте для получения другого токена доступа после истечения срока действия токена доступа.

1 Ответ

1 голос
/ 28 октября 2019

Ответ зависит от провайдера идентификации (Google, Auth0, IBM, Twitter и т. Д.).

В OAuth 2.0 возвращаются два токена: токен доступа и опционально токен обновления.

Токен доступа используется для авторизации доступа. Это может или не может позволить вам получить доступ к идентификационной информации из конечной точки userinfo. Идентификационный токен содержит эту информацию. Токен доступа может быть либо непрозрачным токеном, что означает, что в токене не хранится информация, которую вы можете декодировать, либо он является подписанным JWT. Количество и тип информации зависят от провайдера идентификации. Токены доступа кратковременны и истекают, как правило, через 3600 секунд. Нет необходимости хранить токен доступа, за исключением локального кэширования, поскольку токен теряет свою ценность после истечения срока его действия.

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

OIDC (OpenID Connect) добавляет идентификатор поверх OAuth 2.0. OIDC предоставляет Identity Token, который предоставляет информацию о пользователях, запрошенную областями OAuth и утвержденную пользователем, которому принадлежит идентификационная информация. Большинство поставщиков удостоверений реализуют OIDC со своей реализацией OAuth. Токены Identity также истекают и могут быть отозваны.

В Google Cloud вы можете использовать Identity Token для предоставления доступа на основе идентификации. Вы назначаете удостоверение (адрес электронной почты) с ролями для службы (экземпляр Compute Engine или объект Cloud Storage). Если HTTP-заголовок «Authorization: Bearer» присутствует, действителен и соответствует адресу электронной почты, то доступ предоставляется в соответствии с ролями, назначенными для идентификатора этой службы.

Хранить в хранилище - плохая практикаТокены OAuth в веб-сеансе, если они не зашифрованы уникально для каждого сеанса. Рекомендуется хранить токены OAuth в базе данных и искать их при необходимости с помощью непрозрачного идентификатора, хранящегося в веб-сеансе.

Не все поставщики удостоверений поддерживают токены обновления для всех типов грантов OAuth. Это называется «автономным» доступом, который может быть отклонен, что означает, что после истечения срока действия токена доступа пользователю потребуется снова авторизовать ваше приложение.

...