OAuth 2.0 pour les applications TV et appareils à saisie limitée

Ce document explique comment mettre en œuvre l'autorisation OAuth 2.0 pour accéder aux API Google à l'aide d'applications exécutées sur des appareils tels que des téléviseurs, des consoles de jeu et des imprimantes. Plus précisément, ce flux est conçu pour les appareils qui n'ont pas accès à un navigateur ou qui 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 préservant la confidentialité de leurs noms d'utilisateur, mots de passe et autres informations. 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, on suppose qu'elles ne peuvent pas garder de secrets. Ils peuvent accéder aux API Google lorsque l'utilisateur est présent dans l'application ou lorsque l'application s'exécute en arrière-plan.

Alternatives

Si vous souhaitez uniquement connecter les utilisateurs avec leur compte Google et utiliser un jeton d'ID JWT pour obtenir des informations de base sur leur profil, consultez Se connecter sur les téléviseurs et les appareils à saisie limitée.

Prérequis

Activer les API pour votre projet.

Toute application qui appelle des API Google doit activer ces API dans la console d'API.

Pour activer une API pour votre projet :

  1. Dans la console Google APIs, ouvrez la bibliothèque des API.
  2. Si vous y êtes invité, sélectionnez un projet ou créez-en un.
  3. La bibliothèque d'API répertorie toutes les API disponibles, regroupées par famille de produits et par popularité. Si l'API que vous souhaitez activer n'apparaît pas dans la liste, utilisez la recherche pour la trouver ou cliquez sur Tout afficher dans la famille de produits à laquelle elle appartient.
  4. Sélectionnez l'API que vous souhaitez activer, puis cliquez sur le bouton Activer.
  5. Si vous y êtes invité, activez la facturation.
  6. Si vous y êtes invité, lisez et acceptez les conditions d'utilisation de l'API.

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 l'identifient 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. Accédez à la page Clients.
  2. Cliquez sur Créer un client.
  3. Sélectionnez le type d'application Téléviseurs et appareils à saisie limitée.
  4. Nommez votre client OAuth 2.0, puis cliquez sur Créer.

Identifier les niveaux d'accès

Les champs d'application 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 peut donc y avoir une relation inverse entre le nombre de champs d'application demandés et la probabilité d'obtenir le consentement de l'utilisateur.

Avant de commencer à implémenter l'autorisation OAuth 2.0, nous vous recommandons d'identifier les champs d'application auxquels votre application devra être autorisée à accéder.

Consultez la liste des Champs d'application autorisés 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 fonctionnalités de saisie limitées, les utilisateurs doivent avoir un accès distinct à un appareil doté de fonctionnalités de saisie plus riches pour suivre ce flux d'autorisation. Le flux comprend les étapes suivantes :

  1. Votre application envoie une requête au serveur d'autorisation de Google qui identifie les champs d'application pour lesquels votre application demandera l'autorisation d'accès.
  2. Le serveur répond en fournissant plusieurs informations utilisées lors des étapes suivantes, telles qu'un code d'appareil et un code utilisateur.
  3. Vous affichez des informations que l'utilisateur peut saisir sur un autre appareil pour autoriser votre 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 doté de fonctionnalités de saisie plus riches, lance un navigateur Web, accède à l'URL affichée à l'étape 3 et saisit un code qui s'affiche également à l'étape 3. L'utilisateur peut alors accorder (ou refuser) l'accès à votre application.
  6. La réponse suivante à votre requête d'interrogation contient les jetons dont votre application a besoin pour autoriser les 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 illustre ce processus :

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

Les sections suivantes décrivent ces étapes en détail. Compte tenu de la gamme de fonctionnalités et d'environnements d'exécution dont les appareils peuvent disposer, les exemples présentés dans ce document utilisent l'utilitaire de ligne de commande curl. Ces exemples peuvent être portés vers différents langages et environnements d'exécution.

