OAuth 2.0 pour les applications TV et périphériques à saisie limitée

Ce document explique comment implémenter l'autorisation d'accès OAuth 2.0 l'API YouTube Data via des applications exécutées sur des appareils tels que des téléviseurs, des consoles de jeu des imprimantes. Plus précisément, cette procédure est conçue pour les appareils dans un navigateur ou ont des capacités de saisie limitées.

OAuth 2.0 permet aux utilisateurs de partager des données spécifiques avec une application tout en conservant leur nom d'utilisateur, leur mot de passe et toute autre information privée. Par exemple, une application TV peut utiliser OAuth 2.0 pour obtenir l'autorisation de sélectionner un fichier stocké sur Google Drive.

Étant donné que les applications qui utilisent ce flux sont distribuées sur des appareils individuels, il est suppose que les applications ne peuvent pas conserver de secrets. Elles peuvent accéder aux API Google lorsque l'utilisateur présentes dans l'application ou lorsque celle-ci s'exécute en arrière-plan.

Alternatives

Si vous développez une application pour une plate-forme telle qu'Android, iOS, macOS, Linux ou Windows (y compris la plate-forme Windows universelle), ayant accès au navigateur et à toutes les entrées utilisez le flux OAuth 2.0 pour appareils mobiles et des applications de bureau. Vous devez utiliser ce flux même si votre application est une sans interface graphique.)

Si vous souhaitez uniquement connecter les utilisateurs avec leur compte Google et utiliser Jeton d'ID JWT permettant d'obtenir des informations de base sur le profil utilisateur consultez la section Connexion sur les téléviseurs et les périphériques d'entrée limités

Prérequis

Activer les API pour votre projet.

Toute application qui appelle des API Google doit activer ces API dans le API Console

Pour activer une API pour votre projet:

  1. Open the API Library dans la Google API Console
  2. If prompted, select a project, or create a new one.
  3. Accédez à la page "Bibliothèque" pour trouver et activer l'API YouTube Data. Recherchez les autres API que votre application utilisera et activez-les également.

Créer des identifiants d'autorisation

Toute application qui utilise OAuth 2.0 pour accéder aux API Google doit disposer d'identifiants d'autorisation. qui identifient l'application auprès du serveur OAuth 2.0 de Google. Les étapes suivantes expliquent comment créer des identifiants pour votre projet. Vos applications peuvent ensuite utiliser les identifiants pour accéder aux API que vous avez activées pour ce projet.

  1. Go to the Credentials page.
  2. Cliquez sur Créer des identifiants > ID client OAuth.
  3. Sélectionnez le type d'application Téléviseurs et périphériques d'entrée limités.
  4. Nommez votre client OAuth 2.0, puis cliquez sur Créer.

Identifier les niveaux d'accès

Les niveaux d'accès permettent à votre application de ne demander l'accès qu'aux ressources dont elle a besoin, tout en permettant aux utilisateurs de contrôler le niveau d'accès qu'ils accordent à votre application. Il existe donc peut représenter une relation inverse entre le nombre de champs d'application demandés et la probabilité l'obtention du consentement de l'utilisateur.

Avant de commencer à implémenter l'autorisation OAuth 2.0, nous vous recommandons d'identifier les champs d'application auxquelles votre application a besoin d'une autorisation d'accès.

La version 3 de l'API YouTube Data utilise les champs d'application suivants:

Niveaux d'accès
https://www.googleapis.com/auth/youtubeGérez votre compte YouTube.
https://www.googleapis.com/auth/youtube.channel-memberships.creatorConsulter la liste des membres actuellement actifs de votre chaîne, leur niveau actuel et leur date de souscription
https://www.googleapis.com/auth/youtube.force-sslAfficher, modifier et supprimer définitivement vos vidéos, notes, commentaires et sous-titres YouTube
https://www.googleapis.com/auth/youtube.readonlyConsultez votre compte YouTube.
https://www.googleapis.com/auth/youtube.uploadGérez vos vidéos YouTube.
https://www.googleapis.com/auth/youtubepartnerAffichez et gérez vos éléments et le contenu associé sur YouTube.
https://www.googleapis.com/auth/youtubepartner-channel-auditAffichez les informations privées sur votre chaîne YouTube pertinentes pendant le processus d'audit avec un partenaire YouTube.

