OAuth 2.0 на собеседовании системного аналитика

Зачем OAuth знать СА

OAuth 2.0 — стандарт авторизации для интеграций. Без него любой service-to-service или user-to-service запрос проектируется небезопасно. Системный аналитик описывает интеграции в ТЗ, и без OAuth-словаря на собесе в банке/финтехе/маркетплейсе делать нечего.

Базовые термины

• Resource Owner — пользователь (владелец данных)
• Client — приложение, которое хочет получить доступ
• Resource Server — сервер с API, защищённым OAuth
• Authorization Server — сервер, выдающий токены (часто = Resource Server в малых системах)

Пример: пользователь хочет, чтобы новое приложение постило фото в его Instagram. User = Resource Owner, новое приложение = Client, Instagram API = Resource Server, Instagram OAuth = Authorization Server.

Authorization Code Flow

Главный flow для веб-приложений и mobile-приложений с серверной частью.

Шаги:

1. Client редиректит User на Authorization Server: GET /authorize?response_type=code&client_id=...&redirect_uri=...&scope=read:photos
2. User логинится в Authorization Server и подтверждает разрешение
3. Authorization Server редиректит обратно на redirect_uri?code=ABC123
4. Client (с серверной части!) обменивает code на access_token: POST /token с grant_type=authorization_code&code=ABC123&client_secret=...
5. Получает access_token (и обычно refresh_token)
6. Использует access_token в Authorization: Bearer ... для запросов к Resource Server

Зачем 2 этапа (code → token), а не сразу token? Потому что code передаётся через браузер (видим), а token обменивается через серверный канал (защищённый client_secret).

Authorization Code с PKCE

PKCE (Proof Key for Code Exchange) — расширение для public clients (mobile, SPA). Защищает от перехвата code злоумышленником.

Шаги отличаются от обычного flow:

1. Client генерирует случайный code_verifier и его хэш code_challenge
2. В /authorize отправляет code_challenge
3. После получения code обменивает его на token, прикладывая исходный code_verifier
4. Authorization Server сверяет code_verifier с code_challenge

Без PKCE злоумышленник, перехвативший code, мог бы обменять его на token. С PKCE ему нужен ещё code_verifier, который не передавался по сети.

В 2026 PKCE — обязательная практика для всех authorization code flows, не только public clients.

Client Credentials Flow

Для service-to-service. Нет user, есть только client.

POST /token
grant_type=client_credentials&client_id=...&client_secret=...

Возвращает access_token. Используется когда:

• Backend пишет в API другого backend
• Cron job обращается к API
• Microservice вызывает microservice

Refresh token обычно не возвращается — повторно запрашиваем через client_credentials.

Refresh tokens

Access token живёт коротко (15-60 минут). Refresh token — долго (дни-месяцы). Когда access expired:

POST /token
grant_type=refresh_token&refresh_token=...

Возвращает новый access_token (и часто новый refresh_token — refresh rotation).

Зачем разделение:

• Если access token утёк — мало времени на эксплуатацию
• Refresh token хранится только на сервере client (или в secure storage mobile-приложения)

OIDC и JWT

OIDC (OpenID Connect)

OAuth — про авторизацию (что разрешено). OIDC — про аутентификацию (кто пользователь). OIDC — слой поверх OAuth.

Главное добавление — id_token в формате JWT, который содержит информацию о пользователе (sub, email, name).

Используется для «Войти через Google», «Войти через Yandex».

JWT (JSON Web Token)

Формат токена. Состоит из 3 частей через точку:

eyJhbGciOiJIUzI1NiI... . eyJzdWIiOiIxMjMi... . SflKxwRJSMeKKF2QT...

• Header — алгоритм подписи, тип
• Payload — claims (sub, exp, iat, и кастомные)
• Signature — подпись header+payload секретом

Главное правило — JWT не зашифрован, а подписан. Любой может прочитать payload, но не может подделать без секрета.

Стандартные claims:

• sub — subject (обычно user_id)
• iss — issuer (кто выдал)
• aud — audience (кому предназначен)
• exp — expiration timestamp
• iat — issued at timestamp

Частые ошибки

Использовать access token в URL. URL логируется в access logs, в браузерной истории. Токен только в headers.

Хранить client_secret в frontend. Secret должен быть только на серверной стороне. Для public clients — PKCE.

Не валидировать JWT signature. Если просто читаете payload без проверки подписи — токен можно подделать.

Долгий access token. Если access живёт 24 часа — компрометация даёт долгое окно атаки. Стандарт — 15-60 минут access + длинный refresh.

Использовать localStorage для refresh. Уязвимо к XSS. Лучше httpOnly cookie с SameSite=Strict.

Не использовать PKCE для public clients. В 2026 это уже обязательно по best practices.

FAQ

OAuth 2.0 vs OAuth 2.1?

OAuth 2.1 — консолидация best practices. Запрещает Implicit Flow и password grant, требует PKCE, требует exact match для redirect_uri. По концепции — то же, что OAuth 2.0 + правильные настройки.

Implicit Flow всё ещё используется?

Нет. Запрещён в OAuth 2.1, заменён на Authorization Code + PKCE.

Где можно практиковаться с OAuth?

Auth0, Okta, Yandex OAuth, Google OAuth — у всех есть docs и тестовые приложения. На собесе спросят про реальные интеграции — тестовое приложение «Войти через Google» закрывает эту тему.

Это официальная информация?

Нет. Статья основана на RFC 6749, RFC 7636 (PKCE), OpenID Connect Core и опыте кандидатов.