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

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

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

person webworm    schedule 30.01.2017    source источник


Ответы (1)


Вопрос 1:

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

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

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

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

Вопрос 2:

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

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

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

Итак, точный ответ зависит от сервера. Он должен определяться рассматриваемым сервером.

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

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

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

person S.L. Barth    schedule 30.01.2017
comment
Я понимаю, что вы говорите об истечении срока действия токена доступа, однако в конечном итоге срок действия токена обновления истечет. На этом этапе клиенту необходимо будет повторно пройти аутентификацию с учетными данными. - person webworm; 30.01.2017
comment
@webworm Я обновил свой ответ. В большинстве случаев срок действия токена обновления намного больше, чем у сеанса. В этих случаях не проблема попросить пользователя снова войти в систему. - person S.L. Barth; 30.01.2017