Oauth2 - долгоживущие токены против повторной аутентификации в потоке учетных данных клиента

Мы обеспечили наш сервер REST OAuth2 и внедрили тип гранта клиентских учетных данных для нескольких клиентских приложений, которыми мы управляем. Теперь мы сталкиваемся с решением либо сделать токены долговечными (то есть они истекают "никогда" ), либо часто повторно проверять клиентов (в зависимости от обновления срок действия токена). Первое означает, что захваченный токен может использоваться злоумышленником, второй - очень часто раскрывает секрет клиента, который затем, в свою очередь, может быть использован для получения токенов.

Что более безопасно на сервере-сервере для аутентификации клиент-сервер? Как токен, так и секрет клиента могут быть признаны недействительными, если мы подозреваем кражу. Очевидно, что вся связь осуществляется через https..

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

Спасибо за ваши мысли!

Ответ 1

В соответствии с спецификацией поток клиента разрешен только для клиентов, которые не рискуют имея секрет клиента:

Тип предоставления учетных данных клиента ДОЛЖЕН использоваться только конфиденциальными клиентами.

Итак, если вы используете этот поток вместе с приложением на ненадежной платформе, вам обязательно нужно пересмотреть это решение.

При условии, что вашей платформе доверяют, нет необходимости беспокоиться об украденном секретном клиенте. Затем ваше решение приостанавливает взвешивание времени, в течение которого злоумышленник может сыграть с украденным токеном доступа по сравнению с дополнительными служебными данными для reauthentication (только один вызов, но тем не менее небольшая задержка). Шаг повторной проверки подлинности сам по себе является проблемой, связанной с отключением вашего клиента, когда обеим участникам доверяют, и вы используете хорошую защиту транспортного уровня от атак MITM.

Также обратите внимание, что не рекомендуется (а также ненужно) использовать токены обновления с помощью поток учетных данных клиента:

Тогг обновления НЕ ДОЛЖЕН быть включен.