Consultez la liste des habilitations autorisées pour les applications ou les appareils installés.

Obtenir des jetons d'accès OAuth 2.0

Même si votre application s'exécute sur un appareil doté de capacités de saisie limitées, les utilisateurs doivent avoir un accès distinct à un appareil avec des capacités de saisie plus riches pour terminer ce flux d'autorisation. Le flux comporte les étapes suivantes:

  1. Votre application envoie au serveur d'autorisation de Google une requête qui identifie les champs d'application. auquel votre application demandera l'autorisation d'accéder.
  2. Le serveur répond avec plusieurs informations utilisées dans les étapes suivantes, comme un code de l'appareil et un code utilisateur.
  3. Vous affichez les informations que l'utilisateur peut saisir sur un autre appareil pour autoriser votre l'application.
  4. Votre application commence à interroger le serveur d'autorisation de Google pour déterminer si l'utilisateur a autorisé votre application.
  5. L'utilisateur passe à un appareil avec des fonctionnalités de saisie plus riches, lance un navigateur web, accède à l'URL affichée à l'étape 3 et saisit un code qui est également affiché à l'étape 3. La peut alors accorder (ou refuser) l'accès à votre application.
  6. La réponse suivante à votre demande d'interrogation contient les jetons que votre application doit autoriser. des requêtes au nom de l'utilisateur. (Si l'utilisateur a refusé l'accès à votre application, la réponse ne contient pas de jetons.)

L'image ci-dessous illustre ce processus:

L'utilisateur se connecte sur un autre appareil doté d'un navigateur

Les sections suivantes décrivent ces étapes en détail. Compte tenu des capacités et de l'environnement d'exécution que peuvent comporter les appareils, les exemples présentés dans ce document utilisent l'curl de ligne de commande. Ces exemples doivent être faciles à transférer dans différents langages et environnements d'exécution.

Étape 1: Demandez des codes d'appareil et d'utilisateur

Au cours de cette étape, votre appareil envoie une requête HTTP POST au serveur d'autorisation de Google, à l'adresse https://oauth2.googleapis.com/device/code, qui identifie votre application ainsi que les niveaux d'accès auxquels votre application souhaite accéder au nom de l'utilisateur. Vous devez récupérer cette URL à partir du Document de découverte à l'aide de la classe Valeur de métadonnées device_authorization_endpoint. Incluez la requête HTTP suivante paramètres:

Paramètres
client_id Obligatoire

ID client de votre application. Vous trouverez cette valeur dans le API Console Credentials page

scope Obligatoire

A délimité par des espaces des champs d'application qui identifient les ressources auxquelles votre application pourrait accéder au nom de l'utilisateur. Ces valeurs déterminent l'écran de consentement que Google présente aux utilisateurs utilisateur. Consultez le Liste des habilitations autorisées pour les applications ou appareils installés.

Les niveaux d'accès permettent à votre application de ne demander l'accès qu'aux ressources dont elle a besoin tout en permettant aux utilisateurs de contrôler le niveau d'accès qu'ils accordent application. Ainsi, il existe une relation inverse entre le nombre de champs d'application demandés et la probabilité d'obtenir le consentement de l'utilisateur.

La version 3 de l'API YouTube Data utilise les champs d'application suivants:

Niveaux d'accès
https://www.googleapis.com/auth/youtubeGérez votre compte YouTube.
https://www.googleapis.com/auth/youtube.channel-memberships.creatorConsulter la liste des membres actuellement actifs de votre chaîne, leur niveau actuel et leur date de souscription
https://www.googleapis.com/auth/youtube.force-sslAfficher, modifier et supprimer définitivement vos vidéos, notes, commentaires et sous-titres YouTube
https://www.googleapis.com/auth/youtube.readonlyConsultez votre compte YouTube.
https://www.googleapis.com/auth/youtube.uploadGérez vos vidéos YouTube.
https://www.googleapis.com/auth/youtubepartnerAffichez et gérez vos éléments et le contenu associé sur YouTube.
https://www.googleapis.com/auth/youtubepartner-channel-auditAffichez les informations privées sur votre chaîne YouTube pertinentes pendant le processus d'audit avec un partenaire YouTube.

Le document sur les champs d'application de l'API OAuth 2.0 fournit une liste complète des champs d'application que vous pouvez utiliser pour accéder aux API Google.

