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

Зачем спрашивают на собесе SA

OAuth — стандарт авторизации, фундамент SSO, API-доступа. На собесе SA: «расскажи про Authorization Code flow», «зачем PKCE», «Client Credentials vs пользовательский flow». Senior — нюансы device flow, MTLS-clients, sender-constrained tokens.

Главная боль без понимания — SA закладывает в архитектуру deprecated implicit flow в 2026 году, security commission заворачивает на review.

Что нового в OAuth 2.1

OAuth 2.1 (черновик IETF) — консолидация best practices поверх 2.0.

Что изменилось:

• Implicit flow — удалён (был небезопасный из-за access token в URL).
• Resource Owner Password Credentials (ROPC) — удалён (anti-pattern, вообще не должны были существовать).
• PKCE обязателен для Authorization Code (не только для public clients).
• Refresh tokens должны быть sender-constrained или одноразовыми (для public clients).
• Redirect URI — exact match (без wildcards).

В 2026 на собесе ожидают знание 2.1 как стандарта, а не 2.0.

Authorization Code + PKCE

Главный flow для веб- и мобильных приложений с пользователем.

Шаги:

1. App → Authorization Server (AS):
   GET /authorize?
     response_type=code
     &client_id=APP_ID
     &redirect_uri=https://app.com/callback
     &scope=read:profile
     &state=RANDOM
     &code_challenge=BASE64URL(SHA256(verifier))
     &code_challenge_method=S256

2. AS показывает форму логина / consent.
3. Пользователь авторизуется и соглашается.

4. AS редиректит:
   GET https://app.com/callback?
     code=AUTH_CODE
     &state=RANDOM

5. App → AS (server-to-server):
   POST /token
     grant_type=authorization_code
     &code=AUTH_CODE
     &redirect_uri=https://app.com/callback
     &client_id=APP_ID
     &code_verifier=ORIGINAL_VERIFIER

6. AS:
   Проверяет SHA256(code_verifier) == code_challenge
   Возвращает: access_token + refresh_token + id_token (если OIDC)

Зачем PKCE (Proof Key for Code Exchange):

• Защита от перехвата AUTH_CODE злоумышленником (например, на мобильном устройстве с custom URI scheme).
• Только клиент, знающий verifier, может обменять code на token.

state параметр — защита от CSRF. Сравниваем при возврате.

Client Credentials

Server-to-server без пользователя. Service account.

1. Service A → AS:
   POST /token
     grant_type=client_credentials
     &client_id=SERVICE_A_ID
     &client_secret=SERVICE_A_SECRET
     &scope=internal:read

2. AS возвращает access_token (короткоживущий, без refresh_token обычно).

3. Service A → API (Service B):
   GET /api/data
   Authorization: Bearer ACCESS_TOKEN

Применение:

• Микросервисы между собой.
• Cron, batch-jobs.
• Backend интеграции.

Не подходит для пользовательских данных — здесь нет user'а.

Device Authorization

Для устройств без удобной клавиатуры (smart TV, IoT, CLI).

1. Device → AS:
   POST /device_authorization
     client_id=DEVICE_APP

   Ответ:
     device_code=ABC123
     user_code=WXYZ-1234
     verification_uri=https://example.com/device
     interval=5
     expires_in=600

2. Device показывает: "Зайди на example.com/device, введи WXYZ-1234"

3. Юзер на смартфоне → AS, вводит код → авторизуется.

4. Device параллельно polling'ит:
   POST /token
     grant_type=urn:ietf:params:oauth:grant-type:device_code
     &device_code=ABC123
     &client_id=DEVICE_APP

   - authorization_pending → ждать
   - access_denied → ошибка
   - access_token + refresh_token → готово

Применение:

• Smart TV (Netflix, YouTube on TV).
• CLI-инструменты (gh auth login, aws sso login).
• IoT-устройства.

Refresh tokens

Access token короткоживущий (обычно 5-60 мин). Чтобы не логиниться заново — refresh token (часы / дни / недели).

1. Когда access_token истёк:
   POST /token
     grant_type=refresh_token
     &refresh_token=REFRESH_VALUE
     &client_id=APP_ID

2. AS возвращает новый access_token (+ возможно новый refresh_token = rotation).

Refresh token rotation. Каждое использование — новый refresh, старый аннулируется. Защита: если злоумышленник украл — обнаружим при следующем использовании старого.

Sender-constrained refresh. Refresh привязан к клиенту через mTLS / DPoP. Без правильного клиента не работает.

Срок refresh:

• Web app — 1-7 дней (zero trust подход).
• Native app — 30 дней — год.
• Sliding expiration — каждое использование продлевает.

Какой flow для какого клиента

Чего избегать:

• Implicit flow — deprecated.
• ROPC (password grant) — deprecated, не должно существовать.
• Hybrid flow в новых проектах — обычно лишний для современных SPA.

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

Использовать Implicit flow. Deprecated в OAuth 2.1. Используй Authorization Code + PKCE.

Хранить access_token в localStorage. XSS уведёт. Лучше — http-only secure cookie + CSRF-protection.

Refresh token в localStorage. Та же проблема — XSS. Лучше — http-only cookie или secure storage.

Не валидировать state. CSRF-уязвимость. Обязательная проверка.

Long-lived access token. Если 24-часовой access — refresh не нужен. Но любой компромисс = долгий compromise. Короткий access + refresh — стандарт.

Не делать refresh token rotation. Одноразовые refresh защищают от утечки.

Wildcard redirect URI. OAuth 2.1 запрещает. Exact match.

Хранить client_secret в SPA / mobile. Public client = нет client_secret. PKCE заменяет.

Слабый PKCE method. S256 (SHA-256) — стандарт. plain есть, но небезопасен — не использовать.

Полагаться только на scope для авторизации. Scope = что разрешено. Authorization rules в backend всё равно проверяют ownership ресурса.

Связанные темы

• OAuth на собесе SA
• JWT на собесе SA
• SAML 2 на собесе SA
• RBAC vs ABAC на собесе SA
• Подготовка к собесу системного аналитика

FAQ

Чем OIDC отличается от OAuth?

OAuth 2.x — авторизация (доступ к ресурсу). OpenID Connect — аутентификация (кто пользователь) + authorization. OIDC надстройка над OAuth, добавляет id_token (JWT с информацией о пользователе).

Что такое Token Introspection?

Endpoint, проверяющий валидность токена и возвращающий метаданные. Используется resource server'ом для проверки opaque-токенов (без JWT-подписи).

Когда использовать Refresh token rotation?

Public clients (SPA, mobile) — обязательно. Confidential clients (backend) — желательно. Современная практика — всегда rotation.

Что такое DPoP?

Demonstration of Proof-of-Possession — sender-constrained tokens. Клиент подписывает запрос своим ключом, токен валиден только с этой подписью. Защита от утечки токена.

Implicit flow используется хотя бы где-то в 2026?

Только для legacy. Современные SPA должны использовать Authorization Code + PKCE.

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

Нет. Статья основана на OAuth 2.1 draft (datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1) и RFC 6749/7636/8252/8628.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.