Spring Security 6.5: обмін коду авторизації OAuth через проксі

Надайте клієнту відповіді з токеном коду авторизації в Spring Security RestClient з підтримкою проксі, зберігши його конвертери OAuth і обробник помилок.

Браузер досягає постачальника ідентичності, потім вхід не вдається, коли застосунок обмінює повернений код авторизації. Цей обмін — вихідний запит із сервера застосунку, зі своїм HTTP-клієнтом.

Для API на основі RestClient, доступного в Spring Security 6.5, надайте клієнту відповіді з токеном коду авторизації фабрику запитів із підтримкою проксі:

SimpleClientHttpRequestFactory factory = new SimpleClientHttpRequestFactory();
factory.setProxy(new java.net.Proxy(
    java.net.Proxy.Type.HTTP,
    new java.net.InetSocketAddress("proxy.example", 8080)));
factory.setConnectTimeout(5000);
factory.setReadTimeout(15000);

RestClient tokenHttp = RestClient.builder()
    .requestFactory(factory)
    .messageConverters(converters -> {
        converters.clear();
        converters.add(new FormHttpMessageConverter());
        converters.add(new OAuth2AccessTokenResponseHttpMessageConverter());
    })
    .defaultStatusHandler(new OAuth2ErrorResponseErrorHandler())
    .build();

RestClientAuthorizationCodeTokenResponseClient tokenClient =
    new RestClientAuthorizationCodeTokenResponseClient();
tokenClient.setRestClient(tokenHttp);

Класи конвертера й обробника помилок зберігають задокументовану поведінку запиту токена в Spring Security. Звичайний RestClient, налаштований лише для незв'язаного JSON API, не є рівноцінною заміною.

Підключіть той самий tokenClient до наявної конфігурації безпеки:

http.oauth2Login(login -> login
    .tokenEndpoint(token -> token
        .accessTokenResponseClient(tokenClient)));

Це фрагменти конфігурації для застосунку, який уже має реєстрацію клієнта й SecurityFilterChain. Вони вибирають HTTP-проксі без автентифікації; проксі, що потребує облікових даних, потребує відповідної конфігурації автентифікації вибраного транспорту. Для загальнодоступної кінцевої точки токена HTTPS на дозволеному публічному маршруті HTTP-запис зі списку HTTP-проксі може заповнити цю адресу проксі без облікового запису.

Тримайте хост проксі окремо від його порту та схеми URL. Залиште URI токена постачальника ідентичності як призначення. Приклад не замінює перевірку сертифікатів.

Наступні запити потребують власної перевірки володіння. Отримання UserInfo, обміни токена оновлення, надання client-credentials і виклики захищеного API можуть використовувати інші клієнтські об'єкти. Налаштуйте відповідний підтримуваний клієнт, коли ця операція також потребує маршруту. Для реактивного потоку client_credentials у Spring Security 6.5 налаштуйте реактивний клієнт токена та його постачальника надань окремо.

Старі приклади з OAuth2RestTemplate і AccessTokenProvider належать до старішого проєкту Spring Security OAuth. Виберіть API, який використовує встановлений застосунок, перш ніж адаптувати код; не змішуйте ці об'єкти в цій конфігурації.

Схожі статті