Compreendendo o OAuth 2.0: Um Guia Abrangente

Introdução

O OAuth 2.0 é frequentemente confundido com um protocolo de autenticação, mas é fundamentalmente um framework de autorização que permite a aplicações de terceiros obter acesso limitado aos recursos de um usuário em um serviço HTTP. Esse framework define como aplicações solicitam e recebem permissão para acessar dados do usuário sem expor suas credenciais, aumentando a segurança e o controle do usuário sobre seus ativos digitais [1].

Se você já clicou em “Entrar com o Google” ou “Continuar com o GitHub” em algum site, já usou o OAuth 2.0 — mesmo que não tenha percebido. Este post explica exatamente o que acontece nos bastidores, desde o primeiro clique até a resposta da API, de uma forma acessível tanto para quem está encontrando o OAuth pela primeira vez quanto para quem quer consolidar lacunas no seu entendimento.

O Problema que o OAuth 2.0 Resolve

Para entender por que o OAuth 2.0 existe, é útil entender o problema que ele foi criado para substituir.

Imagine que você usa um aplicativo de despesas de viagem que precisa ler sua caixa de entrada do Gmail para importar automaticamente confirmações de reservas de voos. Antes do OAuth, a única forma de fazer isso funcionar era fornecer ao aplicativo o seu usuário e senha do Gmail diretamente. O app então faria login no Gmail em seu nome e extrairia seus e-mails.

Essa abordagem tem problemas sérios. O aplicativo tem acesso total à sua caixa de entrada inteira, não apenas aos e-mails de reserva que ele precisa. Você não tem como revogar o acesso sem mudar sua senha. Você não tem visibilidade do que ele está realmente fazendo com a sua conta. E se o aplicativo for comprometido, suas credenciais ficam expostas.

O OAuth 2.0 resolve isso introduzindo o conceito de autorização delegada. Em vez de entregar sua senha, você diz diretamente ao Google: “Quero permitir que este aplicativo de viagens leia meus e-mails.” O Google então emite um token de escopo limitado para o app. O aplicativo nunca vê sua senha. Você pode revogar o acesso a qualquer momento nas configurações da sua conta Google. E o token pode ser restrito apenas às permissões específicas que o app realmente precisa — neste caso, acesso somente leitura a um subconjunto das suas mensagens.

Esse é o insight central do OAuth 2.0: separar o ato de provar quem você é do ato de conceder acesso aos seus recursos.

A Distinção Central: Autorização vs. Autenticação

Antes de nos aprofundarmos, é fundamental entender a diferença entre dois termos frequentemente usados de forma intercambiável, mas que têm significados muito distintos:

Autenticação é o processo de verificar identidade. Responde à pergunta: “Quem é você?” Quando você digita sua senha em um formulário de login, você está se autenticando. Você está provando ao sistema que é quem diz ser.

Autorização é o processo de verificar permissões. Responde à pergunta: “O que você tem permissão para fazer?” Quando um sistema verifica se a sua conta tem permissão para deletar um arquivo, visualizar um painel ou chamar um endpoint de API, ele está realizando autorização.

O OAuth 2.0 é puramente um framework de autorização. Ele define como um sistema pode conceder a outro sistema permissão para agir em nome de um usuário — mas não informa, por si só, à aplicação cliente quem é o usuário de fato. Essa é uma fonte comum de confusão.

Por exemplo, após um fluxo OAuth bem-sucedido, a aplicação Cliente recebe um access token. Esse token prova que a autorização foi concedida ao cliente. Mas o token não deve ser tratado como prova de identidade — mesmo que alguns provedores incluam claims de identidade como sub ou email dentro dos access tokens, o cliente não deve depender deles para fins de autenticação. Se a aplicação Cliente precisar conhecer a identidade do usuário — por exemplo, para exibir “Bem-vindo, João” — ela precisa de algo mais adequado para esse propósito. Esse algo mais é o OpenID Connect (OIDC), uma camada de identidade fina construída sobre o OAuth 2.0 que adiciona um segundo token chamado ID token. O ID token é um JWT assinado que contém claims de identidade sobre o usuário, como nome, endereço de e-mail e um identificador de sujeito único [3].

Em resumo: use o OAuth 2.0 quando precisar conceder acesso. Adicione o OIDC por cima quando também precisar saber quem é o usuário.

Uma Analogia do Mundo Real: O Cartão-Chave do Hotel

Uma analogia útil para o OAuth 2.0 é o check-in em um hotel.

