Este documento explica como implementar a autorização OAuth 2.0 para acessar a API YouTube Data usando aplicativos executados em dispositivos como TVs, consoles de jogos e impressoras. Mais especificamente, esse fluxo foi projetado para dispositivos que não têm acesso a um navegador ou têm recursos de entrada limitados.
O OAuth 2.0 permite que os usuários compartilhem dados específicos com um aplicativo, mantendo a privacidade de nomes de usuário, senhas e outras informações. Por exemplo, um aplicativo de TV pode usar o OAuth 2.0 para receber permissão para selecionar um arquivo armazenado no Google Drive.
Como os aplicativos que usam esse fluxo são distribuídos para dispositivos individuais, presume-se que eles não podem manter segredos. Eles podem acessar as APIs do Google enquanto o usuário está presente no app ou quando ele está sendo executado em segundo plano.
Alternativas
Se você estiver escrevendo um app para uma plataforma como Android, iOS, macOS, Linux ou Windows (incluindo a Plataforma Universal do Windows), que tenha acesso ao navegador e recursos de entrada completos, use o fluxo do OAuth 2.0 para aplicativos móveis e de computador. Use esse fluxo mesmo que o app seja uma ferramenta de linha de comando sem uma interface gráfica.
Se você apenas quiser fazer login dos usuários com as Contas do Google deles e usar o token de ID JWT para receber informações básicas do perfil do usuário, consulte Fazer login em TVs e dispositivos de entrada limitada.
Pré-requisitos
Ativar as APIs do projeto
Qualquer aplicativo que chame as APIs do Google precisa ativar essas APIs no API Console.
Para ativar uma API para um projeto, faça o seguinte:
- Open the API Library no Google API Console.
- If prompted, select a project, or create a new one.
- Utilize a página Biblioteca para encontrar e ativar a API de Dados do YouTube. Encontre outras APIs que seu aplicativo vai usar e ative-as também.
Criar credenciais de autorização
Qualquer aplicativo que use o OAuth 2.0 para acessar as APIs do Google precisa ter credenciais de autorização que identifiquem o aplicativo para o servidor OAuth 2.0 do Google. As etapas a seguir explicam como criar credenciais para seu projeto. Seus aplicativos podem usar as credenciais para acessar as APIs que você ativou para esse projeto.
- Go to the Clients page.
- Clique em Criar cliente.
- Selecione o tipo de aplicativo TVs e dispositivos de entrada limitados.
- Dê um nome ao cliente OAuth 2.0 e clique em Criar.
Identificar escopos de acesso
Os escopos permitem que seu aplicativo solicite acesso apenas aos recursos necessários, além de permitir que os usuários controlem o nível de acesso que concedem ao seu aplicativo. Assim, pode haver uma relação inversa entre o número de escopos solicitados e a probabilidade de obter o consentimento do usuário.
Antes de começar a implementar a autorização do OAuth 2.0, recomendamos que você identifique os escopos que seu app precisará de permissão para acessar.
A API YouTube Data v3 usa os seguintes escopos:
| Escopo | Descrição |
|---|---|
https://www. |
Gerenciar sua conta do YouTube |
https://www. |
Ver uma lista dos membros ativos atuais do canal, do nível deles e de quando se tornaram membros |
https://www. |
Ver, editar e excluir permanentemente vídeos, classificações, comentários e legendas do YouTube |
https://www. |
Visualize sua conta do YouTube |
https://www. |
Gerenciar seus vídeos do YouTube |
https://www. |
Ver e gerenciar seus ativos e conteúdos associados no YouTube |
https://www. |
Visualiza as informações particulares do seu canal que são relevantes para o processo de auditoria com um parceiro do YouTube |
Consulte a lista Escopos permitidos para apps ou dispositivos instalados.
Como conseguir tokens de acesso do OAuth 2.0
Mesmo que o aplicativo seja executado em um dispositivo com recursos de entrada limitados, os usuários precisam ter acesso separado a um dispositivo com recursos de entrada mais avançados para concluir esse fluxo de autorização. O fluxo tem as seguintes etapas:
- Seu aplicativo envia uma solicitação ao servidor de autorização do Google que identifica os escopos para os quais seu aplicativo vai pedir permissão de acesso.
- O servidor responde com várias informações usadas nas etapas subsequentes, como um código do dispositivo e um código do usuário.
- Você mostra informações que o usuário pode inserir em um dispositivo separado para autorizar seu app.
- O aplicativo começa a consultar o servidor de autorização do Google para determinar se o usuário autorizou o app.
- O usuário muda para um dispositivo com recursos de entrada mais avançados, abre um navegador da Web, navega até o URL mostrado na etapa 3 e insere um código também exibido na etapa 3. O usuário pode conceder (ou negar) o acesso ao seu aplicativo.
- A próxima resposta à sua solicitação de sondagem contém os tokens que seu app precisa para autorizar solicitações em nome do usuário. Se o usuário recusar o acesso ao seu aplicativo, a resposta não vai conter tokens.
A imagem abaixo ilustra esse processo:
As seções a seguir explicam essas etapas em detalhes. Devido à variedade de recursos e ambientes de execução que os dispositivos podem ter, os exemplos mostrados neste documento usam o utilitário de linha de comando curl. Esses exemplos precisam ser fáceis de migrar para várias linguagens e tempos de execução.
Etapa 1: pedir códigos de dispositivo e de usuário
Nesta etapa, seu dispositivo envia uma solicitação HTTP POST para o servidor de autorização do Google, em
https://oauth2.googleapis.com/device/code, que identifica seu aplicativo
e os escopos de acesso que ele quer acessar em nome do usuário.
Recupere esse URL do
documento de descoberta usando o valor de metadados
device_authorization_endpoint. Inclua os seguintes parâmetros de solicitação HTTP:
| Parâmetros | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
client_id |
Obrigatório
O ID do cliente do seu aplicativo. Esse valor está no Cloud Console Clients page. |
||||||||||||||||
scope |
Obrigatório
Uma lista delimitada por espaços de escopos que identificam os recursos que seu aplicativo pode acessar em nome do usuário. Esses valores informam à tela de consentimento que o Google mostra ao usuário. Consulte a lista Escopos permitidos para aplicativos ou dispositivos instalados. Os escopos permitem que seu aplicativo solicite acesso apenas aos recursos de que precisa, ao mesmo tempo que permitem aos usuários controlar o nível de acesso que concedem ao seu aplicativo. Assim, há uma relação inversa entre o número de escopos solicitados e a probabilidade de obter o consentimento do usuário. A API YouTube Data v3 usa os seguintes escopos:
O documento Escopos da API OAuth 2.0 oferece uma lista completa de escopos que você pode usar para acessar as APIs do Google. |
||||||||||||||||
Exemplos
O snippet a seguir mostra um exemplo de solicitação:
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
Este exemplo mostra um comando curl para enviar a mesma solicitação:
curl -d "client_id=client_id&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl" \
https://oauth2.googleapis.com/device/code
Etapa 2: Lidar com a resposta do servidor de autorização
O servidor de autorização retornará uma das seguintes respostas:
Resposta de sucesso
Se a solicitação for válida, sua resposta será um objeto JSON contendo as seguintes propriedades:
| Propriedades | |
|---|---|
device_code |
Um valor que o Google atribui exclusivamente para identificar o dispositivo que executa o aplicativo que solicita autorização. O usuário autorizará esse dispositivo a partir de outro dispositivo com recursos de entrada mais avançados. Por exemplo, um usuário pode usar um laptop ou celular para autorizar um aplicativo em execução em uma TV. Neste caso, o device_code identifica a TV.
Este código permite que o dispositivo que executa o aplicativo determine com segurança se o usuário concedeu ou negou o acesso. |
expires_in |
O período de tempo, em segundos, em que device_code e user_code são válidos. Se, nesse período, o usuário não concluir o fluxo de autorização e seu dispositivo não consultar para obter informações sobre a decisão do usuário, talvez seja necessário reiniciar esse processo desde a etapa 1. |
interval |
O período de tempo, em segundos, que seu dispositivo deve aguardar entre as solicitações de sondagem. Por exemplo, se o valor for 5, seu dispositivo deverá enviar uma solicitação de verificação ao servidor de autorização do Google a cada cinco segundos. Consulte passo 3 para obter mais detalhes. |
user_code |
Um valor que diferencia maiúsculas de minúsculas e identifica para o Google os escopos aos quais o aplicativo está solicitando acesso. Sua interface de usuário instruirá o usuário a inserir esse valor em um dispositivo separado com recursos de entrada mais avançados. O Google usa esse valor para exibir o conjunto correto de escopos ao solicitar que o usuário conceda acesso ao seu aplicativo. |
verification_url |
Um URL que o usuário deve navegar, em um dispositivo separado, para inserir o user_code e conceder ou negar acesso ao seu aplicativo. Sua interface de usuário também exibirá esse valor. |
O trecho a seguir mostra um exemplo de resposta:
{ "device_code": "4/4-GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8", "user_code": "GQVQ-JKEC", "verification_url": "https://www.google.com/device", "expires_in": 1800, "interval": 5 }
A cota excedeu a resposta.
Se o número de solicitações de código do seu dispositivo exceder a cota associada ao seu ID de cliente, você receberá uma resposta 403 contendo o seguinte erro:
{ "error_code": "rate_limit_exceeded" }
Nesse caso, utilize uma estratégia de recuo (backoff) para reduzir a taxa de solicitações.
Etapa 3: Exibir o código do usuário
Mostre ao usuário os valores verification_url e user_code obtidos na etapa 2. Ambos os valores podem conter qualquer caractere imprimível do conjunto de caracteres US-ASCII. O conteúdo que você exibe para o usuário deve instruí-lo a navegar até o verification_url em um dispositivo separado e inserir o user_code.
Projete sua interface de usuário (IU) levando em consideração as seguintes regras:
user_code- O
user_codedeve ser exibido em um campo que possa lidar com 15 caracteres de tamanho 'W'. Em outras palavras, se você conseguir exibir o códigoWWWWWWWWWWWWWWWcorretamente, sua interface de usuário é válida e recomendamos usar esse valor de string ao testar a forma como ouser_codeé exibido em sua interface de usuário. - O caractere
user_codediferencia maiúsculas de minúsculas e não deve ser modificado de forma alguma, como alterando maiúsculas e minúsculas ou inserindo outros caracteres de formatação.
- O
verification_url- O espaço onde você exibe o
verification_urldeve ser largo o suficiente para acomodar uma string de URL de 40 caracteres. - Você não deve modificar o
verification_urlde forma alguma, exceto para remover opcionalmente o esquema para exibição. Se você planeja remover o esquema (por exemplo,https://) da URL por motivos de exibição, certifique-se de que seu aplicativo possa lidar com as varianteshttpehttps.
- O espaço onde você exibe o
Etapa 4: Consulte o servidor de autorização do Google
Como o usuário usará um dispositivo separado para navegar até o verification_url e conceder (ou negar) o acesso, o dispositivo solicitante não é notificado automaticamente quando o usuário responde à solicitação de acesso. Por esse motivo, o dispositivo solicitante precisa consultar o servidor de autorização do Google para determinar quando o usuário respondeu à solicitação.
O dispositivo solicitante deve continuar enviando solicitações de sondagem até receber uma resposta indicando que o usuário respondeu à solicitação de acesso ou até que odevice_code euser_code obtido em
passo 2 expiraram. O valor interval retornado na etapa 2 especifica a quantidade de tempo, em segundos, a ser aguardada entre as solicitações.
A URL do ponto de extremidade a ser consultado é https://oauth2.googleapis.com/token. A solicitação de sondagem contém os seguintes parâmetros:
| Parâmetros | |
|---|---|
client_id |
O ID do cliente do seu aplicativo. Você pode encontrar esse valor em Cloud Console Clients page. |
client_secret |
O segredo do cliente para o fornecido client_id. Você pode encontrar esse valor em Cloud Console
Clients page. |
device_code |
Odevice_code retornado pelo servidor de autorização empasso 2. |
grant_type |
Defina esse valor como urn:ietf:params:oauth:grant-type:device_code. |
Exemplos
O snippet a seguir mostra um exemplo de solicitação:
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
Este exemplo mostra um comando curl para enviar a mesma solicitação:
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/tokenEtapa 5: O usuário responde à solicitação de acesso.
A imagem a seguir mostra uma página semelhante à que os usuários veem quando navegam até o verification_url que você exibiu na etapa 3:
Após inserir o user_code e, caso ainda não esteja conectado, fazer login no Google, o usuário verá uma tela de consentimento como a mostrada abaixo:
Etapa 6: Lidar com as respostas às solicitações de votação
O servidor de autorização do Google responde a cada solicitação de sondagem com uma das seguintes respostas:
Acesso concedido
Se o usuário concedeu acesso ao dispositivo (clicando em Allow na tela de consentimento), a resposta contém um token de acesso e um token de atualização. Os tokens permitem que seu dispositivoAcessar APIs do Google em nome do usuário. (A propriedade scope na resposta determina quais APIs o dispositivo pode acessar.)
Neste caso, a resposta da API contém os seguintes campos:
| Campos | |
|---|---|
access_token |
O token que seu aplicativo envia para autorizar uma solicitação à API do Google. |
expires_in |
O tempo restante de vida útil do token de acesso em segundos. |
refresh_token |
Um token que pode ser usado para receber um novo token de acesso. Os tokens de atualização são válidos até que o usuário revogue o acesso ou o token de atualização expire. Note que os tokens de atualização são sempre retornados para os dispositivos. |
refresh_token_expires_in |
A vida útil restante do token de atualização em segundos. Esse valor só é definido quando o usuário concede acesso com base em tempo. |
scope |
Os escopos de acesso concedidos pelo access_token expressos como uma lista de strings delimitadas por espaços, diferenciando maiúsculas de minúsculas. |
token_type |
O tipo de token retornado. No momento, o valor desse campo é sempre definido como
Bearer. |
Confira um exemplo de resposta:
{ "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" }
Os tokens de acesso têm um tempo de vida limitado. Se o aplicativo precisar de acesso a uma API por um longo período, ele poderá usar o token de atualização para conseguir um novo token de acesso. Se o aplicativo precisar desse tipo de acesso, ele deverá armazenar o token de atualização para uso posterior.
Acesso negado
Se o usuário se recusar a conceder acesso ao dispositivo, a resposta do servidor terá um
código de status de resposta HTTP 403 (Forbidden). A resposta contém o
seguinte erro:
{ "error": "access_denied", "error_description": "Forbidden" }
Autorização pendente
Se o usuário ainda não tiver concluído o fluxo de autorização, o servidor vai retornar um
código de status de resposta HTTP 428 (Precondition Required). A resposta
contém o seguinte erro:
{ "error": "authorization_pending", "error_description": "Precondition Required" }
Pesquisar com muita frequência
Se o dispositivo enviar solicitações de polling com muita frequência, o servidor vai retornar um código de status de resposta HTTP 403 (Forbidden). A resposta contém o seguinte erro:
{ "error": "slow_down", "error_description": "Forbidden" }
Outros erros
O servidor de autorização também retorna erros se a solicitação de pesquisa estiver sem parâmetros obrigatórios ou tiver um valor de parâmetro incorreto. Essas solicitações geralmente têm um código de status de resposta HTTP 400 (Bad Request) ou 401 (Unauthorized). Esses erros incluem:
| Erro | Código de status HTTP | Descrição |
|---|---|---|
admin_policy_enforced |
400 |
A Conta do Google não pode autorizar um ou mais escopos solicitados devido às políticas do administrador do Google Workspace. Consulte o artigo da Ajuda do administrador do Google Workspace Controlar quais apps internos e de terceiros acessam os dados do Google Workspace para mais informações sobre como um administrador pode restringir o acesso aos escopos até que ele seja concedido explicitamente ao ID do cliente OAuth. |
invalid_client |
401 |
O cliente OAuth não foi encontrado. Por exemplo, esse erro ocorre se o valor do parâmetro O tipo de cliente OAuth está incorreto. Verifique se o tipo de aplicativo para o ID do cliente está definido como TVs e dispositivos de entrada limitados. |
invalid_grant |
400 |
O valor do parâmetro code é inválido, já foi reivindicado ou não pode ser
analisado. |
unsupported_grant_type |
400 |
O valor do parâmetro grant_type é inválido. |
org_internal |
403 |
O ID do cliente OAuth na solicitação faz parte de um projeto que limita o acesso a contas do Google em uma organização do Google Cloud específica. Confirme a configuração do tipo de usuário para seu aplicativo OAuth. |
Como chamar APIs do Google
Depois que o aplicativo receber um token de acesso, ele poderá ser usado para fazer chamadas a uma API do Google
em nome de uma determinada
conta de usuário, se os escopos de acesso exigidos pela API tiverem sido concedidos. Para fazer isso, inclua
o token de acesso em uma solicitação à API incluindo um parâmetro de consulta access_token ou um valor de cabeçalho HTTP Authorization Bearer. Quando possível, o cabeçalho HTTP é preferível, porque as strings de consulta tendem a ficar visíveis nos registros do servidor. Na maioria dos casos, é possível usar uma biblioteca de cliente para configurar suas chamadas às APIs do Google, por exemplo, ao chamar a API YouTube Live Streaming.
A API YouTube Live Streaming não é compatível com o fluxo de conta de serviço. Como não há como vincular uma conta de serviço a uma conta do YouTube, as tentativas de autorizar solicitações com esse fluxo vão gerar um erro NoLinkedYouTubeAccount.
Você pode testar todas as APIs do Google e conferir os escopos delas no OAuth 2.0 Playground.
Exemplos de HTTP GET
Uma chamada para o
endpoint
liveBroadcasts.list (API YouTube Live Streaming) usando o cabeçalho HTTP Authorization: Bearer
pode ser assim: É necessário especificar seu próprio token de acesso:
GET /youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
Esta é uma chamada para a mesma API do usuário autenticado usando o parâmetro de string de consulta access_token:
GET https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true
Exemplos de curl
É possível testar esses comandos com o aplicativo de linha de comando curl. Confira um
exemplo que usa a opção de cabeçalho HTTP (preferencial):
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true
Ou, como alternativa, a opção de parâmetro de string de consulta:
curl https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true
Atualização do token de acesso
Os tokens de acesso expiram periodicamente e se tornam credenciais inválidas para uma solicitação de API relacionada. É possível atualizar um token de acesso sem solicitar a permissão do usuário (inclusive quando ele não está presente) se você solicitou acesso off-line aos escopos associados ao token.
Para atualizar um token de acesso, seu aplicativo envia uma solicitação HTTPS POST
ao servidor de autorização do Google (https://oauth2.googleapis.com/token) que
inclui os seguintes parâmetros:
| Campos | |
|---|---|
client_id |
O ID do cliente obtido do API Console. |
client_secret |
Opcional
O segredo do cliente obtido de API Console. |
grant_type |
Comodefinido na especificação OAuth 2.0 , o valor deste campo deve ser definido comorefresh_token. |
refresh_token |
O token de atualização retornado da troca de código de autorização. |
O snippet a seguir mostra um exemplo de solicitação:
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
Enquanto o usuário não revogar o acesso concedido ao aplicativo, o servidor de token vai retornar um objeto JSON que contém um novo token de acesso. O snippet a seguir mostra um exemplo de resposta:
{ "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" }
Há limites para o número de tokens de atualização que serão emitidos: um limite por combinação de cliente/usuário e outro por usuário em todos os clientes. Salve os tokens de atualização em armazenamento de longo prazo e continue usando-os enquanto forem válidos. Se o aplicativo solicitar muitos tokens de atualização, ele poderá atingir esses limites, e os tokens de atualização mais antigos vão parar de funcionar.
Revogação de token
Em alguns casos, um usuário pode querer revogar o acesso concedido a um aplicativo. Um usuário pode revogar o acesso acessando Configurações da conta. Consulte a seção Remover o acesso de sites ou apps do documento de suporte Sites e apps de terceiros com acesso à sua conta para mais informações.
Também é possível que um aplicativo revogue programaticamente o acesso concedido a ele. A revogação programática é importante quando um usuário cancela a inscrição, remove um aplicativo ou os recursos da API exigidos por um app mudaram significativamente. Em outras palavras, parte do processo de remoção pode incluir uma solicitação de API para garantir que as permissões concedidas anteriormente ao aplicativo sejam removidas.
Para revogar um token de forma programática, seu aplicativo faz uma solicitação para
https://oauth2.googleapis.com/revoke e inclui o token como um parâmetro:
curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
https://oauth2.googleapis.com/revoke?token={token}O token pode ser de acesso ou de atualização. Se o token for de acesso e tiver um token de atualização correspondente, ele também será revogado.
Se a revogação for processada com sucesso, o código de status HTTP da resposta será
200. Em condições de erro, um código de status HTTP 400 é retornado junto
com um código de erro.
Escopos permitidos
O fluxo OAuth 2.0 para dispositivos é compatível apenas com os seguintes escopos:
OpenID Connect, Login do Google
emailopenidprofile
API do Drive
https://www.googleapis.com/auth/drive.appdatahttps://www.googleapis.com/auth/drive.file
API do YouTube
https://www.googleapis.com/auth/youtubehttps://www.googleapis.com/auth/youtube.readonly
Acesso baseado em tempo
O acesso baseado em tempo permite que um usuário conceda ao seu aplicativo acesso aos seus dados por um período limitado para concluir uma ação. O acesso baseado em tempo está disponível em alguns produtos do Google durante o processo de consentimento, aos usuários a opção de conceder acesso por um período limitado. Um exemplo é a API Data Portability, que permite uma transferência única de dados.
Quando um usuário concede acesso por tempo ao seu aplicativo, o token de atualização expira após a
duração especificada. Os tokens de atualização podem ser invalidados antes em circunstâncias específicas. Consulte estes casos para mais detalhes. O campo refresh_token_expires_in retornado na resposta da
troca de código de
autorização representa o tempo restante até que o token de atualização expire nesses casos.
Implementar a Proteção entre contas
Outra etapa para proteger as contas dos usuários é implementar a proteção entre contas usando o serviço de proteção entre contas do Google. Com esse serviço, você pode assinar notificações de eventos de segurança que fornecem informações ao seu aplicativo sobre mudanças importantes na conta do usuário. Depois, use as informações para tomar medidas dependendo de como você decide responder aos eventos.
Alguns exemplos dos tipos de eventos enviados ao seu app pelo Serviço de proteção entre contas do 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
Consulte a página Proteger contas de usuário com a Proteção entre contas para mais informações sobre como implementar a Proteção entre contas e a lista completa de eventos disponíveis.