В настоящее время я пишу код для работы с oAuth (используя API Azure Graph, но я думаю, что API Google похожи).
Для вызова API мне нужен токен доступа, срок действия которого составляет около одного часа. Чтобы получить токен доступа, мне нужно сначала заставить пользователя авторизовать использование моего приложения, что дает код авторизации, срок действия которого составляет около десяти минут. Одновременно с получением токена доступа я также могу получить токен обновления, срок действия которого обычно составляет 90 дней. Хотя я могу получить новый токен обновления до истечения срока его действия, чтобы гарантировать сохранение действительного токена обновления.
Таким образом, существует три типа кодов/токенов, с которыми приходится иметь дело.
Зачем нужны все эти разные коды и токены? Почему бы просто не предоставить код авторизации со сроком действия 90 дней и покончить с этим?
Правильно ли я понимаю, что если срок действия моего токена обновления истечет, мне придется вернуться к началу цепочки и снова запросить доступ у своего пользователя?
решение1
Зачем нужны все эти разные коды и токены? Почему бы просто не предоставить код авторизации со сроком действия 90 дней и покончить с этим?
Код авторизации — один из нескольких способов доставки токена доступа — это не отдельный «шаг», а все еще часть начального потока «интерактивной аутентификации». Он отличается от фактического токена доступа тем, что для использования кода вам также понадобится секрет клиента OAuth2 (или вызов PKCE, который был сгенерирован в начале). Теоретически это означает, что даже если сам код перехвачен (например, через перенаправления, видимые на стороне клиента), только исходное приложение может обменять его на настоящий токен.
Существуют и другие потоки, которые его не используют — например, вы можете использовать поток «неявного предоставления» для прямого получения токена доступа или использовать сертификат для аутентификации и получения токена за один шаг, в зависимости от того, что поддерживает OAuth IDP.
(Например, «сервисные учетные записи» в Google проходят аутентификацию с использованием пары ключей RSA для получения токена доступа — они не используют интерактивный поток аутентификации, и поэтому код аутентификации отсутствует.)
Правильно ли я понимаю, что если срок действия моего токена обновления истечет, мне придется вернуться к началу цепочки и снова запросить доступ у своего пользователя?
Да, но именно избежание этого и является основной целью токена обновления.
Если бы у вас был только один тип токена (токен доступа), каждый раз, когда он истекал, вам нужно было бы возвращаться к началу цепочки. Обычно этого можно избежать, имея токен обновления, который обычно имеетнамного длиннеесрок действия, например, если токен доступа действителен в течение нескольких часов или дней, то токен обновления обычно действителен в течение месяцев или лет.
Я бы сказал, что 90 дней для токена обновления — это необычно мало и в какой-то степени сводит на нет смысл его наличия. Я предполагаю, что Azure OAuth2 специально настроен таким образом, чтобы принудительно проходить повторную аутентификацию с использованием более сложных для кражи учетных данных, таких как сертификат устройства или пользовательская схема HMAC, используемая «Windows Hello». (В отличие от этого, токены обновления, выпущенные Google, похоже, практически не имеют срока действия — я уже много лет использую один и тот же токен для доступа к Gmail IMAP.)
решение2
Существуют разные типы, поскольку они служат разным целям. Простая причина, по которой они у вас есть, заключается в том, что они могут быть скомпрометированы и использованы для разных целей. Поэтому их недолговечность гарантирует, что неправильное обращение или скомпрометированный клиент, хотя и все еще плох, могут потенциально иметь меньшее влияние.
Это также помогает, разделяя то, что делает то, что. Один токен будет означать, что вам нужно будет просто получить один токен и вы сможете делать все. Наличие нескольких токенов немного усложняет получение опции, чтобы делать все.
ВидетьRFC 6749для получения дополнительной информации о типах токенов.