Exemples

L'extrait de code suivant présente un exemple de requête:

POST /device/code HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=client_id&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl

Cet exemple montre une commande curl permettant d'envoyer la même requête:

curl -d "client_id=client_id&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl" \
     https://oauth2.googleapis.com/device/code

Étape 2: Gérer la réponse du serveur d'autorisation

Le serveur d'autorisation renvoie l'une des réponses suivantes:

Réponse de réussite

Si la requête est valide, votre réponse est un objet JSON contenant les éléments suivants : propriétés:

Propriétés
device_code Valeur attribuée de façon unique par Google pour identifier l'appareil qui exécute l'application à l'origine de la demande une autorisation. L'utilisateur autorisera cet appareil à partir d'un autre appareil avec des fonctionnalités plus riches les capacités d'entrée. Par exemple, un utilisateur peut utiliser un ordinateur portable ou un téléphone mobile pour autoriser une une application exécutée sur un téléviseur. Dans ce cas, device_code identifie le téléviseur.

Ce code permet à l'appareil exécutant l'application de déterminer de manière sécurisée si l'utilisateur a accordé ou refusé l'accès.

expires_in Durée, en secondes, pendant laquelle les device_code et user_code sont des valeurs correctes. Si, dans ce laps de temps, l'utilisateur n'effectue pas l'opération flux d'autorisation, et votre appareil n'interroge pas le système pour récupérer des informations décision de l'utilisateur, vous devrez peut-être recommencer ce processus à partir de l'étape 1.
interval Durée d'attente, en secondes, entre chaque demande d'interrogation de votre appareil. Pour Par exemple, si la valeur est 5, votre appareil doit envoyer une demande d'interrogation à toutes les cinq secondes. Voir étape 3.
user_code Valeur sensible à la casse qui identifie pour Google les habilitations auxquelles l'application s'applique. demandant l'accès. Votre interface utilisateur demandera à l'utilisateur de saisir cette valeur sur un appareil distinct avec des capacités d'entrée plus riches. Google utilise ensuite cette valeur pour afficher les niveaux d'accès appropriés lorsque l'utilisateur est invité à accorder l'accès à votre application.
verification_url URL à laquelle l'utilisateur doit accéder, sur un autre appareil, pour saisir le user_code, et autorisez ou refusez l'accès à votre application. Votre interface utilisateur affichera également cette valeur.

L'extrait de code suivant montre un exemple de réponse:

{
  "device_code": "4/4-GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8",
  "user_code": "GQVQ-JKEC",
  "verification_url": "https://www.google.com/device",
  "expires_in": 1800,
  "interval": 5
}

Réponse de dépassement de quota

Si vos requêtes de code d'appareil ont dépassé le quota associé à votre ID client, vous devrez recevez une réponse 403 contenant l'erreur suivante:

{
  "error_code": "rate_limit_exceeded"
}

Dans ce cas, utilisez une stratégie d'intervalle entre les tentatives afin de réduire le taux de requêtes.

Étape 3: Affichez le code utilisateur

Affichez les verification_url et user_code obtenus à l'étape 2 dans la utilisateur. Les deux valeurs peuvent contenir n'importe quel caractère imprimable du jeu de caractères US-ASCII. Le contenu que vous présentez à l'utilisateur doit lui demander d'accéder au verification_url sur un appareil distinct et saisissez le user_code.

