Google is committed to advancing racial equity for Black communities. See how.
This page was translated by the Cloud Translation API.
Switch to English

Межклиентская идентификация

Когда разработчики создают программное обеспечение, оно обычно включает модули, которые запускаются на веб-сервере, другие модули, которые запускаются в браузере, и другие, которые работают как собственные мобильные приложения. И разработчики, и люди, использующие их программное обеспечение, обычно думают обо всех этих модулях как о части единого приложения.

Реализация Google OAuth 2.0 поддерживает этот взгляд на мир. Чтобы использовать любую из служб на основе OAuth2.0, вы должны настроить свое программное обеспечение в Google API Console. Единица организации в API Console - это «проект», который может соответствовать многокомпонентному приложению. Для каждого проекта вы можете предоставить информацию о бренде, и вы должны указать, к каким API будет получать доступ приложение. Каждый компонент многокомпонентного приложения идентифицируется идентификатором клиента , уникальной строкой, которая создается в файле API Console.

Цели межклиентской авторизации

Когда приложение использует OAuth 2.0 для авторизации, оно действует от имени пользователя, запрашивая токен доступа OAuth 2.0 для доступа к ресурсу, который приложение идентифицирует одной или несколькими строками области действия. Обычно пользователя просят подтвердить доступ.

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

Эффект заключается в том, что пользователю не следует запрашивать подтверждение доступа к любому ресурсу более одного раза для одного и того же логического приложения, когда компоненты приложения могут быть надежно аутентифицированы инфраструктурой авторизации Google, которая сегодня включает веб-приложения, приложения Android, Chrome приложения, приложения для iOS, собственные настольные приложения и устройства с ограниченным вводом.

Токены кросс-клиентского доступа

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

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

В результате, если приложение Android запрашивает токен доступа для определенной области, а запрашивающий пользователь уже предоставил одобрение веб-приложению в том же проекте для той же области, пользователю не будет предложено еще раз подтвердить. Это работает в обоих направлениях: если доступ к области действия был предоставлен в вашем приложении Android, он больше не будет требоваться от другого клиента в том же проекте, например, веб-приложения.