Access Token Pattern
токен доступа — это электронный ключ, который подтверждает личность пользователя или приложения и дает им право доступа
Контекст
ПРоблемный Коля:
Так у нас микры и API Gateway, как нам авторизацию на сервисах делать?
Выручающая АНЯ:
А в чем проблема?
ПРоблемный Коля:
Ну gateway проверил пользователя и перенаправил запрос на сервис, здесь ок, а как на сервисе проверить или можно давать доступ по этому запросу?
Выручающая АНЯ:
Можно чтобы JWT прилетал на gateway, он валидировал и перенаправлял запрос, но передавал и сам токен вместе с запросом
Проблема
Как передавать идентификационные данные запроса сервисам? Как разделить аутентификацию и авторизацию? Как избежать постоянного подтверждения авторизации через ввод логина и пароля либо проверочного кода?
Решение
Выдавать token, которые передавать вместе с запросом между сервисами.
Пример:
У нас есть:
1) User — клиент (фронт, мобильное приложение, postman и т. д.).
2) Authentication Server (например Keycloak или сервис на Spring Security) — сервер аутентификации, который проверяет логин/пароль и выдаёт токен.
3) API Gateway — точка входа для всех запросов к backend-сервисам. Проверяет JWT перед пересылкой запроса дальше.
4) Application Server — сервис или API, который предоставляет бизнес-данные (например, OrderService, UserService).
Пример:
У нас есть:
1) User — клиент (фронт, мобильное приложение, postman и т. д.).
2) Authentication Server (например Keycloak или сервис на Spring Security) — сервер аутентификации, который проверяет логин/пароль и выдаёт токен.
3) API Gateway — точка входа для всех запросов к backend-сервисам. Проверяет JWT перед пересылкой запроса дальше.
4) Application Server — сервис или API, который предоставляет бизнес-данные (например, OrderService, UserService).
Последовательный процесс аутентификации и авторизации через JWT
Шаги
- User → Keycloak
Пользователь отправляет свои учетные данные. С телом запроса (например, grant type = password или authorization code)
2. Keycloak → User
Возвращает JWT (header.payload.signature)
Keycloak проверяет данные, создаёт JWT-токен (подписанный своим приватным ключом) и возвращает его клиенту.
Этот токен включает:
- sub — идентификатор пользователя,
- exp — срок действия,
- roles — роли,
- iss — издателя (Keycloak),
- aud — получателя (API Gateway или приложение).
3. User → API Gateway
Запрос к API с JWT в заголовке
Пользователь обращается к API через шлюз. API Gateway получает токен и начинает его валидацию.
4. API Gateway → Keycloak (опционально)
Проверка подписи JWT
5.Application Server
Возврат результата или ошибки
✅ Подпись верна:
Gateway пропускает запрос.
Application Server выполняет логику (например, отдает данные о заказах).
Возвращается успешный ответ 200 OK с данными.
❌ Подпись неверна:
- Gateway или сервер отклоняет запрос.
- Возвращает 401 Unauthorized:
Важные моменты
- Keycloak подписывает JWT приватным ключом, а публичный ключ публикует через JWKS
- API Gateway проверяет токен без обращения к базе Keycloak — это делает систему быстрой и масштабируемой.
- JWT не нужно хранить на сервере — он самодостаточный и содержит все claims.
- Если токен истёк — клиент должен запросить новый через refresh token.
Онлайн-школа профессионального программирования на java для коммерческих разработчиков и соискателей.
2 главные задачи, которые мы решаем:
- Трудоустройство и успешное прохождение испыталки.
- Переход на современный стек middle+
Наше главное достояние:
Менторская поддержка 24/7 и обучение в формате живого общения
Получить консультацию по обучению