Étape 1 : Demander les codes de l'appareil et de l'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 valeur de métadonnées device_authorization_endpoint. Incluez les paramètres de requête HTTP suivants :

Paramètres
client_id Obligatoire

ID client de votre application. Vous trouverez cette valeur sur la page Clients de la console Cloud.
scope Obligatoire

Liste de champs d'application délimités par des espaces qui identifient les ressources auxquelles votre application peut accéder au nom de l'utilisateur. Ces valeurs sont utilisées pour l'écran de consentement que Google affiche à l'utilisateur. Consultez la liste des champs d'application autorisés pour les applications ou les appareils installés.

Les champs d'application 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 une relation inverse entre le nombre de champs d'application demandés et la probabilité d'obtenir le consentement utilisateur.

Exemples

L'extrait de code suivant montre 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=email%20profile

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

curl -d "client_id=client_id&scope=email%20profile" \
     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 sera un objet JSON contenant les propriétés suivantes :

Propriétés
device_code Valeur que Google attribue de manière unique pour identifier l'appareil qui exécute l'application demandant l'autorisation. L'utilisateur autorisera cet appareil à partir d'un autre appareil doté de fonctionnalités de saisie plus riches. Par exemple, un utilisateur peut utiliser un ordinateur portable ou un téléphone mobile pour autoriser une application exécutée sur un téléviseur. Dans ce cas, l'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 de validité (en secondes) de device_code et user_code. Si, pendant ce temps, l'utilisateur ne termine pas le flux d'autorisation et que votre appareil n'interroge pas non plus pour récupérer des informations sur la décision de l'utilisateur, vous devrez peut-être redémarrer ce processus à partir de l'étape 1.
interval Durée, en secondes, pendant laquelle votre appareil doit attendre entre les requêtes d'interrogation. Par exemple, si la valeur est 5, votre appareil doit envoyer une requête d'interrogation au serveur d'autorisation de Google toutes les cinq secondes. Pour en savoir plus, consultez l'étape 3.
user_code Une valeur sensible à la casse qui identifie pour Google les champs d'application auxquels l'application demande l'accès. Votre interface utilisateur invitera l'utilisateur à saisir cette valeur sur un autre appareil doté de fonctionnalités de saisie plus riches. Google utilise ensuite cette valeur pour afficher l'ensemble de champs d'application approprié lorsqu'il invite l'utilisateur à accorder l'accès à votre application.
verification_url URL vers laquelle l'utilisateur doit accéder, sur un appareil distinct, pour saisir le user_code et accorder ou refuser l'accès à votre application. Votre interface utilisateur affichera également cette valeur.

L'extrait de code suivant présente 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 recevrez 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 pour réduire le taux de requêtes.

Étape 3 : Afficher le code utilisateur

Affichez les valeurs verification_url et user_code obtenues à l'étape 2 pour l'utilisateur. Les deux valeurs peuvent contenir n'importe quel caractère imprimable du jeu de caractères US-ASCII. Le contenu que vous affichez doit indiquer à l'utilisateur d'accéder à verification_url sur un autre appareil et de saisir le user_code.