Concevez votre interface utilisateur en tenant compte des règles suivantes:

  • user_code
    • L'élément user_code doit être affiché dans un champ pouvant gérer 15 "W". taille [size] caractères. En d'autres termes, si vous pouvez afficher le code WWWWWWWWWWWWWWW correctement, votre interface utilisateur est valide. Nous vous recommandons d'utiliser cette valeur de chaîne lorsque vous testez la façon user_code s'affiche dans votre interface utilisateur.
    • Le champ user_code est sensible à la casse et ne doit en aucun cas être modifié. comme le changement de casse ou l’insertion d’autres caractères de mise en forme.
  • verification_url
    • L'espace dans lequel vous affichez le verification_url doit être suffisamment large pour pour gérer une chaîne d'URL de 40 caractères.
    • Vous ne devez en aucun cas modifier verification_url, sauf pour supprimer le schéma à afficher. Si vous envisagez de supprimer le schéma (par exemple, https://) à partir de l'URL pour des raisons d'affichage, assurez-vous que votre application à la fois http et https.

Étape 4: Interrogez le serveur d'autorisation de Google

Étant donné que l'utilisateur utilisera un appareil distinct pour accéder à verification_url et d'accorder (ou de refuser) l'accès, l'appareil à l'origine de la demande n'est pas automatiquement averti lorsque l'utilisateur répond à la demande d'accès. Pour cette raison, l'appareil à l'origine de la demande doit interroger d'autorisation pour déterminer quand l'utilisateur a répondu à la requête.

L'appareil demandeur doit continuer à envoyer des requêtes d'interrogation jusqu'à ce qu'il reçoive une réponse indiquant que l'utilisateur a répondu à la demande d'accès ou jusqu'à ce que device_code et user_code obtenu en de l'étape 2 ont expiré. La valeur interval renvoyée à l'étape 2 indique la quantité de le temps d'attente, exprimé en secondes, entre les requêtes.

L'URL du point de terminaison à interroger est https://oauth2.googleapis.com/token. La demande d'interrogation contient les paramètres suivants:

Paramètres
client_id ID client de votre application. Vous trouverez cette valeur dans le API Console Credentials page
client_secret Code secret du client pour l'élément client_id fourni. Vous trouverez cette valeur dans le API Console Credentials page
device_code Le device_code renvoyé par le serveur d'autorisation dans étape 2.
grant_type Définissez cette valeur sur urn:ietf:params:oauth:grant-type:device_code.

Exemples

L'extrait de code suivant présente un exemple de requête:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=client_id&
client_secret=client_secret&
device_code=device_code&
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code

Cet exemple montre une commande curl permettant d'envoyer la même requête:

curl -d "client_id=client_id&client_secret=client_secret& \
         device_code=device_code& \
         grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code" \
         -H "Content-Type: application/x-www-form-urlencoded" \
         https://oauth2.googleapis.com/token

Étape 5: L'utilisateur répond à la demande d'accès

L'image suivante montre une page semblable à celle que les utilisateurs voient lorsqu'ils accèdent à verification_url que vous avez affichée à l'étape 3:

Connectez un appareil en saisissant un code

Après avoir saisi user_code et, si ce n'est pas déjà fait, connectez-vous à Google, l'utilisateur voit un écran de consentement semblable à celui présenté ci-dessous:

Exemple d'écran de consentement pour un client d'appareil

Étape 6: Gérer les réponses aux requêtes d'interrogation

Le serveur d'autorisation de Google répond à chaque requête d'interrogation avec l'un des éléments suivants : réponses:

Accès autorisé

Si l'utilisateur a autorisé l'accès à l'appareil (en cliquant sur Allow sur l'écran d'autorisation), alors la réponse contient un jeton d'accès et un jeton d'actualisation. Les jetons permettent à votre appareil Accéder aux API Google au nom de l'utilisateur (Le scope de la réponse détermine les API auxquelles appareil peut accéder.)

Dans ce cas, la réponse de l'API contient les champs suivants:

Champs
access_token Jeton envoyé par votre application pour autoriser une requête API Google.
expires_in Durée de vie restante du jeton d'accès, en secondes.
refresh_token Jeton que vous pouvez utiliser pour obtenir un nouveau jeton d'accès. Les jetons d'actualisation sont valides jusqu'au l'utilisateur révoque l'accès. Notez que les jetons d'actualisation sont toujours renvoyés pour les appareils.
scope Les champs d'application d'accès accordés par le access_token, exprimés sous la forme d'une liste de délimitées par des espaces et sensibles à la casse.
token_type Type de jeton renvoyé. Pour le moment, la valeur de ce champ est toujours définie sur Bearer

L'extrait de code suivant montre un exemple de réponse:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "openid https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email",
  "token_type": "Bearer",
  "refresh_token": "1/xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

Les jetons d'accès ont une durée de vie limitée. Si votre application a besoin d'accéder à une API sur une longue période il peut utiliser le jeton d'actualisation pour obtenir un nouvel accès à partir d'un jeton d'accès. Si votre application a besoin de ce type d'accès, elle doit stocker le jeton d'actualisation pour une utilisation ultérieure.

Accès refusé

Si l'utilisateur refuse d'accorder l'accès à l'appareil, la réponse du serveur affiche une Code d'état de la réponse HTTP 403 (Forbidden). La réponse contient erreur suivante:

{
  "error": "access_denied",
  "error_description": "Forbidden"
}

Autorisation en attente

Si l'utilisateur n'a pas encore terminé le flux d'autorisation, le serveur renvoie une Code d'état de la réponse HTTP 428 (Precondition Required). La réponse contient l'erreur suivante:

{
  "error": "authorization_pending",
  "error_description": "Precondition Required"
}

Interrogation trop fréquente

Si l'appareil envoie des requêtes d'interrogation trop fréquemment, le serveur renvoie une réponse 403. Code d'état de la réponse HTTP (Forbidden). La réponse contient les éléments suivants : erreur:

{
  "error": "slow_down",
  "error_description": "Forbidden"
}

Autres erreurs

Le serveur d'autorisation renvoie également des erreurs s'il manque des éléments obligatoires dans la demande d'interrogation. ou contient une valeur de paramètre incorrecte. Ces requêtes ont généralement un 400 État de la réponse HTTP (Bad Request) ou 401 (Unauthorized) du code source. Voici quelques-unes de ces erreurs:

Erreur HTTP Status Code Description
admin_policy_enforced 400 Le compte Google n'est pas en mesure d'autoriser une ou plusieurs des habilitations demandées en raison de la de leur administrateur Google Workspace. Consultez l'aide Administrateur Google Workspace pour en savoir plus sur l'optimisation des campagnes les applications internes à accéder aux données Google Workspace. l'administrateur peut limiter l'accès aux niveaux d'accès jusqu'à ce que l'accès soit explicitement accordé à votre ID client.
invalid_client 401

Le client OAuth est introuvable. Par exemple, cette erreur se produit si le La valeur du paramètre client_id n'est pas valide.

Le type de client OAuth est incorrect. Vérifiez que la propriété type d'application pour l'ID client est défini sur Téléviseurs et périphériques d'entrée limités.

invalid_grant 400 La valeur du paramètre code n'est pas valide, a déjà été revendiquée ou ne peut pas l'être analysées.
unsupported_grant_type 400 La valeur du paramètre grant_type n'est pas valide.
org_internal 403 L'ID client OAuth de la requête fait partie d'un projet limitant l'accès aux comptes Google. dans un environnement Organisation Google Cloud. Confirmez le type d'utilisateur la configuration de votre application OAuth.

Appeler des API Google

Une fois que votre application a obtenu un jeton d'accès, vous pouvez l'utiliser pour effectuer des appels vers pour le compte d'un service compte utilisateur si les niveaux d'accès requis par l'API ont été accordés. Pour ce faire, incluez le jeton d'accès dans une requête adressée à l'API en incluant une requête access_token ou une valeur Bearer d'en-tête HTTP Authorization. Si possible, l'en-tête HTTP est préférable, car les chaînes de requête ont tendance à être visibles dans les journaux du serveur. Dans la plupart des cas vous pouvez utiliser une bibliothèque cliente pour configurer vos appels aux API Google (par exemple, lorsque appeler l'API YouTube Live Streaming).

