1001Ferramentas
🔑Validadores

OAuth Scope Checker

Verifica se um scope solicitado está nos scopes concedidos (separados por espaço).

Resultado

Por que o scope quase certo falha

O endpoint devolve 403 com insufficient_scope e você fica comparando duas listas de strings no olho: a que veio no token e a que a documentação exige. É fácil ler read:users e read:user como a mesma coisa, ou supor que profile já inclui email. Com sete ou oito scopes concedidos numa linha só, conferir isso na leitura é convite ao erro.

A regra do OAuth 2.0 é seca: scope é uma lista separada por espaços e cada item é comparado por igualdade literal. Não há hierarquia embutida, não há curinga, não há herança. read:users não concede read:users:email, e admin não abre nada sozinho. Se o seu servidor de autorização entende que um scope engloba outro, isso é convenção dele, não da especificação. Maiúsculas e minúsculas também contam.

Na prática, use a lista exata que voltou no campo scope da resposta do token, e não a que você pediu na autorização, porque o usuário pode negar parte do consentimento e as duas divergirem. O que faltar exige um novo consentimento. Se os scopes batem e a API continua recusando, olhe audience, tenant e expiração antes de mexer neles de novo. A comparação acontece no navegador, sem enviar nada.

Perguntas frequentes

Scopes do OAuth diferenciam maiúsculas de minúsculas?
Sim. A comparação é literal, caractere por caractere, então read:Users e read:users são scopes diferentes para o servidor de autorização.
Por que o token voltou com menos scopes do que eu pedi?
O servidor de autorização pode conceder um subconjunto do que foi solicitado, seja por política, seja porque o usuário recusou parte do consentimento. O campo scope da resposta é a versão que vale.
Existe curinga do tipo read:* no OAuth?
Não na especificação. Alguns provedores implementam padrões próprios de agrupamento, mas isso é extensão deles e precisa estar na documentação do provedor.

Ferramentas Relacionadas