Почему клиент OAuth2 не обновляет токен доступа с истекшим сроком действия?

У меня есть клиентское приложение, настроенное с @EnableOAuth2Sso и @EnableZuulProxy, и сервер ресурсов (отдельное приложение), настроенный с @EnableOAuth2Resource. Я вижу, что клиент правильно аутентифицируется на сервере ресурсов с помощью Authorization: Bearer {access_token here}, но когда по истечении срока действия токена доступа, запрос проксированного сервера ресурсов не выполняется навсегда.

[Отредактировано]

Я изменил свой сервер ресурсов, предоставив настраиваемый bean-компонент RemoteTokenServices, который использует конечную точку OpenAM / tokeninfo, чтобы решить, остается ли access_token действительным. (Предоставляемый Spring bean-компонент RemoteTokenServices пытается выполнить POST, который получает 405 от OpenAM). Когда я обнаруживаю, что access_token недействителен, я бросаю InvalidTokenException из my.spring.oauth2.OpenAMRemoteTokenServices#loadAuthentication. Теперь мой ресурсный сервер (я думаю, правильно) отправляет HTTP 401 в ответ клиенту в случае, если срок действия access_token истек.

Тем не менее, клиент не пытается обновить токен.

Может быть, моя ментальная модель неверна. Я ожидаю, что клиент, в случае истечения срока действия access_token, автоматически использует refresh_token для получения нового. Я не знаю, считаю ли я, что он должен проактивно обновлять access_token (в пределах некоторого эпсилона до истечения срока действия) или ждать, пока нисходящий запрос не сработает, и попытаться затем обновить. Но мой клиент, похоже, не делает ни того, ни другого, и я не могу сказать, почему.


person Tommy Knowlton    schedule 24.06.2015    source источник
comment
Я вижу, что org.springframework.cloud.security.oauth2.resource.UserInfoTokenServices#getMap (в клиенте) устанавливает (заменяет) access_token в контексте на менее информативный токен доступа. Токен замены содержит только значение непрозрачного строкового токена, тогда как заменяемый токен содержит срок действия и refreshToken. Еще не выяснили, почему токен заменяется менее полным токеном, содержащим ту же непрозрачную строку.   -  person Tommy Knowlton    schedule 25.06.2015
comment
Привет, это похоже на мою проблему. Я хочу предоставить краткосрочные токены доступа, и прокси-сервер zuul будет использовать токен обновления на время сеанса пользователя. Вы когда-нибудь добивались прогресса?   -  person Will Faithfull    schedule 29.09.2016
comment
@WillFaithfull, извините, нет, я так и не понял этого, и, вероятно, к настоящему времени должен был удалить вопрос. Извините, что ничем вам не помог.   -  person Tommy Knowlton    schedule 05.10.2016
comment
Я действительно заставил это работать. В моем приложении SSO zuul proxy было две проблемы: мне нужно было, чтобы bean-компонент DefaultTokenServices имел tokenServices.setSupportRefreshToken(true), и мне нужно было определить bean-компонент OAuth2RestOperations в контексте, чтобы он действительно мог делать запросы. Проблемы с этого момента были связаны с моим сервером авторизации. Я не уверен, является ли это ответом на вопрос, или это даже та же проблема.   -  person Will Faithfull    schedule 06.10.2016


Ответы (1)


Как указано в этой проблеме git: https://github.com/spring-guides/tut-spring-security-and-angular-js/issues/140, проблема может быть связана с тем, что в весенних версиях 1.4 и выше загружается фильтр Zuul, который обрабатывает нисходящий поток токенов доступа к службам (org.springframework.cloud.security.oauth2.proxy.OAuth2TokenRelayFilter) отсутствует bean-компонент типа OAuth2RestTemplate, который используется самим фильтром для автоматической обработки предоставления refresh_token по истечении срока действия токенов доступа.

У меня была такая же проблема, и я решил ее, добавив в класс конфигурации следующий bean-компонент:

@Configuration
public class ZuulConfiguration {
    @Bean
    protected OAuth2RestTemplate oauth2RestTemplate(OAuth2ProtectedResourceDetails resource, 
        OAuth2ClientContext context) {

        return new OAuth2RestTemplate(resource, context);
    }
}
person Nicola    schedule 22.03.2017