Когда запрашивать новый access_token для неинтерактивных клиентов в потоке oauth2?

У меня есть вопросы, связанные с неинтерактивными клиентами, такими как серверные приложения на основе потока oauth2.

https://auth0.com/docs/api-auth/grant/client-credentials

В соответствии с oauth2 для неинтерактивных клиентов поток:

  • Приложение аутентифицируется с помощью Auth0, используя его идентификатор клиента и секрет клиента.
  • Auth0 проверяет эту информацию и возвращает access_token.
  • Приложение может использовать access_token для вызова API от своего имени.

Исходя из этого, мои вопросы:

  • Серверные приложения должны хранить access_token локально или запрашивать новый access_token для одного и того же клиента каждый раз, когда клиент использует приложение?
  • Если access_token хранится локально, что случилось со сроком действия?
  • Access_token для неинтерактивных клиентов должен иметь такое же время истечения срока действия, как и access_token для интерактивных пользователей (веб-вход в систему)?

security access-token auth0 oauth-2.0
person JRichardsz    schedule 03.10.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Серверные приложения должны хранить access_token локально или запрашивать новый access_token для одного и того же клиента каждый раз, когда клиент использует приложение?

Для потока предоставления учетных данных клиента решение о том, следует ли часто продлевать или «кэшировать» возвращенный токен доступа JWT, будет зависеть от ваших требований - если области, например, часто меняются, может иметь смысл часто получать новый токен доступа, чтобы гарантировать эти изменения. отражаются. Исходя из личного опыта, это обычно не так, поэтому кеширование токена на время его истечения имеет смысл и сохраняет дополнительный вызов Auth0 для получения нового токена с каждым запросом.

Если access_token хранится локально, что произошло со сроком действия?

Вы можете проверять истечение срока действия перед тем, как делать запрос каждый раз, и получать новый токен доступа, если срок истечения истек, или просто попытаться использовать токен доступа без проверки, а затем попробовать продлить, только если вы получаете сбой при использовании существующий токен.

Access_token для неинтерактивных клиентов должен иметь такое же время истечения срока действия, как и access_token для интерактивных пользователей (веб-вход в систему)?

Вопрос аналогичный первому. Поскольку использование потока предоставления учетных данных клиента обычно указывает на конфиденциального / доверенного клиента (вы храните секрет клиента) - и часто для сценариев между компьютерами - может иметь смысл использовать более длительный срок действия. Однако, как уже упоминалось, если области действия могут измениться и т. Д., То короткое истечение срока действия приведет к тому, что изменения конфигурации (области действия) будут приняты быстрее.

person arcseldon    schedule 03.10.2017
comment
Спасибо @arcseldon. (1) Когда вы говорите: например, если области видимости часто меняются, вы имеете в виду требования к бизнес-проектам и проектам безопасности или области создания-чтения-записи из ответа json (oauth.com/oauth2-servers/access-tokens/access-token-response) ?? (2) В стабильной корпоративной среде требования к проекту безопасности не должны изменяться, чтобы не повлиять на все клиенты приложений конечных точек безопасности. Итак, предполагая стабильную платформу безопасности, токен access_token с большим сроком действия будет действителен? Или в целях безопасности нужно продлевать access_token по истечении срока его действия (часто)? Спасибо - person JRichardsz; 06.10.2017
comment
Привет. Здесь я заявляю, достаточно ли у вас фиксированных прав авторизации - например, ваши области действия, назначенные API, похожи на read:book write:book, тогда подходит более длительный срок действия (при прочих равных условиях - например, доверенный клиент и т. д.). Однако, если вы знаете, что права авторизации могут быть изменены, и хотите, чтобы ваш неинтерактивный клиент принимал новые изменения, то более подходящим может быть более короткий срок действия - например. вы добавляете delete book в качестве области видимости и хотите, чтобы существующие неинтерактивные клиенты принимали это изменение - поскольку exp. Короче они обновляют токен доступа раньше. - person arcseldon; 06.10.2017