OAuth 2.0 и OIDC
Тема дорожной карты · Backend разработчик
OAuth 2.0 — промышленный стандарт фреймворка авторизации, позволяющий сторонним приложениям получать ограниченный доступ к ресурсам пользователя на сервере, не работая напрямую с его учётными данными, — вместо этого используются краткосрочные access-токены. Фреймворк определяет четыре типа грантов: Authorization Code (с PKCE для публичных клиентов — рекомендуемый поток для веб- и мобильных приложений), Client Credentials (для аутентификации сервис-к-сервису), Device Code (для CLI-инструментов и умных устройств), и устаревший Implicit, заменённый связкой Authorization Code + PKCE. Сервер авторизации OAuth 2.0 выдаёт JWT access-токены и непрозрачные refresh-токены; библиотеки passport-oauth2 для Node.js, spring-security-oauth2-authorization-server для Spring Boot или authlib для Python берут на себя детали реализации выдачи, валидации и ротации токенов. Access-токены передаются в виде заголовка Authorization: Bearer <token> к защищённым REST API или gRPC-эндпоинтам, где ресурсные серверы проверяют подпись токена, его claims aud, scope и exp при каждом запросе. OAuth 2.0 расширяется протоколом OpenID Connect (OIDC), который добавляет id_token (JWT с данными о пользователе) и эндпоинт /userinfo, обеспечивая единый вход (SSO) в микросервисах и интеграциях с третьими сторонами.
Как это работает
OAuth 2.0 и OIDC включает аутентификацию (кто вы?) и авторизацию (что можете?). Современная auth: OAuth 2.0 + OpenID Connect для делегированной identity, session-куки для традиционных веб-приложений, JWT для stateless distributed-систем. Пароли всегда хешируйте через bcrypt или argon2id. CSRF-защита на state-changing endpoints; CORS осознанно (не * в production). Авторизация: RBAC (роли), ABAC (атрибуты), policy engines (OPA, Casbin). MFA/2FA для любой привилегированной операции.
Когда применять
Session-куки — для монолитных веб-приложений (HttpOnly + Secure + SameSite=Lax): проще, отзываемо, server-side state. JWT — только когда реально нужна stateless distributed-валидация; иначе session безопаснее. Identity отдавайте провайдеру (Yandex ID, Keycloak, Auth0, Authentik) — DIY identity = место утечек. Rate-limit на auth-endpoints с первого дня.
Типичные ошибки
Ловушки OAuth 2.0 и OIDC: пароли через MD5/SHA1/SHA256 (быстро, brute-force-friendly — используйте argon2id); JWT-секрет в клиентском коде или git-history; JWT без expiry или revocation list (потерянный девайс = пожизненный доступ к аккаунту); своя крипта (используйте библиотеки); admin-endpoints без auth "потому что internal" (внутренняя сеть не граница безопасности). Регулярные auth-аудиты.