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

Question

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

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

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

Answer 1

Google ссылается конкретно на токен доступа.

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

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

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

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

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

1. Алиса входит в FileStore с помощью Google.
2. После процесса аутентификации FileStore создает учетную запись для Алисы и связывает ее с идентификатором пользователя Google XYZ.
3. Алиса загружает некоторые файлы в свою учетную запись FileStore. Пока все хорошо.
4. Позже Алиса входит в EvilApp, которая предлагает игры, которые выглядят забавно.
5. В результате EvilApp получает токен доступа, связанный с идентификатором пользователя Google XYZ.
6. Владелец EvilApp теперь может создать URI перенаправления для FileStore, вставив маркер доступа, который был выдан для учетной записи Алисы в Google.
7. Злоумышленник подключается к FileStore, который получит токен доступа и сверится с Google, чтобы узнать, для какого пользователя он. Google скажет, что это пользователь XYZ.
8. FileStore предоставит злоумышленнику доступ к файлам Алисы, поскольку у злоумышленника есть токен доступа для пользователя Google XYZ.

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

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

• http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application.html
• http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
• http://tools.ietf.org/html/rfc6749

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

Answer 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