📖🔖 Всё про 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 или info@getanalyst.ru.


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

🔑 Ключевые параметры 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 или info@getanalyst.ru.

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

🔥 Postman: подборка практических руководств по исследованию API 🔥

Документация ≠ реальность.

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

Он заранее подстраховывает разработчиков, уточняя нюансы, которых нет в API-документации внешней системы.


Что важно проверить аналитику для интеграции:
✅ Как работает аутентификация в API
✅ Успешную работу всех API-методов
✅ Протестировать ошибки (при авторизации, отсутствии данных и другие), чтобы понять, как внешняя система реагирует на нештатные ситуации


Делюсь с вами практическими руководствами по исследованию API внешних систем через Postman:

📹 Postman: навык тестирования REST API за вечер

📚 Тестирование API DaData

📚 Тестирование API Unisender

📚 Тестирование API банка ВТБ

📚 Тестирование API KudaGo и DashaMail

📚 Тестирование API ChatGPT

👉 В этих руководствах всё четко, с картинками и по шагам.

С ними вы сможете освоить Postman за выходные, и сразу же пополните своё портфолио несколькими коллекциями запросов 🙌


🔖 Сохраняйте пост в избранное,
чтобы пройти все руководства и получить реальный опыт для работы с задачами на интеграции


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

🎄 [27-30 декабря] Открытый интенсив по REST, GraphQL и gRPC с практикой в Postman 🎄

Cегодня всё реже бывает “только REST”.
В одном продукте REST остаётся публичным API, в другом GraphQL нужен, чтобы не таскать лишние поля в мобильные приложения, а внутри микросервисов всё чаще живёт быстрый gRPC.


Чтобы передать вам практический опыт работы с современными API и интеграциями, мы готовим для вас предпразничный интенсив:

⚡️ Интеграции по REST, GraphQL и gRPC через Postman

🗓 Доступ к записи: 27 - 30 Декабря
🕗 Время на обучение: 4 часа
(можно пройти в своём темпе, в удобное время)

🔗 Регистрация и подробности


Ваши результаты:
✅ Поймёте что такое интеграции и как с ними работать.
✅ Получите уверенную базу знаний по REST API, GraphQL и gRPC, и понимание, как её применить в работе аналитика.
✅ Научитесь читать любую API-документацию и быстро “раскладывать” методы по структуре.
✅ Освоите инструмент тестирования API - Postman.
✅ Получите практический опыт: сможете сами прогнать запросы и проверить ответы REST/GraphQL/gRPC по шагам.


Для кого
🟢 Системные аналитики, которым надо уверенно вести интеграционные задачи
🟢 Бизнес-аналитики, которые хотят понимать “под капотом” и формулировать сильные требования
🟢 Те, кто готовится к собеседованиям (REST/интеграции - база, GraphQL/gRPC - жирный плюс)


Эта практика - ваша возможность сделать огромный шаг в понимании работы с API и интеграциями.

Регистрируйтесь и входите в новый год с новыми навыками и сильными целями! 🎄🚀

------

👉 Интенсив проводится в поддержку практической программы Интеграции систем.

23 декабря завершается запись с лучшей ценой и с бонусным обучением по БД и SQL в подарок.

⚠️ С 2026 года в GetAnalyst планируется повышение цен на все программы, поэтому до 30 декабря — самый выгодный период для записи на обучение