Прежде чем разбирать OAuth 2.0 flows (grant types) - алгоритмы, давайте познакомимся с его ключевыми параметрами.
📌 Шаги в OAuth 2.0
👉 Запрос на авторизацию - получение code
GET .../oauth/authorize
?response_type=code
&client_id=...
&redirect_uri=...
&scope=...
&state=...
👉 Callback на ваш redirect_uri - получен code
GET https:// testapp .com/api/v1/auth/oauth/provider/callback
?code=/...
&state=...
👉 Обмен code на токены
POST .../oauth/token
grant_type=authorization_code&
code=...&
client_id=...&
client_secret=...&
redirect_uri=...
📌 Параметры:
1️⃣ response_type
Тип результата, который вы хотите получить на шаге авторизации - регулирует ответ на GET /authorize
Где используется:
В URL для GET /authorize
2️⃣ client_id
Публичный идентификатор приложения, который предоставляет провайдер OAuth 2.0 (Mail ru /Google и др) после его регистрации у себя.
Где используется:
+ в URL для GET /authorize
+ в теле POST /token
+ иногда в запросах на обновление токена или в других grant types
3️⃣ client_secret
Cекрет (пароль) вашего приложения, который предоставляет провайдер OAuth 2.0 после регистрации
Где используется:
чаще всего в POST /token
4️⃣ redirect_uri
Это URL, куда провайдер OAuth 2.0 возвращает пользователя после аутентификации
Пример:
Пользователь вводит логин и пароль от своего Google-аккаунта на безопасной форме от Google. После этого Google делает переход на redirect_uri
Кто формирует:
Владелец приложения, который будет использовать OAuth 2.0.
Он указывает его в настройках при регистрации.
Где используется:
+ в URL для GET /authorize
+ в теле POST /token
5️⃣ scope
Список прав/доступов, которые вы запрашиваете у пользователя.
Пример:
Ваше приложение запрашивает у пользователя доступ к его Google-аккаунту:
+ ФИО
+ почта
+ Google-диск, чтение
и др.
scope=profile,email,drive:read
Кто формирует:
Владелец приложения
Где используется:
В URL для GET /authorize
На что влияет:
+ какие данные/действия разрешены для access_token
+ что пользователь увидит в окне согласия на безопасной форме от провайдера OAuth
6️⃣ state
Случайная строка для защиты от подмены (CSRF атаки) и для связывания “запрос-ответ”
Кто формирует/проверяет:
Backend приложения, который использует OAuth 2.0
Где используется:
+ отправляется в URL для GET /authorize
+ возвращается провайдером в redirect_uri вместе с code или error
Backend генерирует state, сохраняет (в сессии/БД/кэше), потом сравнивает с ответами от OAuth 2.0 провайдера
Если state не совпал — считаем запрос из процесса авторизации атакой/ошибкой и прерываем его
7️⃣ code (authorization code)
Временный одноразовый код, который провайдер возвращает после успешного входа пользователя.
Он нужен, чтобы безопасно обменять его на токены (access/refresh) через POST /token
Где появляется:
В URL на вашем redirect_uri (callback) после логина.
🕘 Есть срок жизни:
Обычно короткий (минуты/часы)
8️⃣ access_token
Токен доступа к API провайдера (Resource Server).
Где появляется:
В ответе на POST /token.
Как используется:
В дальнейших запросах к API провайдера (Resource Server).
Пример:
Подписываем запрос на получение файлов с Google-диска пользователя с access_token.
🕘 Есть срок жизни:
Обычно короткий (минуты/часы)
9️⃣ refresh_token
Это “токен обновления”.
По нему можно получить новый access_token без повторного запроса логина+пароля у пользователя.
Где появляется:
В ответе на POST /token.
Но не всегда выдаётся провайдером и не всегда нужен.
Как используется:
в запросе POST /token с grant_type=refresh_token.
🕘 Есть срок жизни:
либо нет, либо длинный (месяцы/год)
🔟 token_type
Тип токена.
Чаще всего Bearer.
Где появляется:
В ответе на POST /token
1️⃣1️⃣ expires_in
Срок жизни access_token в секундах.
Где появляется:
в ответе POST /token
Как используется:
+ ваше приложение рассчитывает момент истечения: expiresAt = now + expires_in
+ когда время подходит, то приложение обновляет access_token через refresh_token (фоново) или заново ведёт пользователя на авторизацию
#ИнтеграцииGA
#FoodDeliveryGA_oauth