Современные подходы к авторизации: OAuth2, OIDC, JWT и ротация ключей

Авторизация сегодня — это не «введите логин и пароль», а гибкая система доверия между пользователями, сервисами и внешними платформами.
Пользователь хочет авторизоваться в одно касание, разработчик — не возиться с безопасностью, а компания — не получить утечку данных.

Решение? Современные протоколы вроде OAuth2, OIDC, JWT и обязательная ротация ключей.
Эти технологии лежат в основе всех современных систем: от корпоративных порталов до мобильных приложений и API.

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-приложениях).

OAuth2 умеет выдавать токены доступа, но не знает, кто именно вошёл.
Поэтому появился 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 — готовые облачные решения.

JWT (JSON Web Token) — это формат, в котором обычно передаются access и ID токены. Могут храниться на клиенте (в localStorage, sessionStorage, cookies).
Он состоит из трёх частей: 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 кэш.

Это обеспечивает плавный переход без даунтайма.

Итого: фронтенд получает токен от OIDC, backend валидирует его через public key — и вся система работает без хранения паролей.

• Frontend: SPA-приложения с авторизацией через Google / GitHub / Keycloak.

• Java / Spring Boot: микросервисы с JWT и централизованным сервером авторизации.

• DevOps: безопасные API-шлюзы, CI/CD и сервисные учётки с OAuth2 Client Credentials.

• Mobile: вход через социальные сети и refresh-токены для тихого продления сессии.

В современной архитектуре эти технологии работают вместе:

OAuth2 отвечает за делегирование доступа,
OIDC — за аутентификацию и идентификацию пользователя,
JWT — за компактную и верифицируемую передачу этой информации,
а ротация ключей и токенов делает систему устойчивой к компрометации.

Главное — строить архитектуру авторизации не как костыль, а как фундамент безопасности.
Потому что вход в систему — это не просто “login”, это первый рубеж доверия.


Хотите узнать больше? Изучите другие статьи из разделов:

• DevOps
• Java
• Frontend