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