Проверка подлинности токена для обновления веб-API

Question

Я пишу веб-API, который будет вызываться из фонового сервиса для получения некоторых данных. После некоторых исследований я решил использовать веб-токен Json для достижения этой цели, но я все еще немного озадачен тем, когда следует запрашивать новый токен.

Допустим, я запускаю свой сервис, я запрашиваю токен, токен истекает через 15 минут, затем через 20 минут я делаю вызов API с токеном с истекшим сроком действия. Я получу несанкционированную ошибку или что-то в этом роде.

Мой вопрос: как клиент узнает, когда запросить новый токен? Должен ли он запрашивать новый перед каждым вызовом API? Похоже, я что-то упустил. Может быть, я должен сделать токен постоянным и сохранить его в базе данных?

Спасибо

Answer 1

Поскольку ваш клиент работает в фоновом режиме, вы можете использовать Oauth2 Client Credential Flow . Ваша фоновая служба может запрашивать токен доступа, используя только свои учетные данные клиента, когда клиент запрашивает доступ к защищенным ресурсам, находящимся под его контролем.

С этим потоком вам не нужно сильно заботиться об истечении срока действия токена, если клиент отправляет токен с истекшим сроком действия в web api, web api проверяет токен и создает токен, срок действия ответа которого истекает вашей службе, ваша служба проверяет код состояния / ответ, напрямую отправляет новый запрос токена в web api, чтобы получить новый токен доступа, нет необходимости использовать refresh token, который используется в других потоках.

Answer 2

Ответ на этот вопрос слегка зависит от приложения c, но в спецификации OAuth есть механизм для «refre sh tokens», который можно использовать для предоставления новых «токенов доступа» (токен, обычно включаемый в каждый API запрос), без необходимости отправлять пользователя в процесс аутентификации пользовательского интерфейса, чтобы они повторно аутентифицировались. Поэтому, как только вы запросите токен доступа, вы получите токен refre sh и токен доступа. Эта методология позволяет использовать токены доступа для гораздо более коротких периодов времени.

Это также можно сделать без refre sh токенов, но в этих случаях тайм-аут доступа к токену, вероятно, будет больше, и тогда вы бы запросили что пользователь повторно проходит аутентификацию через обычный процесс пользовательского интерфейса OAuth. Обратите внимание, что даже если у вас есть токены refre sh, токен refre sh также может быть установлен на expire, что потребует повторной аутентификации пользователя через пользовательский интерфейс.

В некоторых API вы просто сделайте запрос API как обычно, и если вы получите ответ, который определен API как ответ, указывающий, что токен доступа истек, вы можете затем выполнить вызов API, чтобы обновить sh токен (или полностью запросить новый, если срок его действия истек, или если у API нет refre sh tokens), а затем повторите исходный вызов API с новым токеном доступа.

API также может получить ответ, который включает в себя тайм-аут или дату / время истечения срока действия токена доступа. Затем клиент может избежать отправки начального вызова API первым и просто сначала отправить вызов токена refre sh.

При реализации вашего API вы, вероятно, можете использовать любую из этих методологий.

Вот некоторые общие обсуждения на веб-сайте OAuth spe c, чтобы дать более подробную информацию: https://www.oauth.com/oauth2-servers/making-authenticated-requests/

https://www.oauth.com/oauth2-servers/access-tokens/access-token-lifetime/

https://www.oauth.com/oauth2-servers/access-tokens/refreshing-access-tokens/

А также, вот пример из API Twitter относительно кодов ответов, показывающих один из методов истечения срока действия маркеров доступа (см. Раздел «Коды ошибок» в разделе код ошибки 89, который означает, что токен истек, и вам необходимо получить новый):

https://developer.twitter.com/en/docs/basics/response-codes