Подтвердить что ты не робот

Как и почему выполняется проверка маркера Google OAuth?

Между токенами доступа, токенами обновления, областями, аудиториями и идентификаторами клиентов, я был смущен, когда документация Google OAuth дала указание мне проверить все токены для предотвращения запутанной депутатской проблемы. Статья в Википедии, связанная с, описывает только общую проблему на высоком уровне, не относящуюся к OAuth или даже сетевой аутентификации. Если я правильно ее понимаю, проверка маркера не является частью OAuth2, но на самом деле зависит от конкретной реализации. Итак, вот мой вопрос:

Как и почему выполняется проверка маркера Google OAuth?

Конкретный пример запутанной депутатской проблемы в этом контексте будет особенно ценен. Также обратите внимание, что я прошу об этом в контексте полностью клиентских приложений, если это имеет значение.

4b9b3361

ОТВЕТЫ

Ответ 1

Google специально ссылается на токен доступа.

В контексте OAuth 2.0 запутанная проблема заместителя применяется к потоку Протокол неявного траста при использовании для аутентификации. То, что Google называет "OAuth 2.0 для клиентских приложений", основано на потоке неявного протокола протокола.

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

Критическим шагом в проверке токена доступа является то, что приложение проверяет, что токен доступа не был первоначально выпущен для другого приложения. Google обращает внимание на это, когда они говорят:

Примечание. При проверке токена важно обеспечить, чтобы поле аудитории в ответе точно соответствовало вашему client_id, зарегистрированному в консоли API. Это смягчение для запутанного депутатского вопроса, и абсолютно необходимо выполнить этот шаг.

В качестве упрощенного примера представьте, что есть два приложения: (1) FileStore, законное приложение для хранения файлов и (2) EvilApp. Оба приложения используют процесс аутентификации Google для клиентских приложений. Алиса - невинный конечный пользователь, а ее идентификатор пользователя Google - XYZ.

  • Алиса подписывается в FileStore с помощью Google.
  • После процесса auth FileStore создает учетную запись для Alice и связывает ее с идентификатором пользователя Google XYZ.
  • Алиса загружает некоторые файлы в свою учетную запись FileStore. Пока все в порядке.
  • Позже Алиса подписывается на EvilApp, который предлагает игры, которые выглядят очень весело.
  • В результате EvilApp получает токен доступа, связанный с идентификатором пользователя Google XYZ.
  • Теперь владелец EvilApp может создать URI перенаправления для FileStore, вставив маркер доступа, который был выпущен для учетной записи Alice Google.
  • Злоумышленник подключается к FileStore, который принимает токен доступа и проверяет с помощью Google, для какого пользователя он предназначен. Google скажет, что это пользователь XYZ.
  • FileStore предоставит злоумышленнику доступ к файлам Alice, поскольку у злоумышленника есть токен доступа для пользователя Google XYZ.

Ошибка FileStore не подтвердила с Google, что токен доступа, который был предоставлен, был действительно выдан FileStore; маркер действительно был выпущен EvilApp.

Другие говорили об этом гораздо элегантнее, чем я:

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

Ответ 2

Как вы используете OAuth2? Получаете ли вы код авторизации и обменете токены обновления? Или вы получаете токены доступа напрямую через свой интерфейс?

Если вы получаете код авторизации, вы закончили, так как проверка на client_secret, выполненная Google в бэкэнд, гарантирует, что все токены, возвращенные в обмен на код авторизации, были выпущены для вашего приложения.

Если вы получаете access_token + id_token через интерфейс, то вы должны проверить подпись id_token с использованием рекомендуемых библиотек, а затем подтвердить, что поле aud в id_token соответствует тому, которое вы зарегистрировали для своего приложения с Google. Для полной защиты также перекрестно проверяйте access_token с id_token (id_token включает в себя усеченный хеш access_token как поданный "at_hash" ), как описано в: https://developers.google.com/accounts/docs/OAuth2Login