Quando você chega ao hotel, vai à recepção (o Authorization Server) e prova quem é com seu passaporte (suas credenciais). A recepção não lhe dá uma chave mestra para o prédio inteiro — ela lhe entrega um cartão-chave (o access token) programado para abrir apenas o seu quarto, a academia e a piscina. O seu quarto é o 412, e o cartão só funciona no quarto 412 (o scope).

Quando você caminha até a porta do seu quarto (o Resource Server), passa o cartão. O leitor da porta valida o cartão e abre. Ele não precisa ligar para a recepção para verificar toda vez — ele confia no próprio cartão, porque a recepção o emitiu. Isso é análogo à verificação de assinatura JWT: o servidor de recursos valida o token localmente sem fazer uma chamada de ida e volta.

Se você perder o cartão ou fizer o checkout, a recepção pode desativá-lo (token revocation). Quando o cartão expira, você volta à recepção para um novo sem precisar mostrar o passaporte novamente (o refresh token).

O hóspede no quarto 413 (outro Resource Owner) tem seu próprio cartão. O cartão dele não abre o seu quarto. Os scopes garantem que cada aplicação acesse apenas o que foi explicitamente autorizado a acessar.

Os Papéis Principais no Framework OAuth 2.0

O framework OAuth 2.0 define quatro papéis distintos que interagem para facilitar o acesso delegado de forma segura:

1. Resource Owner

O Resource Owner é tipicamente o usuário final que possui os recursos protegidos e tem capacidade de conceder acesso a eles — por exemplo, seus arquivos no Google Drive, seus repositórios no GitHub ou suas postagens nas redes sociais. O consentimento explícito do Resource Owner é a base do OAuth 2.0: nada acontece sem que o usuário concorde. Vale notar que, em alguns cenários máquina a máquina (o grant Client Credentials), o Resource Owner e o Cliente podem ser o mesmo sistema, sem nenhum usuário humano envolvido [1].

2. Client

O Client é a aplicação que deseja acessar os recursos protegidos do Resource Owner. Pode ser uma aplicação web rodando em um servidor, um app móvel no telefone do usuário, uma single-page application rodando no navegador ou um serviço em background. Antes que um fluxo OAuth possa começar, o Client deve ser registrado no Authorization Server — esse processo de registro atribui ao Client um Client ID único e, para clientes confidenciais que conseguem guardar segredos, um Client Secret. Essas credenciais identificam a aplicação, não o usuário [1].

3. Authorization Server

O Authorization Server é responsável por obter a autenticação do Resource Owner e, após autenticação e consentimento bem-sucedidos, emitir access tokens para o Client. Note que o Authorization Server nem sempre autentica o usuário diretamente — ele pode delegar essa responsabilidade a um provedor de identidade externo. Exemplos reais comuns incluem o Keycloak federando com LDAP, o Auth0 delegando ao login do Google ou o Okta integrando com o Active Directory. O Authorization Server atua como guardião, garantindo que apenas aplicações Cliente registradas e autorizadas recebam tokens. Ele também gerencia o ciclo de vida completo dos tokens: emissão, expiração, atualização e revogação [1].

4. Resource Server

O Resource Server hospeda os recursos protegidos que o Client deseja acessar. Geralmente é uma API. Quando o Client chama a API com um access token, o Resource Server é responsável por validar esse token antes de responder. Em muitas implementações, essa validação é feita localmente verificando uma assinatura JWT, tornando-a rápida e independente do Authorization Server. Em outras configurações — especialmente quando tokens opacos são usados — o Resource Server chama o endpoint de token introspection do Authorization Server para verificar se o token ainda é válido [1].

Os Grant Types do OAuth 2.0

O OAuth 2.0 define vários “grant types” — cada um é um fluxo diferente projetado para um tipo diferente de aplicação ou caso de uso. Escolher o correto é importante tanto para segurança quanto para praticidade.

Authorization Code Grant

Este é o fluxo mais comum e mais seguro, projetado para aplicações que rodam em um servidor ou que conseguem usar redirecionamentos de navegador de forma confiável. O fluxo completo de nove etapas é descrito na próxima seção. A propriedade de segurança principal é a separação entre uma etapa de front-channel (o redirecionamento do navegador que entrega o authorization code) e uma etapa de back-channel (a requisição servidor a servidor que troca o código por um token). Essa separação significa que o próprio token nunca passa pelo navegador.

Authorization Code Grant + PKCE