Concevez votre interface utilisateur en gardant à l'esprit les règles suivantes :

  • user_code
    • Le user_code doit être affiché dans un champ pouvant contenir 15 caractères de taille "W". En d'autres termes, si vous pouvez afficher correctement le code WWWWWWWWWWWWWWW, votre UI est valide. Nous vous recommandons d'utiliser cette valeur de chaîne lorsque vous testez l'affichage de user_code dans votre UI.
    • Le paramètre user_code est sensible à la casse et ne doit pas être modifié (par exemple, en changeant la casse ou en insérant d'autres caractères de mise en forme).
  • verification_url
    • L'espace où vous affichez le verification_url doit être suffisamment large pour gérer une chaîne d'URL de 40 caractères.
    • Vous ne devez en aucun cas modifier l'verification_url, sauf pour éventuellement supprimer le schéma d'affichage. Si vous prévoyez de supprimer le schéma (par exemple, https://) de l'URL pour des raisons d'affichage, assurez-vous que votre application peut gérer les variantes http et https.

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

Étant donné que l'utilisateur utilisera un autre appareil pour accéder à l'verification_url et accorder (ou refuser) l'accès, l'appareil demandeur n'est pas automatiquement averti lorsque l'utilisateur répond à la demande d'accès. C'est pourquoi l'appareil demandeur doit interroger le serveur d'autorisation de Google pour déterminer quand l'utilisateur a répondu à la demande.

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 les valeurs device_code et user_code obtenues à l' étape 2 aient expiré. La valeur interval renvoyée à l'étape 2 spécifie le délai d'attente, en secondes, entre les requêtes.

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

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

Exemples

L'extrait de code suivant montre 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 à l'verification_url que vous avez affiché à l'étape 3 :

Connecter un appareil en saisissant un code

Après avoir saisi l'user_code et s'être connecté à Google (si ce n'est pas déjà fait), l'utilisateur voit un écran de consentement :

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 par l'une des réponses suivantes :

Accès autorisé

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

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

Champs
access_token Jeton que votre application envoie pour autoriser une requête d'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'à ce que l'utilisateur révoque l'accès ou que le jeton d'actualisation expire. Notez que les jetons d'actualisation sont toujours renvoyés pour les appareils.
scope Niveaux d'accès accordés par le access_token, exprimés sous la forme d'une liste de chaînes sensibles à la casse et délimitées par des espaces.
token_type Type de jeton renvoyé. Cette valeur est toujours Bearer.

L'extrait de code suivant présente 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 doit accéder à une API sur une longue période, elle peut utiliser le jeton d'actualisation pour obtenir un nouveau jeton d'accès. Si votre application nécessite 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 comporte un code d'état de réponse HTTP 403 (Forbidden). La réponse contient l'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 un code d'état de 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 un code d'état de réponse HTTP 403 (Forbidden). La réponse contient l'erreur suivante :

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

Autres erreurs

Le serveur d'autorisation renvoie également des erreurs si la requête d'interrogation ne contient pas les paramètres requis ou si la valeur d'un paramètre est incorrecte. Ces requêtes ont généralement un code d'état de réponse HTTP 400 (Bad Request) ou 401 (Unauthorized). Voici quelques exemples d'erreurs :

Erreur HTTP Status Code Description
admin_policy_enforced 400 Le compte Google ne peut pas autoriser un ou plusieurs champs d'application demandés en raison des règles de son administrateur Google Workspace. Pour en savoir plus sur la manière dont un administrateur peut restreindre l'accès aux champs d'application jusqu'à ce que l'accès soit explicitement accordé à votre ID client OAuth, consultez l'article d'aide de l'administrateur Google Workspace Contrôler quelles applications tierces et internes ont accès aux données Google Workspace.
invalid_client 401

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

Le type de client OAuth est incorrect. Assurez-vous que le type d'application pour l'ID client est défini sur Téléviseurs et appareils à saisie limitée.
invalid_grant 400 La valeur du paramètre code n'est pas valide, a déjà été revendiquée ou ne peut pas être analysée.
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 d'une organisation Google Cloud spécifique. Confirmez la configuration du type d'utilisateur pour votre application OAuth.

Appeler des API Google

Une fois que votre application a obtenu un jeton d'accès, vous pouvez l'utiliser pour appeler une API Google au nom d'un compte utilisateur donné, 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 un paramètre de requête access_token ou une valeur d'en-tête HTTP Authorization Bearer. Dans la mesure du possible, l'en-tête HTTP est préférable, car les chaînes de requête ont tendance à être visibles dans les journaux de serveur. Dans la plupart des cas, vous pouvez utiliser une bibliothèque cliente pour configurer vos appels aux API Google (par exemple, lorsque vous appelez l'API Drive Files).

Vous pouvez tester toutes les API Google et afficher leurs champs d'application sur OAuth 2.0 Playground.

Exemples de requêtes HTTP GET

Un appel au point de terminaison drive.files (l'API Drive Files) à l'aide de l'en-tête HTTP Authorization: Bearer peut se présenter comme suit. Notez que vous devez spécifier votre propre jeton d'accès :

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

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

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

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ée) :

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

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

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

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. Vous pouvez actualiser un jeton d'accès sans demander l'autorisation de l'utilisateur (y compris lorsqu'il n'est pas présent) 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 une requête HTTPS POST au serveur d'autorisation de Google (https://oauth2.googleapis.com/token) qui inclut les paramètres suivants dans le corps de la requête :

Nom Valeur
client_id ID client obtenu à partir de la console APIs.
client_secret Optional

Code secret du client obtenu à partir de la console APIs.

grant_type Comme défini dans la 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 montre 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&
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 renvoie un objet JSON contenant un nouveau jeton d'accès. L'extrait de code suivant présente un exemple de réponse :

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

Notez que le nombre de jetons d'actualisation émis est limité : une limite par combinaison client/utilisateur et une autre par utilisateur pour tous les clients. Vous devez enregistrer les jetons d'actualisation dans un espace de stockage à long terme et continuer à les utiliser tant qu'ils restent valides. Si votre application demande trop de jetons d'actualisation, elle peut atteindre ces limites, auquel cas les anciens jetons d'actualisation cesseront de fonctionner.

Révocation des jetons

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 aux paramètres du compte. Pour en savoir plus, consultez la section Supprimer l'accès d'un site ou d'une application de l'article "Sites et applications tiers ayant accès à votre compte".

Une application peut également révoquer l'accès qui lui a été accordé de manière programmatique. La révocation programmatique est importante dans les cas où un utilisateur se désabonne, supprime une application ou lorsque les ressources d'API requises par une application ont considérablement changé. En d'autres termes, une partie du processus de suppression peut inclure une requête API pour s'assurer que les autorisations précédemment 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 un jeton d'actualisation correspondant, le jeton d'actualisation sera également révoqué.

Si la révocation est traitée correctement, le code d'état HTTP de la réponse est 200. En cas d'erreur, un code d'état HTTP 400 est renvoyé, ainsi qu'un code d'erreur.

Niveaux d'accès 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

Accès basé sur l'heure

L'accès basé sur la durée permet à un utilisateur d'accorder à votre application l'accès à ses données pendant une durée limitée pour effectuer une action. L'accès limité dans le temps est disponible dans certains produits Google lors du flux de consentement. Il permet aux utilisateurs d'accorder l'accès pour une durée limitée. Par exemple, l' API Data Portability permet de transférer des données une seule fois.

Lorsqu'un utilisateur accorde à votre application un accès limité dans le temps, le jeton d'actualisation expire après la durée spécifiée. Notez que les jetons d'actualisation peuvent être invalidés plus tôt dans certaines circonstances. Pour en savoir plus, consultez ces cas. Le champ refresh_token_expires_in renvoyé dans la réponse de l'échange de code d'autorisation représente le temps restant avant l'expiration du jeton d'actualisation dans de tels cas.

Implémenter la protection multicompte

Pour protéger les comptes de vos utilisateurs, vous devez également mettre en œuvre la protection multicompte en utilisant le service de protection multicompte de Google. Ce service vous permet de vous abonner aux notifications d'événements liés à la sécurité qui fournissent à votre application des informations sur les modifications majeures apportées au compte utilisateur. Vous pouvez ensuite utiliser ces informations pour prendre des mesures en fonction de la manière dont 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

Pour en savoir plus sur l'implémentation de la protection multicompte et obtenir la liste complète des événements disponibles, consultez la page Protéger les comptes utilisateur avec la protection multicompte .