Personas

Toda troca OAuth, qualquer que seja o fluxo, é encenada por quatro papéis. Nomear cada um com precisão remove a maior parte da confusão, porque as descrições da spec (“o client redireciona o resource owner para o authorization server”) só fazem sentido quando se sabe quem é quem. Vale seguir com a mesma analogia do Panorama, a da chave do manobrista.

Os quatro papéis

Resource owner é o dono do recurso, quase sempre o usuário final. É quem tem o direito de conceder acesso ao dado protegido. No carro, é o dono do veículo. A spec observa que, quando o resource owner é uma pessoa, ela o chama de end user.

Client é o aplicativo que quer acesso e age em nome do resource owner, com a autorização dele. É o manobrista. Aqui mora uma confusão comum: “client” não é o cliente-consumidor da empresa nem é “o navegador”; é a aplicação que faz o pedido, seja ela um app web, um app de celular, uma CLI ou outro servidor.

Authorization server (AS) é quem emite os tokens, depois de autenticar o resource owner e obter o consentimento dele. É a recepção que confere o seu documento, pergunta “você autoriza?” e entrega a chave do manobrista. É dono do login, da tela de consentimento e dos endpoints /authorize e /token. Google, Auth0, Keycloak e Okta ocupam esse papel.

Resource server (RS) é quem hospeda os recursos protegidos e responde às requisições que trazem um access token válido. É o carro, ou melhor, a API que guarda as suas fotos. Ele não faz login de ninguém; a cada requisição, apenas valida o token e devolve (ou nega) o recurso. É comum o mesmo dono operar o AS e o RS (o login do Google e a API do Google Fotos), mas os papéis são distintos, e separá-los é justamente o que torna a delegação limpa.

Papel	Quem é, na prática	Analogia	Responsabilidade
Resource owner	o usuário	dono do carro	consente ou nega o acesso
Client	o app que pede acesso	manobrista	pede e usa o token, nunca vê a senha
Authorization server	o provedor de identidade (Google, Auth0)	recepção que confere o documento	autentica, coleta consentimento, emite tokens
Resource server	a API dos dados (Google Fotos)	o carro	valida o token e devolve o recurso

Público ou confidencial: o cliente tem um segredo?

Essa é a distinção que mais decide o que vem depois. Um cliente é confidencial se consegue guardar uma credencial secreta do resto do mundo, e público se não consegue.

O cliente confidencial roda onde o usuário não lê o seu código, num servidor. Ele pode guardar um client_secret e usá-lo para provar ao AS que é ele mesmo. É o caso de um app web renderizado no servidor, de um daemon de backend, de um serviço que fala com outro serviço.

O cliente público tem o código entregue ao dispositivo do usuário, então qualquer segredo embutido nele pode ser extraído. É a single-page app (todo o JavaScript no navegador), o app nativo de celular, o app desktop, a CLI. Ele não tem segredo com que provar que é ele mesmo.

Por que isso importa tanto: um authorization code, sozinho, é uma credencial ao portador. Se um cliente público tivesse só o code para trocar por tokens, qualquer um que interceptasse o code faria a troca. O cliente confidencial ainda apresenta o seu segredo, então um code roubado não serve sem ele. O cliente público não tem esse anteparo, e é exatamente esse o buraco que o PKCE tapa, razão pela qual o OAuth 2.1 tornou o PKCE obrigatório para todo mundo. A divisão público/confidencial não é taxonomia burocrática: é a bifurcação que decide como o cliente se prova, e ela desemboca direto na escolha do fluxo.

Convém desfazer um mal-entendido: “público” não quer dizer “menos confiável” nem “pior”. Um app de banco no celular é um cliente público. O termo só diz “não consegue guardar segredo”, e o protocolo compensa isso com PKCE no lugar do segredo.

Onde o token entra

Esses quatro papéis passam artefatos entre si: um code que vira token, um token que abre a API, um outro que renova o primeiro. A página de tokens cataloga cada um e diz por onde ele trafega.

Palavras-chave

Papéis: resource owner, client, authorization server, resource server, end user Tipos de cliente: cliente público, cliente confidencial, client_secret Conceitos: autorização delegada, credencial ao portador, PKCE