Jak wdrożyć OAuth2 "Token Exchange" z Spring Cloud Security

Question

Chciałbym wiedzieć, czy ktoś ma przykład, aby zobaczyć, jak zaimplementować technikę "Token Exchange" w Spring Cloud Security (z OAuth2).

Obecnie zaimplementowałem technikę "Przekaźnik Tokenowy" w środowisku Microservices, używając ZuulProxy do "przekazywania" tokenu OAuth2 i wdrażania SSO. Jest to świetne, ale sugeruje, że każda mikroserwis używa tego samego identyfikatora klienta (który jest określony w konfiguracji ZuulProxy, ponieważ ZuulProxy przekazuje token tylko z typem dotacji autoryzacji i podanym ID klienta). Jednak w przypadku połączeń wewnątrz micro-usługodawców chciałbym "wymienić" token. Oznacza to w niektórych przypadkach token, że przekaźniki ZuulProxy nie są tym, których potrzebuję do uwierzytelnienia/autoryzacji Microservice A jako klienta Microservice B.

Dokumentacja referencyjna Spring Cloud mówi obecnie: "W oparciu o Spring Boot and Spring Security OAuth2 możemy szybko tworzyć systemy, które implementują typowe wzorce, takie jak logowanie jednokrotne, przekaźnik tokena i wymiana znacznika token . " (http://cloud.spring.io/spring-cloud-security/spring-cloud-security.html)

myślę, że z „Reklamowe Exchange” w dokumentacji odniesienia oznacza, że ​​wdrożenie tego rozszerzenia OAuth2, opisane w tej specyfikacji, która jest w zasadzie to, czego potrzebuję: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03

Jak powiedziałem Rozumiem, jak używać SSO i Token Relay, ale nie jestem w stanie zobaczyć dalszych wyjaśnień na temat wdrażania "wymiany tokenów" w dokumentacji referencyjnej. Nie mogłem też znaleźć przykładu wdrożenia.

Czy ktoś wie, gdzie mogę znaleźć dalsze informacje lub przykład?

Dziękuję bardzo!

Answer 1

Jestem ciekawy, dlaczego musiałbyś "wymienić" token za połączenia z Microservice A na Microservice B i dlaczego przekazywanie nie jest wystarczające? Co próbujesz osiągnąć, wymieniając żetony na prośby między służbami?

Mamy zestaw bardzo podobny do tego, co jest opisane w tym Nordic APIs entry. Krótka wersja jest taka, że ​​zewnętrzni wywołujący używają nieprzezroczystego tokena, ale gdy żądanie przechodzi przez naszą bramkę, każda mikroserwis otrzymuje reprezentację JWT tego samego tokena. Musieliśmy zaimplementować niestandardowy punkt końcowy, aby wykonać nieprzezroczystą wymianę na JWT. Kiedy usługi muszą współdziałać ze sobą, nie wymieniamy tokena, gdy A potrzebuje wywołać B, po prostu przekazujemy token. Dowolny klient RestTemplate lub Feign automatycznie przekazuje token z punktu A do punktu B. W ten sposób kontekst nie zostanie utracony.

Teraz, jeśli chcemy kontrolować dostęp, JWT może określić zbiór wartości odbiorców lub możemy wymusić dostęp poprzez zakresy. W rzeczywistości robimy kombinację tych dwóch w zależności od przypadku użycia.

Wymiana żetonów nie jest tanią operacją, w rzeczywistości jest dość kosztowna i naprawdę powinna rozważyć, dlaczego trzeba wymieniać tokena dla komunikacji wewnątrzserwisowej. Jeśli każde żądanie API spowoduje połączenie z usługą B, a będziesz musiał dokonać wymiany tokena, będziesz mieć pewność, że twoja usługa autoryzacji poradzi sobie z tego typu obciążeniem. Wreszcie, wymiana tokena IETF jest nadal stanem projektu i zmieniła się nieco w jego ewolucji, więc nie spodziewałbym się wiele w zakresie porad dotyczących wdrażania, dopóki specyfikacja nie zbliży się do finalizacji.