O PKCE (Proof Key for Code Exchange, pronunciado “pixie”) é uma extensão do Authorization Code Grant que adiciona um desafio criptográfico para prevenir ataques de interceptação do authorization code. Foi originalmente projetado para aplicações móveis e single-page applications que não conseguem armazenar com segurança um Client Secret, mas as diretrizes modernas de segurança — especificamente o OAuth 2.1 — recomendam o uso de PKCE para todos os clientes, incluindo aplicações server-side confidenciais. Ao usar PKCE, o Client gera um code_verifier aleatório, aplica um hash para produzir um code_challenge e envia o challenge na requisição de autorização inicial. Mais tarde, ao trocar o código por um token, o Client envia o code_verifier original. O Authorization Server verifica que o hash corresponde, confirmando que a entidade que está resgatando o código é a mesma que iniciou o fluxo.

Client Credentials Grant

Este fluxo é para comunicação máquina a máquina onde não há nenhum usuário humano envolvido. Um serviço backend que precisa chamar outra API em seu próprio nome — não em nome de um usuário — usa esse grant. O Client envia seu Client ID e Client Secret diretamente ao endpoint de token do Authorization Server e recebe um access token. Não há redirecionamento, navegador ou tela de consentimento do usuário. Casos de uso comuns incluem microsserviços chamando APIs internas, jobs agendados e integrações servidor a servidor.

Implicit Grant e Resource Owner Password Credentials Grant (Obsoletos)

Esses dois grant types existem na especificação original do OAuth 2.0, mas são considerados obsoletos no uso moderno e não devem ser usados em novas aplicações. O Implicit Grant foi projetado para apps baseados em navegador, mas expunha tokens no fragmento da URL, criando riscos de segurança. O Resource Owner Password Credentials (ROPC) Grant exigia que o usuário fornecesse suas credenciais diretamente à aplicação Cliente — exatamente o anti-padrão que o OAuth foi criado para eliminar. Ambos foram substituídos pelo Authorization Code + PKCE.

O Fluxo de Comunicação do OAuth 2.0 (Authorization Code Grant)

O fluxo Authorization Code Grant é um dos fluxos OAuth 2.0 mais comuns e seguros, particularmente adequado para clientes confidenciais (aplicações capazes de armazenar com segurança um client secret). Hoje, esse fluxo é tipicamente combinado com PKCE para proteção adicional, mesmo para clientes confidenciais.

  sequenceDiagram
    actor RO as Resource Owner (Usuário)
    participant UA as User-Agent (Navegador)
    participant C as Client (Aplicação)
    participant AS as Authorization Server
    participant RS as Resource Server (API)

    RO->>C: 1. Inicia requisição de autorização(ex.: clica em "Conectar com o Google")
    C->>UA: 2. Redireciona para o Auth Server(Client ID, Scopes, Redirect URI, response_type=code)
    UA->>AS: 2. Segue o redirecionamento para o Auth Server
    AS->>UA: 3. Solicita login e consentimento
    UA->>RO: 3. Exibe tela de login/consentimento
    RO->>UA: 4. Autentica e concede consentimento
    UA->>AS: 4. Envia credenciais e consentimento
    AS->>UA: 5. Redireciona de volta com o Authorization Code(via redirect_uri)
    UA->>C: 5. Entrega o Authorization Code(front-channel, via redirecionamento do navegador)
    C->>AS: 6. Troca Auth Code + code_verifier(e Client Secret se cliente confidencial)
    AS->>C: 7. Emite Access Token (e Refresh Token)
    C->>RS: 8. Solicita recurso com Access Token(Authorization: Bearer )
    RS->>C: 9. Valida o token e retorna o recurso protegido

O fluxo envolve as seguintes etapas:

O Client Inicia a Requisição de Autorização: O Resource Owner (usuário) clica em algo na aplicação Cliente que requer acesso a um recurso protegido — por exemplo, “Conectar com o Google.” O Client ainda não recebeu nenhuma credencial; ele simplesmente prepara uma requisição de autorização.
O Client Redireciona para o Authorization Server: O Client redireciona o navegador do usuário (User-Agent) para o endpoint de autorização do Authorization Server, passando o Client ID, os scopes solicitados (permissões), um redirect_uri e response_type=code.
O Authorization Server Solicita Login e Consentimento: O Authorization Server apresenta ao Resource Owner uma tela de login (caso não esteja autenticado) e uma tela de consentimento detalhando exatamente quais permissões o Client está solicitando.
O Resource Owner se Autentica e Concede Consentimento: O Resource Owner envia suas credenciais e aprova a tela de consentimento diretamente com o Authorization Server — crucialmente, o Client nunca lida com as credenciais do usuário. O Authorization Server então gera um authorization code.
O Authorization Code é Entregue via User-Agent: O Authorization Server redireciona o navegador de volta para o redirect_uri pré-registrado do Client, com o authorization code anexado como parâmetro de URL. Esta é uma etapa de front-channel — o código viaja pelo navegador, não diretamente entre servidores.
O Client Troca o Código por um Token (Back-Channel): O Client faz uma requisição direta servidor a servidor ao endpoint de token do Authorization Server, enviando o authorization code, o code_verifier (quando usando PKCE) e o redirect_uri. Clientes confidenciais também incluem seu Client Secret. Essa requisição de back-channel nunca passa pelo navegador.
O Authorization Server Emite os Tokens: O Authorization Server valida o código e as credenciais do cliente e emite um access token e, opcionalmente, um refresh token para o Client.
O Client Solicita o Recurso Protegido: O Client usa o access token para chamar a API do Resource Server, tipicamente passando-o no header Authorization: Bearer <token>.
O Resource Server Valida e Responde: O Resource Server valida o access token — em muitas implementações isso é feito localmente verificando uma assinatura JWT, enquanto outras dependem de token introspection para tokens opacos — e, se válido, retorna o recurso protegido solicitado.

Entendendo os Tokens

Os tokens são a moeda do OAuth 2.0. Após um fluxo bem-sucedido, sua aplicação acaba com um ou mais tokens em mãos. Entender o que cada um é e como manuseá-lo com segurança é essencial.

Access Tokens

O access token é a credencial que o Client usa para chamar APIs protegidas. Ele é de curta duração por design — tipicamente de alguns minutos a algumas horas — o que limita o dano caso o token seja vazado ou roubado. O Resource Server aceita esse token como prova de que a autorização foi concedida ao cliente para realizar um conjunto específico de ações dentro de um escopo específico.

Os access tokens vêm em dois formatos principais. Tokens opacos são strings aleatórias que não significam nada por si mesmas — o Resource Server deve chamar o endpoint de introspection do Authorization Server para descobrir o que o token representa. JWT (JSON Web Token) access tokens são autocontidos: são um payload JSON codificado em Base64 assinado pelo Authorization Server. O Resource Server pode verificar a assinatura localmente usando a chave pública do Authorization Server, confirmar que o token não expirou, verificar que ele contém os scopes necessários e responder — tudo sem fazer uma chamada de rede. Esta é uma abordagem comum em sistemas distribuídos modernos porque elimina o gargalo da introspection.

Um JWT é composto por três partes separadas por pontos: um header (algoritmo e tipo de token), um payload (claims como sujeito, emissor, expiração e scopes) e uma assinatura. A assinatura é o que torna o token à prova de adulteração: qualquer modificação no payload invalidaria a assinatura.

Refresh Tokens

Um refresh token é uma credencial tipicamente de vida mais longa do que os access tokens, permitindo que o Client obtenha um novo access token depois que o atual expira, sem exigir que o usuário passe pelo fluxo de autorização completo novamente. É isso que permite a uma aplicação web manter conexão com uma API ao longo de múltiplas sessões — o usuário concede acesso uma vez e o app atualiza silenciosamente seu access token em background.

Os refresh tokens devem ser armazenados e manuseados com muito cuidado. Ao contrário dos access tokens — que são tipicamente stateless e validados por assinatura — os refresh tokens são frequentemente segredos stateful. Se um refresh token for vazado, um atacante pode usá-lo para obter novos access tokens enquanto o refresh token permanecer válido. Por esse motivo, muitos Authorization Servers implementam a rotação de refresh tokens: cada vez que um refresh token é usado para obter um novo access token, o refresh token antigo é invalidado e um novo é emitido. Se o mesmo refresh token for usado duas vezes (sinal de que foi roubado), o servidor pode revogar toda a família de tokens.

Scopes

Os scopes definem os limites do que um access token permite. Quando o Client inicia uma requisição de autorização, ele especifica uma lista de scopes que está solicitando — por exemplo, read:emails, write:calendar ou profile. O Resource Owner vê esses scopes na tela de consentimento e decide se os aprova. O access token emitido carregará apenas os scopes aprovados, e o Resource Server os aplica.

