Авторизация сегодня — это не «введите логин и пароль», а гибкая система доверия между пользователями, сервисами и внешними платформами.
Пользователь хочет авторизоваться в одно касание, разработчик — не возиться с безопасностью, а компания — не получить утечку данных.
Решение? Современные протоколы вроде OAuth2, OIDC, JWT и обязательная ротация ключей.
Эти технологии лежат в основе всех современных систем: от корпоративных порталов до мобильных приложений и API.
Пользователь хочет авторизоваться в одно касание, разработчик — не возиться с безопасностью, а компания — не получить утечку данных.
Решение? Современные протоколы вроде OAuth2, OIDC, JWT и обязательная ротация ключей.
Эти технологии лежат в основе всех современных систем: от корпоративных порталов до мобильных приложений и API.
OAuth2 — не просто токены, а делегирование доступа
OAuth2 — это стандарт, который решает задачу: «Как дать стороннему приложению доступ к данным без передачи пароля?»
Пользователь логинится у провайдера (например, Google), а приложение получает access token — временный пропуск для запросов к API.
Важно, что этот токен не раскрывает пароли, а действует строго в рамках разрешений.
Основные роли в OAuth2:
• Resource Owner — пользователь (владелец данных);
• Client — приложение, запрашивающее доступ;
• Authorization Server — сервер, выдающий токены;
• Resource Server — API, к которому обращаются.
Типичный пример:
1. Пользователь заходит в сервис и выбирает «Войти через Google».
2. Google спрашивает разрешение.
3. После подтверждения — выдает access token.
4. Сервис использует токен, чтобы получить e-mail и имя через Google API.
Потоки авторизации (flows)
• Authorization Code Flow — классика для веба и мобильных клиентов.
• Client Credentials Flow — для серверов и микросервисов.
• Device Flow — для Smart TV, где нельзя вводить пароль.
• Implicit Flow — устарел, почти не используется (только в legacy-приложениях).
Пользователь логинится у провайдера (например, Google), а приложение получает access token — временный пропуск для запросов к API.
Важно, что этот токен не раскрывает пароли, а действует строго в рамках разрешений.
Основные роли в OAuth2:
• Resource Owner — пользователь (владелец данных);
• Client — приложение, запрашивающее доступ;
• Authorization Server — сервер, выдающий токены;
• Resource Server — API, к которому обращаются.
Типичный пример:
1. Пользователь заходит в сервис и выбирает «Войти через Google».
2. Google спрашивает разрешение.
3. После подтверждения — выдает access token.
4. Сервис использует токен, чтобы получить e-mail и имя через Google API.
Потоки авторизации (flows)
• Authorization Code Flow — классика для веба и мобильных клиентов.
• Client Credentials Flow — для серверов и микросервисов.
• Device Flow — для Smart TV, где нельзя вводить пароль.
• Implicit Flow — устарел, почти не используется (только в legacy-приложениях).
OIDC — слой аутентификации и идентификации поверх OAuth2
OAuth2 умеет выдавать токены доступа, но не знает, кто именно вошёл.
Поэтому появился OpenID Connect (OIDC) — расширение, которое добавляет аутентификацию и идентификацию пользователя.
Он вводит новый тип токена, ID Token, где хранится информация о пользователе.
Пример полезных claims:
Поэтому появился OpenID Connect (OIDC) — расширение, которое добавляет аутентификацию и идентификацию пользователя.
Он вводит новый тип токена, ID Token, где хранится информация о пользователе.
Пример полезных claims:
OIDC является одной из основных технологий для реализации SSO (Single Sign-On):
однажды вошёл — сразу имеешь доступ к Jira, Confluence, GitLab и прочим сервисам.
В Java-мире чаще всего используют:
• Keycloak — полноценный open-source сервер авторизации;
• Spring Authorization Server — легковесный, но гибкий вариант;
• Auth0 / Okta / Azure AD — готовые облачные решения.
однажды вошёл — сразу имеешь доступ к Jira, Confluence, GitLab и прочим сервисам.
В Java-мире чаще всего используют:
• Keycloak — полноценный open-source сервер авторизации;
• Spring Authorization Server — легковесный, но гибкий вариант;
• Auth0 / Okta / Azure AD — готовые облачные решения.
JWT — универсальный контейнер для токенов
JWT (JSON Web Token) — это формат, в котором обычно передаются access и ID токены. Могут храниться на клиенте (в localStorage, sessionStorage, cookies).
Он состоит из трёх частей: Header.Payload.Signature, разделённых точками.
Пример:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTYiLCJyb2xlIjoiYWRtaW4iLCJleHAiOjE3MzkzNjgyMDB9.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Преимущества:
• Не требует обращений к БД: информация уже зашита внутри токена.
• Можно легко передавать между сервисами.
• Работает как на backend, так и на frontend.
Минусы:
• Невозможность немедленного отзыва токена до истечения его срока действия.
• Большие payload-ы → больше нагрузка на сеть.
• Ошибки с exp и iat могут вызвать баги, если не учитывать часовой пояс или clock skew.
Он состоит из трёх частей: Header.Payload.Signature, разделённых точками.
Пример:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTYiLCJyb2xlIjoiYWRtaW4iLCJleHAiOjE3MzkzNjgyMDB9.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Преимущества:
• Не требует обращений к БД: информация уже зашита внутри токена.
• Можно легко передавать между сервисами.
• Работает как на backend, так и на frontend.
Минусы:
• Невозможность немедленного отзыва токена до истечения его срока действия.
• Большие payload-ы → больше нагрузка на сеть.
• Ошибки с exp и iat могут вызвать баги, если не учитывать часовой пояс или clock skew.
Ротация токенов и ключей
1. Ротация токенов (refresh flow)
Access token живёт недолго — обычно 5–15 минут. Чтобы не заставлять пользователя логиниться заново, используется refresh token.
Пример схемы:
1. Клиент получает access_token и refresh_token.
2. Когда access истекает, клиент запрашивает новый, передавая refresh.
3. Сервер возвращает новый access_token, а иногда и новый refresh_token.
Для безопасности refresh-токены должны:
• Храниться только в HttpOnly cookie или Secure Storage;
• Иметь разумный баланс между удобством и безопасностью;
• Быть одноразовыми (rotate-on-use).
2. Ротация ключей (JWKS)
Каждый токен подписан ключом. Если ключ утечёт — можно подделать любой токен.
Чтобы избежать катастрофы, применяют ротацию ключей.
Серверы (Keycloak, Auth0 и др.) публикуют открытые ключи в файле:
https://auth.company.com/.well-known/jwks.json
Когда ключ меняется:
• Новые токены подписываются новым ключом;
• Старые продолжают работать до истечения срока;
• Клиенты периодически обновляют JWKS кэш.
Это обеспечивает плавный переход без даунтайма.
Access token живёт недолго — обычно 5–15 минут. Чтобы не заставлять пользователя логиниться заново, используется refresh token.
Пример схемы:
1. Клиент получает access_token и refresh_token.
2. Когда access истекает, клиент запрашивает новый, передавая refresh.
3. Сервер возвращает новый access_token, а иногда и новый refresh_token.
Для безопасности refresh-токены должны:
• Храниться только в HttpOnly cookie или Secure Storage;
• Иметь разумный баланс между удобством и безопасностью;
• Быть одноразовыми (rotate-on-use).
2. Ротация ключей (JWKS)
Каждый токен подписан ключом. Если ключ утечёт — можно подделать любой токен.
Чтобы избежать катастрофы, применяют ротацию ключей.
Серверы (Keycloak, Auth0 и др.) публикуют открытые ключи в файле:
https://auth.company.com/.well-known/jwks.json
Когда ключ меняется:
• Новые токены подписываются новым ключом;
• Старые продолжают работать до истечения срока;
• Клиенты периодически обновляют JWKS кэш.
Это обеспечивает плавный переход без даунтайма.
Как это выглядит на практике
Backend (Java + Spring Security)
Frontend (React + OIDC)
Итого: фронтенд получает токен от OIDC, backend валидирует его через public key — и вся система работает без хранения паролей.
Где всё это используется
• Frontend: SPA-приложения с авторизацией через Google / GitHub / Keycloak.
• Java / Spring Boot: микросервисы с JWT и централизованным сервером авторизации.
• DevOps: безопасные API-шлюзы, CI/CD и сервисные учётки с OAuth2 Client Credentials.
• Mobile: вход через социальные сети и refresh-токены для тихого продления сессии.
• Java / Spring Boot: микросервисы с JWT и централизованным сервером авторизации.
• DevOps: безопасные API-шлюзы, CI/CD и сервисные учётки с OAuth2 Client Credentials.
• Mobile: вход через социальные сети и refresh-токены для тихого продления сессии.
В современной архитектуре эти технологии работают вместе:
OAuth2 отвечает за делегирование доступа,
OIDC — за аутентификацию и идентификацию пользователя,
JWT — за компактную и верифицируемую передачу этой информации,
а ротация ключей и токенов делает систему устойчивой к компрометации.
Главное — строить архитектуру авторизации не как костыль, а как фундамент безопасности.
Потому что вход в систему — это не просто “login”, это первый рубеж доверия.
Хотите узнать больше? Изучите другие статьи из разделов:
OIDC — за аутентификацию и идентификацию пользователя,
JWT — за компактную и верифицируемую передачу этой информации,
а ротация ключей и токенов делает систему устойчивой к компрометации.
Главное — строить архитектуру авторизации не как костыль, а как фундамент безопасности.
Потому что вход в систему — это не просто “login”, это первый рубеж доверия.
Хотите узнать больше? Изучите другие статьи из разделов:
