OAuth и аутентификация на собеседовании системного аналитика
Зачем OAuth на собесе SA
Аутентификация и авторизация — одна из самых частых тем на собесе системного аналитика. Любая система с пользователями требует ответа на «кто это» (authentication) и «что ему можно» (authorization). Слабый ответ — «логин-пароль и в куки». Сильный — разделяет authn vs authz, понимает OAuth2 flows, JWT, refresh-токены, RBAC vs ABAC.
В 2026 OAuth2 + OIDC — индустриальный стандарт. Без понимания этих протоколов senior SA не получится: интеграция с SSO, B2B-API, mobile clients — везде это нужно.
Authentication vs Authorization
Authentication (authn): проверка, кто пользователь. «Это действительно Иван?»
Authorization (authz): проверка, что ему можно делать. «Иван может удалить этот заказ?»
Часто путают, но разные системы. Authn — login flow, MFA, password manager. Authz — RBAC, ACL, policy engine (OPA).
OAuth2 — про authorization (delegation: «Я разрешаю приложению X читать мои фото»). OIDC — про authentication, надстройка над OAuth2.
OAuth2 в двух предложениях
OAuth2 — протокол делегирования. Пользователь даёт приложению ограниченный доступ к ресурсу (своему профилю в Google, например), не передавая пароль. Приложение получает access token, использует его для API-запросов.
Роли:
- Resource Owner — пользователь
- Client — приложение, запрашивающее доступ
- Authorization Server — выдаёт токены (например, accounts.google.com)
- Resource Server — API, который защищён токеном (Google Drive API)
OAuth2 flows
1. Authorization Code (стандарт для web/mobile):
- Client → AuthServer: «дай code для user X»
- User logs in, consents
- AuthServer → Client: code
- Client (backend) → AuthServer: code + client_secret → access_token + refresh_token
- Client → ResourceServer: API call с access_token
2. Authorization Code + PKCE (для mobile / SPA):
- Как Authorization Code, но без client_secret
- PKCE (Proof Key for Code Exchange) защищает от code interception
- Стандарт для public clients
3. Client Credentials (M2M):
- Сервис ↔ сервис, не пользователь
- Client → AuthServer: client_id + client_secret → access_token
- Для backend integrations, scheduled jobs
4. Device Code (TV, IoT):
- Устройство без браузера показывает code
- User вводит code на phone, авторизует
- Device polls AuthServer → token
Устаревшие:
- Implicit flow — deprecated (token в URL = security risk)
- Resource Owner Password — deprecated (нарушает OAuth-идею)
OIDC поверх OAuth2
OAuth2 — про access. Когда нужна аутентификация («кто этот пользователь») — OpenID Connect.
OIDC = OAuth2 + ID Token (JWT с user info).
ID token содержит: sub (user ID), iss (issuer), aud (audience), exp (expiry), email, name и т.д.
Client читает ID token → знает, кто пользователь. Это «Войти через Google / Apple / VK ID».
JWT (JSON Web Token)
Самоописывающий токен. 3 части через точки: header.payload.signature.
Payload: claims (например, {"sub": "user_42", "exp": 1715520000, "role": "admin"}).
Signature: HMAC (общий ключ) или RSA (private key).
Плюсы:
- Stateless: сервер не хранит сессии, validate подписью
- Self-contained: вся информация внутри
Минусы:
- Нельзя инвалидировать до expiry (без blacklist)
- Если sensitive data в payload — все видят (base64, не encryption)
- Длинный — больше bandwidth
Refresh tokens
Access token — short-lived (15 min - 1h). Когда истекает, client использует refresh token для нового access.
Best practices:
- Refresh token — long-lived (days/weeks)
- Хранить в httpOnly cookie (web) или secure storage (mobile)
- Rotate refresh tokens при каждом use (security)
- Revocation endpoint для logout
RBAC vs ABAC
Authorization модели.
RBAC (Role-Based Access Control):
- Users → Roles → Permissions
- Admin role может delete, Viewer — только read
- Просто, масштабируется до средней сложности
ABAC (Attribute-Based Access Control):
- Decisions на основе attributes: user, resource, environment
- «Менеджер может видеть заказы своего отдела, в рабочие часы»
- Гибче, но сложнее
- Tools: Open Policy Agent (OPA), Cedar
В большинстве продуктов RBAC достаточно. ABAC — когда есть complex policies (банки, healthcare).
Security best practices
- HTTPS only. TLS — обязательно
- State parameter против CSRF в OAuth flow
- PKCE для public clients
- Short-lived access tokens + refresh rotation
- Validate iss / aud / exp в JWT
- Не передавать токен в URL (логи, referrer)
- MFA для admin-аккаунтов
- Rate limiting на login endpoints (brute force)
- Account lockout после N failed attempts
Типичные вопросы
«Как реализовать "Войти через Google"?»
OAuth2 Authorization Code + PKCE → OIDC ID token. Backend: validate token, найти/создать user, выдать session/JWT. Frontend: redirect на Google, callback с code, обмен через backend.
«JWT или session cookies?»
Session cookies: проще, native CSRF protection, easy revoke. JWT: stateless, для distributed systems, mobile/SPA. Часто гибрид: session для web, JWT для API.
«Где хранить JWT в SPA?»
httpOnly cookie — защита от XSS. localStorage — уязвим к XSS. Memory + refresh из httpOnly — стандарт для SPA.
«Как сделать logout с JWT?»
JWT нельзя инвалидировать до expiry. Опции: short-lived JWT + revoke refresh; blacklist в Redis; rotate JWT secret (nuclear option). Для logout-всех-устройств — last_logout_at в БД, проверка в JWT validation.
«SSO между несколькими продуктами?»
Centralized Auth Server (Keycloak / Auth0). Каждый продукт — OIDC client. Single login session на AuthServer, SSO между продуктами.
Частые ошибки
- JWT в localStorage с sensitive scopes. Один XSS — все компрометировано
- Access token long-lived. Не реализован refresh → токен валиден часами
- Implicit flow для SPA. Deprecated, использовать Authorization Code + PKCE
- Confusion authn vs authz. «Я авторизуюсь» — на самом деле «аутентифицируюсь»
- Roles hardcoded в коде. Изменение требует deploy. Должно быть data-driven
FAQ
Keycloak, Auth0, Okta — что выбрать?
Keycloak — open-source, self-hosted, бесплатно. Auth0 / Okta — SaaS, проще запустить, дорого на масштабе. Российский аналог — Cloud.ru Identity. Для small startup — Auth0; для enterprise — Keycloak.
SAML устарел?
SAML 2.0 ещё используется в enterprise (B2B SSO), но новые системы строят на OIDC. SAML XML-based, тяжёлый.
OAuth для public APIs?
Да, стандарт. Client Credentials для service-to-service, Authorization Code для user-facing.
Что такое scope?
Granular permission в OAuth: scope=read:profile write:photos. Client запрашивает scopes, user одобряет, token содержит approved scopes.
Где валидировать JWT?
В API gateway (centralized) или в каждом сервисе (decentralized). Gateway проще, но single point of failure. Decentralized — нужен shared public key.