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

Эпизод будет полезен системным аналитикам, кто работает с Backend, API и интеграциями, а также тем, кто только начинает осваивать эту область. Кроме того, он станет отличным ресурсом для подготовки к собеседованиям, помогая освежить теоретические знания и понять практические аспекты безопасности в API.

00:19 - Когда системный аналитик встречается со сценариями авторизации в системе.
2:51 - Предварительные шаги процесса авторизации: идентификация и аутентификация.
8:19 - Секретный ключ для работы с API - Token для подписания запросов.
9:23 - Понятие авторизации запросов к API.
14:25 - Постановки задач на разработчиков, связанные с авторизацией пользователей в системе.
15:53 - Задачи на авторизацию при проектировании собственного API, например - REST API.
24:12 - Задачи на авторизацию при проектировании интеграций с внешними системами. Особенности процесса авторизации для приложений и пользователей.
34:20 - Способы авторизации в API. API-key.
40:26 - Basic Authorization
45:22 - Bearer Token
48:47 - JWT Token (JSON Web Token)
50:00 - OAuth 2.0
55:54 - Подведение итогов и рекомендации.

Ведущая:
Екатерина Ананьева

Чек-лист требований:
Авторизация при проектировании собственного API

Этот чек-лист поможет системному аналитику проверить, что учтены все требования к авторизации при разработке собственного API. Чек-лист покрывает только Backend-часть системы.

1. Выбрать подход к авторизации приложений и пользователей в системе

Basic Authorization
API-KEY
Bearer Token
JWT Token
OAuth 2.0
mTLS
или другой.

2. Разработать сценарий первичного входа пользователя в систему

✔ Определен способо идентификации пользователя (email, телефон, login или другой параметр)
✔ Определен способ аутентификации (пароль, OTP-код, из комбинация или другой способ)
✔ Если способ аутентификации включает генерацию временного секретного кода, то алгоритм его генерации, хранения в БД и времени жизни должен быть разработан и описан
✔ Решить, будет ли идентификация и аутентификация пользователя в одном или двух разных методах API
✔ Спроектирован механизм получения секретного ключа (токена), если это необходимо. Иначе предполагаем, что логин и пароль пользователя передаются в каждом запросе, как, например, в Basic-авторизации или при использовании API-key.

3. Описать требования к оработке ошибок при аутентификации

✔ Обработан сценарий, если аккаунт зарегистрирован, но не подтвержден (перенаправление на подтверждение email/телефона)
✔ Определена логика работы с блокировкой аккаунта при нескольких неудачных попытках входа
✔ Всегда возвращается ошибка HTTP-401 на ошибку входа, когда пользователь ввел неверные логин и пароль

4. Разработать сценарий авторизации всех запросов к API от пользователя после аутентификации в системе

✔ Определена отдельная статья требований для авторизации API-запросов
✔ В каждой статье с требованиями к API-методу указаны роли пользователей и их уровни доступа. Шаблон постановки задачи можно посмотреть по ссылке https://t.me/getanalysts/2237

5. Определить требования к хранению данных для авторизации

✔ Где и как хранятся данные о пользователях: логины, пароли
✔ Где и как хранятся пароли пользователей (хэширование, алгоритм)
✔ Где и как хранятся токены для подписания запросов к API, если это необходимо

6. Работа с секретными ключами (механизм ре-авторизации - повторная авторизация после окончания срока жизни секретного ключа для подписания запросов к API)

✔ Определена продолжительность жизни ключей (bearer token, jwt token, access token, refresh token и другие)
✔ Указано, что делать, если ключ устарел: принудительный выход пользователя из аккаунта, фоновая ре-авторизация
✔ Определен механизм обновления ключей клиентами для подписания запросов к API (токенов), без повторного запроса логина и пароля от пользователя, если это возможно

7. Процесс регистрации

✔ Определен механизм выдачи первичного ключа (токена) для подписания запросов к API сразу после регистрации, если это необходимо
✔ Реализована верификация email/телефона перед первым входом в систему, если это необходимо

8. Восстановление пароля

✔ Определено, что делать с текущими активными сессиями, если пользователь восстанавливает пароль: сбрасывать или оставлять открытыми
✔ Определен способ направления кода подтверждения: почта, телефон, другое устройство или иной способ

9. Выход из системы и деактивация ключей

✔ Определен механизм выхода пользователя из аккаунта - метод деавторизации по API: например, удаление текущего активного токена сессии (ключа сессии)
✔ Продумана логика выхода из всех сессий пользователя, если это необходимо по функциональности системы

Чек-лист требований:
Авторизация при интеграции с внешней системой

Этот чек-лист поможет системному аналитику проверить, что учтены все требования к авторизации при разработке требований к интеграциям с внешними системами. Чек-лист покрывает только Backend-часть системы.

1. Авторизация пользователя во внешней системе, когда он работает с нашим приложением

✔ Описан механизм аутентификации приложения и пользователя во внешней системе по нескольким факторам. Например:

✔ Определен сценарий авторизации запросов к API внешней системы после аутентификации пользователя
✔ Определен сценарий повторного получения ключей при устаревании: фоновая ре-авторизация или запрос повторного ввода логина и пароля пользователем
✔ Определена логика выхода из учетной записи пользователя во внешней системе (деавторизация)

2. Авторизация только нашего приложения во внешней системе, без необходимости авторизации пользователя

✔ Определен метод технической авторизации во внешней системе (API-ключ, логин/пароль, OAuth-токен или другой способ авторизации)
✔ Спроектирован механизм автоматического фонового обновления устаревших API-ключей (токенов), если это необходимо
✔ Определено, требуется ли деавторизация нашего приложения в определенные моменты взаимодействия с внешней системой (обычно не нужна)

Способы авторизации в API на примерах в Postman

Ссылка на инструмент Postman для тестирования и документирования API.

API Key

Basic Authorization

Bearer Token

JWT (JSON Web Token)

OAuth 2.0

OAuth 2.0 — это стандарт авторизации, который позволяет приложениям получать ограниченный доступ к ресурсам на сервере от имени пользователя, без необходимости передавать учетные данные пользователя (например, логин и пароль).

Этот процесс включает несколько шагов:

1️⃣ Клиент (например, Postman) отправляет пользователя на страницу авторизации (например, от Google).

Пользователь переходит по ссылке на сайт, где вводит свои логин и пароль.

Пример запроса:
GET https://auth.example.com/oauth/authorize?response_type=code&client_id=YOUR_CLIENT_ID&redirect_uri=https://yourapp.com/callback&scope=read 

2️⃣ Пользователь подтверждает доступ.
На стороне авторизационного сервера пользователь вводит свои данные (например, логин и пароль).

3️⃣ Авторизационный сервер возвращает код авторизации
После успешного входа пользователя сервер перенаправляет его обратно на указанный в настройках redirect_uri, добавляя параметр code.

Как выглядит редирект в браузере:
https://yourapp.com/callback?code=AUTHORIZATION_CODE 

4️⃣ Клиент обменивает код авторизации на токен:

Теперь ваш сервер (в примере - Postman) делает запрос на авторизационный сервер (в примере - Google) для получения токена.

Пример запроса:

POST https://auth.example.com/oauth/token?grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=https://yourapp.com/callback&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET
Content-Type: application/x-www-form-urlencoded

5️⃣ Сервер возвращает токен в JSON-ответе.

6️⃣ Клиент использует токен для доступа к защищённым ресурсам с префиксом Bearer или иным в заголовке запроса.

Следите за анонсами подкаста в Telegram!