Os scopes são uma ferramenta poderosa para aplicar o princípio do menor privilégio: uma aplicação deve solicitar apenas as permissões que realmente precisa, não um escopo amplo de “ler tudo” por padrão. Scopes bem projetados permitem que os usuários tomem decisões informadas sobre o que estão concedendo e dão ao Resource Server as informações necessárias para aplicar controle de acesso granular.

Erros Comuns e Armadilhas de Segurança

O OAuth 2.0 é um framework flexível, e essa flexibilidade cria espaço para erros de implementação. Aqui estão os erros mais comuns que os desenvolvedores cometem — e como evitá-los.

Armazenar tokens no localStorage

Single-page applications frequentemente armazenam tokens no localStorage por conveniência. Isso é um risco de segurança significativo. Qualquer JavaScript rodando na página — incluindo scripts de terceiros, anúncios injetados ou extensões do navegador — pode ler o localStorage. Uma única vulnerabilidade XSS (cross-site scripting) é suficiente para exfiltrar todos os tokens armazenados lá.

Uma alternativa mais segura para apps baseados em navegador é usar cookies HttpOnly gerenciados por um backend leve (o padrão BFF — Backend for Frontend), ou manter os tokens apenas em memória (eles são perdidos ao atualizar a página, mas podem ser silenciosamente readquiridos usando um iframe oculto ou uma atualização em background se o usuário ainda tiver uma sessão ativa no Authorization Server).

Não validar o parâmetro `state`

O parâmetro state é um valor aleatório opcional-mas-recomendado que o Client inclui na requisição de autorização e espera ver retornado inalterado no redirecionamento. É um mecanismo de proteção CSRF: se o state no redirecionamento não corresponder ao que o Client enviou originalmente, o Client deve rejeitar a resposta. Omitir essa verificação deixa o fluxo de autorização vulnerável a ataques de cross-site request forgery, onde um atacante engana o Client para completar um fluxo iniciado por outra pessoa.

Solicitar scopes excessivamente amplos

É tentador solicitar todos os scopes disponíveis de uma vez para evitar pedir permissão ao usuário novamente mais tarde. Isso viola o princípio do menor privilégio e corrói a confiança do usuário — usuários apresentados a uma tela de consentimento solicitando acesso para “ler e escrever todos os seus arquivos” quando o app só precisa ler uma pasta vão razoavelmente recusar. Solicite apenas o que você precisa, quando precisar. Isso às vezes é chamado de autorização incremental ou dynamic scopes.

Usar o Implicit Grant em novas aplicações

O Implicit Grant ainda é amplamente documentado e suportado por muitos Authorization Servers, mas não deve ser usado em nenhuma nova aplicação. Ele retorna o access token diretamente no fragmento da URL, onde pode ser registrado por servidores, vazado através do header Referer e acessado por qualquer JavaScript na página. O Authorization Code + PKCE fornece todos os mesmos benefícios para clientes públicos sem esses riscos.

Tratar OAuth como autenticação sem OIDC

Um erro clássico é usar a presença de um access token válido como prova da identidade do usuário. Um access token prova que alguém autorizou o Client — não diz quem é esse alguém. Se você precisar da identidade do usuário (para criar uma sessão, exibir um nome ou consultar uma conta), você deve usar o OpenID Connect sobre o OAuth 2.0 e validar o ID token, não o access token.

OAuth 2.0 e OpenID Connect: Como se Encaixam

O OAuth 2.0 e o OpenID Connect são intimamente relacionados, mas servem a propósitos diferentes. Entender onde um termina e o outro começa elimina muita confusão nesse espaço.

O OAuth 2.0 responde: “Esta aplicação pode realizar esta ação em nome deste usuário?” Lida com access tokens e scopes. Não diz nada sobre identidade.

O OpenID Connect responde: “Quem é este usuário?” É uma camada de identidade construída diretamente sobre o OAuth 2.0, usando os mesmos fluxos e endpoints. Ele adiciona um artefato fundamental: o ID token, um JWT emitido junto com o access token que contém claims sobre o usuário autenticado — coisas como sub (identificador de sujeito), email, name, picture e iat (timestamp de emissão). Ele também define um endpoint userinfo padrão que o Client pode chamar com o access token para recuperar claims adicionais.

