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