Должен ли истекать срок действия токенов доступа OAuth2 для мобильного приложения?
принятый ответ здесь как почему токены доступа OAuth2 истекают:
- многие поставщики поддерживают токены на предъявителя, которые очень слабы в плане безопасности. Делая их недолговечными и требующими обновления, они ограничивают время, когда злоумышленник может злоупотреблять украденным токеном. (что это значит? Я понимаю это как разрешить передачу без TLS? Что-нибудь еще?).
- крупномасштабное развертывание не хочет выполнять поиск базы данных каждый вызов API, поэтому вместо того, чтобы они самостоятельно закодированных маркер доступа, который может быть проверен путем дешифрования. Однако это также означает, что нет способа отозвать эти токены, поэтому они выдаются на короткое время и должны быть обновлены.
- маркер обновления требует аутентификации клиента, что делает его более сильным. В отличие от вышеуказанных маркеров доступа, он обычно реализуется с помощью поиска базы данных.
предполагая, что мы не поддерживаем незашифрованную передачу токена доступа, заботится о первая точка пуля.
предполагая, что мы в порядке с выполнением поиска базы данных против отзываемого, полностью случайного маркера доступа заботится о втором.
для мобильных приложений аутентификация клиента не может быть сильнее, потому что " client_id и client_secret, полученные при регистрации, встроены в исходный код вашего приложения. В этом контексте client_secret явно не рассматривается как секрет."( Google). Это исключает третья проблема.
Итак, в чем преимущество разделения кратковременных токенов доступа и долгоживущих токенов обновления в этом сценарии? Это "хорошо", чтобы просто выдавать маркеры доступа без истечения срока действия и игнорировать всю часть токена обновления?
3 ответов
разница между токеном обновления и маркером доступа без истечения срока действия в средствах безопасности - это один дополнительный вызов сервера авторизации.
Если злоумышленник получает доступ к вашей не истекающий токен доступа, он может напрямую позвонить на ваш сервер ресурсов и получить конфиденциальные данные в качестве ответа.
Теперь, если он украл ваш маркер, Он сначала должен вызвать сервер авторизации и получить маркер доступа в ответ. Тогда он может запросить сервер ресурсов для конфиденциальных данных.
каждый раз, когда маркер доступа запрашивается с вашего сервера авторизации с помощью маркера обновления, спецификация OAuth 2 (по крайней мере, последний проект на данный момент) требует от сервера проверить личность клиента, и если он привязан к маркеру, если это возможно.
поскольку обычный подход с секретом клиента не работает, чтобы определенно идентифицировать установленное приложение на открытой платформе, Платформа под управлением приложение должно предоставить методы для этого. Google, например, требует, чтобы приложения Android были подписаны разработчиком. При запросе учетных данных для приложения Android с помощью в Google API в консоли, поэтому вы должны указать отпечаток сертификата, который вы использовали для подписания заявления и получить только идентификатор клиента, но не секрет в ответ. При выдаче токенов Google может решить, было ли приложение авторизовано разработчиком для запросите жетоны на его имя.
Если вы определенно не можете проверить личность клиента, по крайней мере, в некоторых случаях можно распознать, что маркер обновления был украден. Спецификация имеет пример:
когда аутентификация клиента невозможна, сервер авторизации должен развернуть другие средства для обнаружения злоупотребления токеном обновления.
например, сервер авторизации может использовать вращение маркер обновления в который новый маркер обновления выдается с каждым ответом на обновление маркера доступа. Предыдущий маркер обновления недействителен, но сохраняется сервером авторизации. Если маркер обновления скомпрометирован и впоследствии используется как злоумышленником, так и законным клиентом, один из них представит недействительный маркер обновления, который сообщит серверу авторизации о нарушении.
самая большая проблема с не истекающим токеном доступа заключается в том, что нет механизма для замены украденного токена. Если я получаю доступ к вашему маркеру доступа без истечения срока действия, то я фактически вы для этой системы. Если токен недолговечен и истекает, то есть механизм замены украденного токена и ограничение на окно я должен взломать ваш токен.
предположим, мне требуется 3 часа, чтобы взломать пакет и получить токен, но токен доступа хорош только для двух несколько часов. Затем, к тому времени, когда я не могу взломать вашу учетную запись, токен изменился, и я должен начать все сначала. Если токен не истекает, у меня есть полный доступ к вашей учетной записи, и у вас нет возможности заменить его, кроме удаления токена и принудительной повторной авторизации.
токены доступа OAuth2 не должны истекать (или, скорее, они истекают, но это может быть через много лет).
маркер доступа может использоваться один раз для получения определенных ресурсов с сервера ресурсов, в частности, он позволяет получать ресурсы, одобренные пользователем. Маркер обновления, с другой стороны, позволяет повторный доступ. Таким образом, нельзя избавиться от токенов обновления, не требуя взаимодействия пользователя между каждым доступом.
в целом, хотя, токены иногда могут быть украдены другими вредоносными приложениями на том же устройстве или атаками MITM на телефоне. SSL способен MITM, если телефон можно заставить доверять сомнительному сертификату. Это иногда требуется компаниями для доступа к внутренним сетям (они требуют принятия самозаверяющего сертификата, который позволяет им MITM весь зашифрованный трафик, происходящий по сети компании. Таким образом, предполагая, что отправка зашифрованных токенов означает, что они не могут быть украдены в пути, опасно.
токены на предъявителя не слабее, чем любая другая форма токена как таковая, как доказано в куче документов (включая один из моих собственных, на который я отправлю ссылку, когда смогу его откопать.) Однако токены на предъявителя подходят только в тех случаях, когда допущения, которые они делают, действительны. Предположение о том, что токен может храниться в секрете, является основным предположением о токенах на предъявителя в целом. Если это не так, токены-носители не утверждают никаких свойств безопасности (хотя некоторые из них все еще сохраняются). См.NIST Уровень 3 токены, которые определяют, какие атаки токены-носители должны победить, как указано в Токены На Предъявителя OAuth. Короче говоря, токены на предъявителя не должны побеждать кражу токена.
токены на предъявителя не могут быть отозваны, это правда. Однако, учитывая, что обычным шаблоном доступа является использование маркера доступа сразу после приобретения, токены доступа должны истекать довольно быстро, чтобы предотвратить потенциальное злоупотребление, даже если случай злоупотребления не может быть придумано в настоящее время. Чем дольше находится токен, тем больше вероятность его кражи. Маркер обновления на самом деле гораздо опаснее украсть, поскольку он обеспечивает повторный доступ в течение более длительного периода времени, если вы не можете защитить идентификатор клиента. OAuth2 может предоставить доступ к ресурсам в целом и, например, может использоваться для предоставления API клиенту на время. С помощью токена обновления можно нанести значительно больший ущерб, в отличие от одного токена использования.
клиент аутентификацию можно сделать более безопасной несколькими способами, например, предоставляя каждому клиенту при загрузке другой ключ. Это предотвращает обобщенные атаки, когда обратное проектирование маркера на одном устройстве нарушает безопасность для всех экземпляров клиента. Другие потенциальные методы включают использование OAuth для проверки клиента с вашим сервером, который затем выполняет второй запуск протокола OAuth с сервером авторизации, к которому вы хотите получить доступ. Это позволяет вам иметь клиентов, которые обновляют их ключи регулярно, и для них у всех должны быть разные ключи, при этом не создавая чрезмерной нагрузки на системы, используемые сервером авторизации, принадлежащим Facebook или Google, например.
при использовании мобильного приложения долговечные токены обновления более безопасны, чем наличие какого-либо многофункционального токена на предъявителя, даже если не предпринимаются шаги для защиты клиента. Это происходит потому, что пользователь не может очистить маркер. Если токен обновления не украден, и пользователь просто хочет отозвать доступ тогда это можно сделать. Токен многоцелевого носителя не может быть отозван, даже если пользователь просто хочет отозвать доступ. Очевидно, что многофункциональный ссылочный маркер базы данных может быть отозван, но это не то, для чего предназначен протокол, и поэтому анализ безопасности, выполненный на OAuth, ничего не говорит о безопасности этой гибридной системы.
В заключение я бы рекомендовал использовать токены обновления и токены базы данных, так как это, скорее всего, будет безопасно. Если вы можете сделать все, чтобы защитить клиента, это бонус, но ситуации, которые это защищает, минимальны. Если вы хотите защитить клиента, рассмотрите мягкие токены, a la Google authenticator, поскольку это твердая реализация, которая выдержала анализ некоторыми очень умными людьми.