Как реализовать OAuth2 "Обмен токенов" с помощью Spring Cloud Security

Я хотел бы знать, есть ли у кого-нибудь пример, как реализовать технику "Token Exchange" с помощью Spring Cloud Security (с OAuth2).

В настоящее время я реализовал технику "Token Relay" в среде Microservices, используя ZuulProxy для "ретрансляции" маркера OAuth2 и реализации единого входа. Это замечательно, но подразумевает, что каждый микросервис использует один и тот же clientId (который указан в настройке ZuulProxy, поскольку ZuulProxy ретранслирует токен только с типом grantization_code и предоставленным clientId). Однако для вызовов внутри микросервисов я хотел бы "обменять" токен. Это означает, что в некоторых случаях токен, который не поддерживает ZuulProxy, не тот, который мне нужно использовать для аутентификации/авторизации Microservice A в качестве клиента Microservice B.

В справочной документации Spring Cloud в настоящее время говорится: "Основываясь на Spring Boot и Spring Security OAuth2, мы можем быстро создавать системы, которые реализуют общие шаблоны, такие как единый вход, ретранслятор токенов и обмен токенами". (http://cloud.spring.io/spring-cloud-security/spring-cloud-security.html)

Я предполагаю, что с "Token Exchange" в справочной документации это означает реализацию этого расширения OAuth2, объясненного в этой спецификации, что в основном является тем, что мне нужно: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03

Как я уже сказал, я понимаю, как использовать SSO и Token Relay, но я не могу больше узнать о том, как реализовать "Обмен токенов" в справочной документации. Я также не смог найти пример реализации.

Кто-нибудь знает, где я могу найти дополнительную информацию или пример?

Большое спасибо!

Ответ 1

Мне любопытно, почему вам нужно "обменять" токен для совершения звонков с Microservice A на Microservice B и почему ретрансляции недостаточно? Чего вы пытаетесь достичь, обменяясь токенами на межсервисные запросы?

У нас есть набор, очень похожий на то, что описано в этой записи Nordic APIs. Краткая версия заключается в том, что внешние абоненты используют непрозрачный токен, но как только запрос проходит через наш шлюз, каждый микросервис получает JWT-представление одного и того же токена. Нам пришлось реализовать пользовательскую конечную точку для выполнения непрозрачного обмена JWT. Когда сервисы должны взаимодействовать друг с другом, мы не обмениваем токен, когда A нужно вызвать B, мы просто передаем токен. Либо клиент RestTemplate, либо Feign автоматически переадресует токен от A до B. Таким образом, контекст не теряется.

Теперь, если мы хотим контролировать доступ, JWT может указывать коллекцию значений аудитории, или мы можем обеспечить доступ через области. Мы фактически делаем комбинацию из двух в зависимости от варианта использования.

Обмен токенами не является дешевой операцией, на самом деле он довольно дорогой в масштабе и должен действительно учитывать, почему вам нужно сделать токен для обмена внутри службы. Если вы выполняете каждый запрос API, обратитесь к сервису. Вызывающий сервис B и вы должны сделать обмен токена, вы убедитесь, что ваша служба авторизации может обрабатывать этот тип рабочей нагрузки. Наконец, обмен токенами IETF по-прежнему является статусом проекта и немного изменился в его эволюции, поэтому я не ожидал бы многого на пути рекомендаций по внедрению, пока спецификация не приблизится к завершению.