Quando você usa “Entrar com o Google”, está usando OIDC construído sobre o OAuth 2.0. O Google atua tanto como Authorization Server (emitindo access tokens) quanto como OpenID Provider (emitindo ID tokens). Sua aplicação recebe ambos. O access token permite que seu app chame as APIs do Google. O ID token diz ao seu app quem acabou de fazer login.

A conclusão prática: se seu caso de uso é puramente delegação de acesso a APIs (ex.: um serviço que lê o calendário de um usuário), o OAuth 2.0 sozinho pode ser suficiente. Se seu caso de uso envolve login de usuário e gerenciamento de sessão, você quer o OIDC.

Outras Considerações Importantes

Tempo de Vida dos Tokens: Os access tokens são tipicamente de curta duração por razões de segurança. Os refresh tokens, de vida mais longa, permitem ao Client obter novos access tokens sem exigir que o Resource Owner reautorize a aplicação [1].
PKCE (Proof Key for Code Exchange): Esta extensão ao fluxo Authorization Code Grant é essencial para clientes públicos (ex.: apps móveis, single-page applications) que não conseguem armazenar com segurança um client secret. O PKCE mitiga ataques de interceptação de authorization code adicionando uma chave criptograficamente aleatória criada dinamicamente à requisição de autorização. As diretrizes modernas de segurança recomendam o uso de PKCE para todos os clientes, incluindo os confidenciais [1].
Revogação de Token: O OAuth 2.0 define um endpoint de revogação de token (RFC 7009) que permite a clientes e servidores de autorização invalidar explicitamente access e refresh tokens. Isso é importante para fluxos de logout e para responder a incidentes de segurança.
Descoberta do Authorization Server: A maioria dos Authorization Servers modernos expõe um documento de descoberta em /.well-known/openid-configuration (para OIDC) ou /.well-known/oauth-authorization-server (para OAuth 2.0 puro, definido na RFC 8414 [7]). Esse documento lista todos os endpoints do servidor, grant types suportados, algoritmos de assinatura e scopes, permitindo que os clientes se configurem dinamicamente.

Conclusão

O OAuth 2.0 é uma daquelas tecnologias que inicialmente parece complexa, mas se torna intuitiva quando você entende o problema que resolve e o modelo mental por trás dele. O insight central é a separação de responsabilidades: o usuário se autentica com o Authorization Server, e o Authorization Server emite um token de escopo limitado que o Client usa para agir em nome do usuário. As credenciais do usuário nunca saem do Authorization Server.

Os principais aprendizados deste guia:

O OAuth 2.0 é um framework de autorização, não um protocolo de autenticação. Para identidade, adicione o OpenID Connect por cima.
A propriedade de segurança real que ele fornece é acesso delegado sem exposição de credenciais — não ocultação de identidade.
O Authorization Code Grant + PKCE é a escolha certa para quase todas as novas aplicações hoje.
Tokens são credenciais sensíveis. Armazene access tokens em memória ou cookies HttpOnly. Proteja refresh tokens com o mesmo cuidado que senhas.
Aplique o princípio do menor privilégio aos scopes: solicite apenas o que você precisa.
O Authorization Server pode delegar a autenticação a um provedor de identidade externo — isso é o padrão em implantações enterprise com Keycloak, Okta e Auth0.

À medida que suas aplicações crescem em complexidade — microsserviços, integrações com terceiros, clientes móveis, chamadas máquina a máquina — o OAuth 2.0 fornece o vocabulário e a maquinaria para expressar e aplicar fronteiras de autorização de forma clara e segura.

Referências

[1] DigitalOcean. “An Introduction to OAuth 2.” DigitalOcean Community, https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2.

[2] Auth0. “Authentication vs. Authorization.” Auth0 Docs, https://auth0.com/docs/get-started/identity-fundamentals/authentication-and-authorization.

[3] Auth0. “OAuth 2.0 Authorization Framework.” Auth0 Docs, https://auth0.com/docs/authenticate/protocols/oauth.

[4] IETF. “RFC 6749 — The OAuth 2.0 Authorization Framework.” https://datatracker.ietf.org/doc/html/rfc6749.

[5] IETF. “RFC 7636 — Proof Key for Code Exchange by OAuth Public Clients.” https://datatracker.ietf.org/doc/html/rfc7636.

[6] IETF. “RFC 7009 — OAuth 2.0 Token Revocation.” https://datatracker.ietf.org/doc/html/rfc7009.

[7] IETF. “RFC 8414 — OAuth 2.0 Authorization Server Metadata.” https://datatracker.ietf.org/doc/html/rfc8414.