📖🔖 Всё про OAuth 2.0 с примером за 3 минуты 📖


👉 OAuth 2.0 — это стандарт, который позволяет вашему приложению получить ограниченный доступ к данным пользователя во внешнем сервисе без передачи пароля


👉 Ключевая идея на примере FoodDeliveryGA

✅ пользователь логинится в приложении FoodDeliveryGA и подтверждает доступ к его личным данным на стороне внешнего сервиса (Mail.ru) - через его безопасную web-форму

✅ FoodDeliveryGA получает токены доступа и работает дальше через API

❌ пароль пользователя от Mail.ru приложению FoodDeliveryGA никогда не передают


👉 Роли в OAuth 2.0
на примере FoodDeliveryGA

▫️Resource Owner (Владелец ресурса) — пользователь
Человек, который хочет войти в приложение FoodDeliveryGA и даёт согласие на доступ к его данным в Mail.ru для этого приложения

▫️Client (Клиент) — приложение FoodDeliveryGA
Frontend + Backend (в зависимости от схемы), которое инициирует авторизацию

▫️Authorization Server (Сервер авторизации) — Mail.ru
На предоставляемой им web-форме пользователь вводит логин/пароль Mail.ru и подтверждает доступ к данным

▫️Resource Server (Сервер ресурсов) — API Mail.ru
Методы REST API, где лежат данные пользователя (например, профайл / user info, информация о друзьях, посты на стене в социальной сети Мой Мир и другие данные).
Эти методы мы вызываем с использованием токена, который получили после аутентификации пользователя

💡 Часто Authorization Server и Resource Server находятся “в одном провайдере” (как Mail.ru), но логически это разные роли и с точки зрения Mail.ru это разные сервисы (сервера)


👉 Алгоритм работы OAuth 2.0 по шагам на картинке
для Grant Type=authorization_code


👉 OAuth 2.0 Grant Types - алгоритмы
authorization_code
refresh_token
client_credentials
implicit
password
device_code


👉 Ключевые параметры OAuth 2.0
для API-методов (в URL и JSON)

response_type
client_id
client_secret
redirect_uri

scope
state

refresh_token
access_token
token_type
expires_in

Зависят от Grant Type


Продолжение в следующих постах #FoodDeliveryGA_oauth 🚀

#ИнтеграцииGA

🧩 22 декабря | Маппинг данных: БД и JSON 🧩

Если вы хоть раз описывали интеграцию или требования к REST API-методу, то возможно вам знакомо:
- в БД одно, в JSON другое, а на UI третье,
- «а почему поле так называется»,
- «а откуда берём значение»,
- «а что если null»,
- «а как это маппить в требованиях».


Чтобы закрыть эти вопросы раз и навсегда и уверенно чувствовать себя в связке JSON ↔ БД, приглашаю вас на онлайн-практикум 👇

🧩 Маппинг данных: БД и JSON
🗓 22 декабря, 19:00 Мск

👉 Записаться на практикум
Стоимость участия от 1390 рублей


✅ Запись будет опубликована в платформе на следующий день после занятия
🎁 Занятие в записи по использованию AI для проектирования БД + SQL


План:
1. Знакомство с JSON
2. Практика формирования JSON для API методов на основе БД и дизайна UI
3. Описание маппингов данных
4. Автоматизация задачи с использованием AI-инструментов


В результате практикума вы:
✔️ Поймёте, как связать UI → JSON → БД в одну логичную схему
✔️ Заберёте себе понятный подход, как оформлять маппинг в требованиях
✔️ Получите практический опыт, который можно сразу применять в работе


По вопросам можно написать @getanalyst или [email protected].


До встречи онлайн! 🤩

🔑 Ключевые параметры OAuth 2.0 🔑

Прежде чем разбирать 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

🔔✅ Сегодня в 19:00 Мск | Маппинг данных: БД и JSON ✅🔔

Онлайн-практикум для системных и бизнес-аналитиков, которые хотят научиться самостоятельно проектировать и описывать JSON-объекты с нуля.

Этот навык даст вам уверенность
+ в рабочих задачах на API и интеграции,
+ в общении с разработчиками,
+ а также на собеседованиях при решении задач на REST API и понимание БД/SQL.

👉 Что получите:
1. Структурированные знания о JSON и его связи с БД+UI
2. Опыт проектирования JSON с нуля под реальные API-методы
3. Опыт разработки маппингов для интеграций Frontend-Backend-Внешние системы
4. Понимание, как применять AI-инструменты


📚 Материалы, которые заберёте:
✔️ Руководство по JSON
✔️ Подборка шаблонов для описания маппинга
✔️ Подборка примеров постановок задач с маппингом
✔️ Оптимизированный промпт для работы с AI + разбор его настроек


📹 Можно посмотреть в записи - будет доступна на следующий день после эфира

🎁 Занятие в записи по использованию AI для проектирования БД + SQL


🧩 Маппинг данных: БД и JSON
🗓 22 декабря, 19:00 Мск

🔗 Записаться на практикум
Стоимость участия от 1390 рублей


По вопросам можно написать @getanalyst или [email protected].

До встречи онлайн! 😌