spring security client_credentials grant_type — поддержка токена обновления

Поддерживает ли тип гранта client_credentials сценарий маркера обновления?

Как следует обрабатывать истечение срока действия access_token при использовании типа гранта client_credentials?

У меня есть служба авторизации и защищенные службы за прокси-службой (Zuul с EnableOAuth2Sso), которая действует как шлюз для всех запросов, поступающих от клиентского приложения.

Вот поток, который у меня есть:

  1. Прокси-сервис (zuul), который принимает запросы (остальные API) от клиентского приложения.
  2. Прокси-сервис вызывает API-интерфейс службы авторизации, отправляя client_id, client_secret и grant_type (client_credentials) и получая access_token, refresh_token и время истечения срока действия из ответа.
  3. Прокси-служба направляет исходный запрос защищенным службам в соответствии с сопоставлением маршрутов zuul.

Этот поток работает нормально, но, глядя на код в ClientCredentialsAccessTokenProvider, я заметил, что методы «supportsRefresh» возвращают false, а методы «refreshToken» возвращают null. Означает ли это, что по истечении срока действия access_token любые последующие запросы от клиентских приложений к прокси-сервису (zuul) не будут выполняться?


spring-security spring-security-oauth2 spring-oauth2 netflix-zuul
person rgv    schedule 12.06.2017    source источник

Ответы (1)


arrow_upward
3
arrow_downward

client_credentials OAuth предоставляет серверам необходимость межмашинной аутентификации, поэтому нет необходимости обновлять токен.

В результате в Spring Security OAuth ClientCredentialsAccessTokenProvider, supportsRefresh возвращает false, а refreshToken методы возвращают null.

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

person chenrui    schedule 12.06.2017
comment
Спасибо за ответ. Несколько уточнений. 1) Сервер ресурсов и сервер аутентификации могут находиться в разных местах. 2) В нашем сценарии не сервер ресурсов получает access_token. У нас есть служба шлюза (zuul), которая отвечает за получение access_token с сервера аутентификации и передачу его в заголовках http на сервер ресурсов. Мой вопрос: должен ли наш прокси-сервер всегда получать новый access_token для каждого запроса или его можно обновлять только по истечении срока его действия? Я надеялся, что это будет позже, но, глядя на класс ClientCredentialsAccessTokenProvider, я вижу, что он не поддерживается. - person rgv; 13.06.2017
comment
Я думаю, что еще один вариант — внедрить логику (фильтр) в нашу службу шлюза, чтобы проверить, истек ли срок действия access_token в контексте, а затем получить новый access_token, используя учетные данные клиента (client_id и client_secret). - person rgv; 13.06.2017
comment
@rgv, да, вы должны AuthenticationFilter выполнять эти операции, связанные с токенами. - person chenrui; 15.06.2017