L'authentification et l'autorisation sont des mécanismes utilisés pour vérifier respectivement l'identité et l'accès aux ressources. Ce document explique comment l'authentification et l'autorisation fonctionnent pour les requêtes de l'API REST Google Meet.
Ce guide explique comment utiliser OAuth 2.0 avec les identifiants Google d'un utilisateur pour accéder à l'API REST Meet. L'authentification et l'autorisation avec les identifiants utilisateur permettent aux applications Meet d'accéder aux données utilisateur et d'effectuer des opérations pour le compte de l'utilisateur authentifié. En s'authentifiant pour le compte d'un utilisateur, l'application dispose des mêmes autorisations que cet utilisateur et peut effectuer des actions comme si elles étaient effectuées par cet utilisateur.
Terminologie importante
Voici une liste de termes liés à l'authentification et à l'autorisation :
- Authentification
Action consistant à s'assurer qu'un compte principal, qui peut être un utilisateur
ou une application agissant pour le compte d'un utilisateur, est bien celui qu'il prétend être. Lorsque vous écrivez des applications Google Workspace, vous devez connaître ces types d'authentification : l'authentification utilisateur et l'authentification d'application. Pour l'API REST Meet, vous ne pouvez vous authentifier qu'à l'aide de l'authentification utilisateur.
- Autorisation
Autorisations ou "autorité" dont dispose le compte principal pour accéder
aux données ou effectuer des opérations. L'autorisation est effectuée via le code que vous écrivez dans votre application. Ce code informe l'utilisateur que l'application souhaite agir en son nom et, si elle est autorisée, utilise les identifiants uniques de votre application pour obtenir un jeton d'accès de Google afin d'accéder aux données ou d'effectuer des opérations.
Champs d'application de l'API REST Meet
Les champs d'application d'autorisation sont les autorisations que vous demandez aux utilisateurs d'autoriser pour que votre application puisse accéder au contenu de la réunion. Lorsqu'un utilisateur installe votre application, il est invité à valider ces champs d'application. En règle générale, vous devez choisir le champ d'application le plus précis possible et éviter de demander des champs d'application dont votre application n'a pas besoin. Les utilisateurs accordent plus facilement l'accès à des champs d'application limités et clairement décrits.
L'API REST Meet est compatible avec les champs d'application OAuth 2.0 suivants :
| Code du champ d'application | Description | Utilisation |
|---|---|---|
https://www.googleapis.com/auth/meetings.space.settings |
Modifiez et consultez les paramètres de tous vos appels Google Meet. | Non sensible |
https://www.googleapis.com/auth/meetings.space.created |
Autorisez les applications à créer, modifier et lire les métadonnées concernant les espaces de réunion créés par votre application. | Sensible |
https://www.googleapis.com/auth/meetings.space.readonly |
Autorisez les applications à lire les métadonnées de n'importe quel espace de réunion auquel l'utilisateur a accès. | Sensible |
https://www.googleapis.com/auth/drive.readonly |
Autorisez les applications à télécharger des fichiers d'enregistrement et de transcription à partir de l'API Google Drive. | Limité |
Le champ d'application OAuth 2.0 adjacent à Meet suivant se trouve dans la liste des champs d'application de l'API Google Drive :
| Code du champ d'application | Description | Utilisation |
|---|---|---|
https://www.googleapis.com/auth/drive.meet.readonly |
Affichez les fichiers Drive créés ou modifiés dans Google Meet. | Limité |
La colonne "Utilisation" du tableau indique la sensibilité de chaque champ d'application, selon les définitions suivantes :
Non sensible : ces champs d'application fournissent le plus petit champ d'application d'accès à l'autorisation et ne nécessitent qu'une validation de l'application de base. Pour en savoir plus, consultez la section Exigences liées à la validation.
Sensible : ces champs d'application permettent d'accéder à des données utilisateur Google spécifiques autorisées par l'utilisateur pour votre application. Vous devez passer par une validation supplémentaire de l'application. Pour en savoir plus, consultez la section Exigences liées aux champs d'application sensibles et limités.
Limité : ces champs d'application offrent un large accès aux données utilisateur Google et nécessitent de passer par un processus de validation des champs d'application limités. Pour en savoir plus, consultez les Règles relatives aux informations sur les utilisateurs dans les services des API Google et les Exigences supplémentaires pour des champs d'application d'API spécifiques. Si vous stockez des données de champ d'application limité sur des serveurs (ou si vous les transmettez), vous devez passer par une évaluation de la sécurité.
Si votre application nécessite d'accéder à d'autres API Google, vous pouvez également ajouter ces champs d'application. Pour en savoir plus sur les champs d'application des API Google, consultez la page Utiliser OAuth 2.0 pour accéder aux API Google.
Pour définir les informations affichées pour les utilisateurs et les évaluateurs d'applications, consultez la page Configurer l'écran de consentement OAuth et choisir des champs d'application.
Pour en savoir plus sur les champs d'application OAuth 2.0 spécifiques, consultez la section Champs d'application OAuth 2.0 pour les API Google.
S'authentifier et autoriser à l'aide de la délégation au niveau du domaine
Si vous êtes administrateur de domaine, vous pouvez accorder une délégation d'autorité au niveau du domaine pour autoriser le compte de service d'une application à accéder aux données de vos utilisateurs sans que chacun d'entre eux ait à donner son consentement. Une fois que vous avez configuré la délégation au niveau du domaine, le compte de service peut emprunter l'identité d'un compte utilisateur. Bien qu'un compte de service soit utilisé pour l'authentification, la délégation au niveau du domaine emprunte l'identité d'un utilisateur et est donc considérée comme une authentification utilisateur. Toute fonctionnalité nécessitant une authentification utilisateur peut utiliser la délégation au niveau du domaine.
Articles associés
Pour obtenir une présentation de l'authentification et de l'autorisation dans Google Workspace, consultez la page En savoir plus sur l'authentification et l'autorisation.
Pour obtenir une présentation de l'authentification et de l'autorisation dans Google Cloud, consultez la page Méthodes d'authentification chez Google.