Когда передать маркер обновления в API

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

  1. Должен ли клиент передавать маркер обновления при каждом вызове API вместе с маркером доступа или клиент должен передавать маркер обновления только после получения кода ошибки от API, что маркер доступа истек?
  2. Какой тип кода ошибки передается обратно клиенту после обновления маркера истек срок годности? Это означает, что клиент должен запросить новый маркер доступа, снова передав имя пользователя и пароль.
1 4
access-token asp.net-web-api2

1 ответ:

Вопрос 1:

Должен ли клиент передавать маркер обновления при каждом вызове API вместе с маркером доступа или клиент должен передавать маркер обновления только после получения кода ошибки от API, что маркер доступа истек?

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

Чтобы получить новый маркер доступа, вы отправляете запрос с grant_type, установленным в refresh_token, как в разделе 6 RFC.
В идеале, вы бы попросили новый маркер доступа до истечения срока действия текущего маркера доступа, чтобы не прерывать службу.

Большинство реализаций, которые я видел, выдают новый токен обновления скаждым токеном доступа . Вы можете использовать любой допустимый маркер обновления для получения нового маркера доступа.

Вопрос 2:

Какой тип кода ошибки передается обратно клиенту после истечения срока действия маркера обновления? Это означает, что клиент должен запросить новый маркер доступа, снова передав имя пользователя и пароль.

К сожалению, RFC явно не определяет ответ на ошибку; см. раздел 7.2 RFC:

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

Таким образом, точный ответ зависит от сервера. Он должен быть определен соответствующим сервером.

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

Вы не хотите отправлять учетные данные пользователя снова; вы не должны иметь их, не говоря уже о том, чтобы сохранить их. OAuth 2 был предназначен для предоставления третьим лицам доступа к защищенным ресурсам пользователя без просмотра учетных данных пользователя.

Обычно вы получаете новый токен обновления с новым токеном доступа в вызове password_grant или refresh_token. Стандарт не гарантирует.
Если сервер не выдает новые маркеры обновления или на них нельзя положиться, вам придется попросить пользователя снова войти в систему. Обратите внимание, что этот вход осуществляется через сервер авторизации, что не обязательно ваше приложение. На самом деле, скорее всего, нет.

3