Подтвердить что ты не робот

Как определить, истек ли токен OAuth?

Мое мобильное приложение iOS использует сервисы, реализованные в протоколе OAuth2.0. Маркер доступа OAuth поставляется вместе с токеном обновления и поле expires_in. Я сохранил токен обновления и время истечения срока действия токена в своем приложении, но у меня нет хорошей идеи о том, когда их использовать.

  • Итак, какова обычная и лучшая практика использования этого expires_in?
  • Как определить, что мой токен доступа истек?
  • Существует ли общий формат ошибок веб-службы, в котором указано, что мой токен доступа истек?
4b9b3361

Ответ 1

Здесь информация о обновлении токена OAuth 2.0.

Истекает в определении

Стандарт OAuth 2.0, RFC 6749, определяет поле expires_in как количество секунд до истечения срока действия:

expires_in: РЕКОМЕНДУЕТСЯ. Время жизни в секундах токена доступа. Например, значение "3600" означает, что срок действия маркера доступа истечет через один час после создания ответа. Если опущено, сервер авторизации ДОЛЖЕН предоставить время истечения срока действия другими средствами или задокументировать значение по умолчанию.

Обработка обновления токена: метод 1

После получения действительного access_token, значения expires_in, refresh_token и т.д. Клиенты могут обработать это, сохраняя время истечения и проверяя его при каждом запросе. Это можно сделать, используя следующие шаги:

  1. преобразовать expires_in в время истечения (эпоха, expires_in время RFC-3339/ISO-8601 и т.д.)
  2. сохранить время истечения
  3. при каждом запросе ресурса access_token текущее время с временем истечения и делайте запрос обновления токена до запроса ресурса, если истек срок access_token

Примером реализации является библиотека Go oauth2 которая преобразует значение expires_in в дату-время RFC 3339 в свойстве expiry токена. expiry не определен стандартом OAuth 2.0, но полезен здесь.

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

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

Обработка обновления токена: метод 2

Другой метод обработки обновления токена - это ручное обновление после получения недопустимой ошибки токена. Это можно сделать с помощью предыдущего подхода или самостоятельно.

Если вы попытаетесь использовать просроченный access_token и у вас access_token ошибка токена, вам следует выполнить обновление токена (если ваш токен обновления все еще действителен). Поскольку разные службы могут использовать разные коды ошибок для маркеров с истекшим сроком действия, вы можете либо отслеживать код для каждой службы, либо простой способ обновить токены между службами - просто попробовать выполнить одно обновление при обнаружении ошибки 4xx.

Недопустимые ошибки токена доступа

Ниже приведены некоторые коды ошибок от популярных сервисов:

  1. Facebook: Ошибка 467 Недопустимый токен доступа - токен доступа истек, был отозван или недействителен по другой причине - Обрабатывать токены доступа с истекшим сроком действия.
  2. LinkedIn: ошибка 401 не авторизована.
  3. PayPal: ошибка 401 не авторизована.

Обновить срок действия токена

Если refresh_token действия refresh_token также истек, вам нужно будет снова пройти процедуру авторизации.

Спецификация OAuth 2.0 не определяет срок действия маркера обновления или способы его обработки, однако ряд API-интерфейсов вернет свойство refresh_token_expires_in когда токен обновления истечет. Разные API будут по-разному обрабатывать истечение срока действия маркера обновления, поэтому важно просматривать документы по API, но обычно вы можете получить новый токен обновления, когда обновляете свой токен доступа. Истечение срока действия должно обрабатываться аналогичным образом, например, путем преобразования refresh_token_expires_in в значение даты-времени refresh_token_expiry в RFC 3339.

Некоторые примеры включают LinkedIn, eBay и RingCentral. В API LinkedIn, когда вы обновляете токены доступа, вы получите токен обновления с уменьшающимся свойством refresh_token_expires_in нацеленный на первоначальное время истечения срока действия маркера обновления до тех пор, пока вам не понадобится refresh_token_expires_in. API-интерфейс RingCentral будет возвращать токены обновления со статическим временем, поэтому пользователю не придется снова выполнять аутентификацию, если обновления токенов и обновления токенов выполняются последовательно.

Ответ 2

Рекомендовал бы метод 2 выше, так как 401 может произойти по нескольким причинам, таким как продление сертификата подписи токена или разница часов:

  • Проверьте на 401 после каждого запроса API
  • Получить новый токен - только один раз
  • Повторите запрос API - только один раз

Я реализовал множество успешных клиентов OAuth и всегда использовал эту технику - и избегал когда-либо читать поле expires_in в моем коде на стороне клиента