Notez que l'API YouTube Live Streaming n'est pas compatible avec le flux du compte de service. Puisqu'il y a ne permet pas d'associer un compte de service à un compte YouTube, tente d'autoriser les demandes avec ce génère une erreur NoLinkedYouTubeAccount.

Vous pouvez essayer toutes les API Google et consulter leurs champs d'application à la OAuth 2.0 Playground.

Exemples de requête HTTP GET

Un appel à la fonction liveBroadcasts.list (l'API YouTube Live Streaming) à l'aide du protocole HTTP Authorization: Bearer peut se présenter comme suit. Notez que vous devez spécifier votre propre jeton d'accès:

GET /youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

Voici un appel à la même API pour l'utilisateur authentifié à l'aide de access_token. paramètre de chaîne de requête:

GET https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true

curl exemples

Vous pouvez tester ces commandes avec l'application de ligne de commande curl. Voici un exemple qui utilise l'option d'en-tête HTTP (recommandé):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true

Vous pouvez également utiliser l'option de paramètre de chaîne de requête:

curl https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true

Actualiser un jeton d'accès

Les jetons d'accès expirent régulièrement et deviennent des identifiants non valides pour une requête API associée. Toi peut actualiser un jeton d'accès sans demander l'autorisation à l'utilisateur (y compris lorsqu'il est absente) si vous avez demandé un accès hors connexion aux champs d'application associés au jeton.

Pour actualiser un jeton d'accès, votre application envoie un POST HTTPS au serveur d'autorisation de Google (https://oauth2.googleapis.com/token) qui comprend les paramètres suivants:

Champs
client_id ID client obtenu à partir de API Console.
client_secret Code secret du client obtenu à partir de API Console.
grant_type En tant que définis dans le spécification OAuth 2.0, la valeur de ce champ doit être définie sur refresh_token.
refresh_token Jeton d'actualisation renvoyé par l'échange de code d'autorisation.

L'extrait de code suivant présente un exemple de requête:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=your_client_id&
client_secret=your_client_secret&
refresh_token=refresh_token&
grant_type=refresh_token

Tant que l'utilisateur n'a pas révoqué l'accès accordé à l'application, le serveur de jetons La fonction renvoie un objet JSON contenant un nouveau jeton d'accès. L'extrait de code suivant montre un exemple réponse:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
  "token_type": "Bearer"
}

Notez que le nombre de jetons d'actualisation qui seront émis est limité. une limite par combinaison client/utilisateur et une autre par utilisateur pour tous les clients. Enregistrer les jetons d'actualisation dans un espace de stockage à long terme et continuent à les utiliser tant qu'ils sont valides. Si votre application demande trop de jetons d'actualisation, il risque de dépasser ces limites, auquel cas les jetons d'actualisation plus anciens cesseront de fonctionner.

Révoquer un jeton

Dans certains cas, un utilisateur peut souhaiter révoquer l'accès accordé à une application. Un utilisateur peut révoquer l'accès en accédant à la page Paramètres du compte. Consultez le Supprimer de la section "Sites et applications tiers" applications ayant accès à votre compte pour en savoir plus.

Une application peut également révoquer de manière programmatique l'accès qui lui est accordé. La révocation par programmation est importante lorsqu'un utilisateur se désabonne, supprime application ou les ressources d'API requises par une application ont changé de manière significative. Autrement dit, peut inclure une requête API pour garantir que les autorisations précédemment accordées accordées à l'application sont supprimées.

Pour révoquer un jeton de manière programmatique, votre application envoie une requête à https://oauth2.googleapis.com/revoke et inclut le jeton en tant que paramètre:

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
        https://oauth2.googleapis.com/revoke?token={token}

Il peut s'agir d'un jeton d'accès ou d'un jeton d'actualisation. Si le jeton est un jeton d'accès et qu'il possède le jeton d'actualisation correspondant, il sera également révoqué.

Si la révocation a bien été traitée, le code d'état HTTP de la réponse est 200 Pour les conditions d'erreur, un code d'état HTTP 400 est renvoyé avec par un code d'erreur.

Champs d'application autorisés

Le flux OAuth 2.0 pour les appareils n'est compatible qu'avec les champs d'application suivants:

OpenID Connect, Google Sign-In

  • email
  • openid
  • profile

API Drive

  • https://www.googleapis.com/auth/drive.appdata
  • https://www.googleapis.com/auth/drive.file

API YouTube

  • https://www.googleapis.com/auth/youtube
  • https://www.googleapis.com/auth/youtube.readonly

Implémenter la protection multicompte

Une mesure supplémentaire à prendre pour protéger l'expérience utilisateur implémente les stratégies d'enchères à l'aide du service de protection multicompte de Google. Ce service vous permet vous abonner aux notifications d'événements liés à la sécurité, qui fournissent des informations à votre application sur des modifications majeures au compte utilisateur. Vous pouvez ensuite utiliser ces informations pour prendre des mesures en fonction de comment vous décidez de répondre aux événements.

Voici quelques exemples de types d'événements envoyés à votre application par le service de protection multicompte de Google:

  • https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
  • https://schemas.openid.net/secevent/oauth/event-type/token-revoked
  • https://schemas.openid.net/secevent/risc/event-type/account-disabled

Consultez le Protéger les comptes utilisateur grâce à la page "Protection multicompte" pour en savoir plus sur l'implémentation de la protection multicompte et obtenir la liste complète des événements disponibles.