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