Google стремится продвигать расовое равенство для чернокожих сообществ. Смотри как.
Эта страница переведена с помощью 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, он больше не будет требоваться от другого клиента в том же проекте, например, веб-приложения.