Identité multicompte

Lorsque les développeurs créent un logiciel, il comprend généralement des modules exécutés sur un serveur Web, d'autres exécutés dans le navigateur et d'autres exécutés en tant qu'applications mobiles natives. Les développeurs et les utilisateurs de leur logiciel considèrent généralement tous ces modules comme faisant partie d'une seule application.

L'implémentation OAuth 2.0 de Google est compatible avec cette vision du monde. Pour utiliser l'un des services basés sur OAuth 2.0, vous devez configurer votre logiciel dans Google API Console. L'unité d'organisation dans API Console est un "projet", qui peut correspondre à une application à plusieurs composants. Pour chaque projet, vous pouvez fournir des informations de branding et spécifier les API auxquelles l'application aura accès. Chaque composant d'une application multicomposant est identifié par un ID client, une chaîne unique générée dans API Console.

Objectifs d'autorisation multi-clients

Lorsqu'une application utilise OAuth 2.0 pour l'autorisation, elle agit au nom d'un utilisateur pour demander un jeton d'accès OAuth 2.0 afin d'accéder à une ressource, qu'elle identifie par une ou plusieurs chaînes de champ d'application. Normalement, l'utilisateur est invité à approuver l'accès.

Lorsqu'un utilisateur accorde l'accès à votre application pour un champ d'application particulier, il consulte l'écran d'autorisation de l'utilisateur, qui inclut le branding de produit au niveau du projet que vous avez configuré dans Google API Console. Par conséquent, Google considère qu'un utilisateur qui accorde l'accès à un champ d'application particulier à un ID client dans un projet indique sa confiance dans l'ensemble de l'application pour ce champ d'application.

L'utilisateur ne doit donc pas être invité à approuver l'accès à une ressource plus d'une fois pour la même application logique, chaque fois que les composants de l'application peuvent être authentifiés de manière fiable par l'infrastructure d'autorisation de Google, qui comprend aujourd'hui les applications Web, les applications Android, les applications Chrome, les applications iOS, les applications de bureau natives et les appareils à saisie limitée.

Jetons d'accès interclients

Les logiciels peuvent obtenir des jetons d'accès OAuth 2.0 de différentes manières, en fonction de la plate-forme sur laquelle le code est exécuté. Pour en savoir plus, consultez la section Utiliser OAuth 2.0 pour accéder aux API Google. Normalement, l'approbation de l'utilisateur est requise pour accorder un jeton d'accès.

Heureusement, l'infrastructure d'autorisation Google peut utiliser les informations sur les approbations des utilisateurs pour un ID client dans un projet donné pour déterminer si d'autres utilisateurs doivent être autorisés dans le même projet.

En conséquence, si une application Android demande un jeton d'accès pour un champ d'application particulier et que l'utilisateur à l'origine de la demande a déjà accordé son approbation à une application Web du même projet pour ce même champ d'application, l'utilisateur n'est plus invité à approuver à nouveau. Cela fonctionne dans les deux sens: si l'accès à un champ d'application a été accordé dans votre application Android, il ne sera plus demandé à un autre client du même projet, tel qu'une application Web.