Что мешает другому приложению украсть мой идентификатор клиента Google OAuth?

Question

Я создал приложение для Android, которое использует AppAuth для аутентификации в Google OAuth.В консоли Google Cloud Platform я создал идентификатор клиента Android OAuth 2.0 для своего приложения и предоставил имя пакета приложения и отпечаток сертификата подписи.Все работает нормально.

Я хотел убедиться, что только мое приложение может использовать этот идентификатор клиента.Поэтому я создал второе приложение с другим именем пакета и подписал его другим сертификатом подписи.Используя тот же идентификатор клиента, я все еще могу проходить аутентификацию в Google и получать доступ к API.Я не думаю, что это должно быть так.Я искал исходный код для AppAuth, и похоже, что он никогда не использует подпись приложения или имя пакета в процессе аутентификации.Конечно, он использует PKCE, но я ожидал, что произойдет больше.

Так что, если я могу украсть свой собственный идентификатор клиента без особых усилий, что помешает кому-то еще извлечь мой идентификатор клиента из моего APK и использовать его дляаутентификация?Пользовательскую схему, которую я использую для URI перенаправления, легко определить на основе имени моего пакета.Таким образом, приложение румян может настроить AppAuth на использование аналогичного URI перенаправления и захватить результат авторизации.А поскольку PKCE используется только для проверки того, что запрос на авторизацию и обмен кодами поступают из одного и того же места, приложение-рум будет делать и то, и другое, поэтому здесь нет реальной защиты.

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

Я что-то упустил или Google OAuth работает точно так, как предполагалось?

Answer 1

Для клиентской части Google OAuth 2 ваш идентификатор клиента не имеет значения.Клиент выполняет поток OAuth, а клиент получает токен OAuth.Волшебство в том, что клиент должен авторизовать Google.Любой может украсть ваш идентификатор клиента, но он не может ничего с этим поделать.В рамках жизненного цикла OAuth вы должны проверять токены OAuth.Ваши бэкэнды НЕ должны слепо принимать что-либо от клиента - или в любом месте, не находящемся под вашим абсолютным контролем.

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

Секрет клиента должен оставаться секретным. Секрет клиента не участвует в аутентификации на стороне клиента.Client Secret используется на ваших внутренних серверах.

Я думаю, что вы путаете процесс.Когда клиентское приложение (ваше приложение, веб-браузер и т. Д.) Проходит проверку подлинности с использованием учетных записей Google, ваше приложение не авторизуется.Клиент авторизуется.Клиент должен руководствоваться здравым смыслом в отношении того, какие веб-сайты он посещает (или приложения) и использует свои логины Google.Единственное, что клиент может сделать со своим токеном, - это получить доступ к своим собственным данным (Google Drive, Gmail и т. Д.).Если ваши внутренние серверы принимают токен OAuth клиента для управления доступом, тогда вы несете ответственность за проверку того токена и его желаемого использования в ваших системах, а также от того, у кого этот токен авторизован.

Лучше выбрать проверку подлинности.и авторизация на бэкэнде (например, ваш веб-сервер).Затем вы можете реализовать перенаправление Google OAuth для отправки токена OAuth на ваши серверы.Вы защищены тем, что в процесс аутентификации могут быть вовлечены только авторизованные источники (например, имя вашего домена) и авторизованные URI перенаправления (конечная точка на вашем веб-сервере).Затем вы сохраняете токен в сеансе клиента, обновляете при необходимости, при необходимости добавляете области авторизации и т. Д.

Я часто использую оба метода (на стороне клиента, на стороне сервера), и оба работают хорошо.