OAuth 2.0

Analogia

A chave do hotel, não a do apartamento

Você não entrega a chave de casa ao estacionamento — pede um cartão temporário só para o hall. OAuth é o cartão com escopo e prazo; a senha continua só com o hotel (IdP).

01Conceito

Delegar sem vazar a senha

Terceiros e SPAs não são lugar para senha nem para client secret.

O código de autorização é de uso único e curto; tokens vêm no canal que o browser menos expõe.

OIDC = OAuth + id_token e UserInfo. Para “Login with X”, você quer OIDC; para “app acessa minha planilha”, OAuth com escopos basta.

Client confidential (backend) usa secret; client público (SPA/mobile) usa PKCE. Misturar os dois é a origem de muitos bugs de segurança.

02No mundo real

Como isso aparece na prática

SSO da empresa

Cenário

Três produtos internos precisam do mesmo login corporativo e MFA do IdP.

Como o padrão entra

Keycloak/Entra como IdP; cada app é client OIDC com redirect allowlisted.

Trade-off: Dependência do IdP: se ele cai, o login cai — prepare status e cache de sessão já estabelecida.

App mobile acessando API

Cenário

O app não pode embutir client secret; deep link recebe o code.

Como o padrão entra

PKCE + claim de redirect; refresh com rotação; access curto.

Trade-off: Interception de custom URL schemes exige cuidado (app links / verified links).

03Cuidado

Onde isto dá errado

Password grant / senha no SPA
O cliente pede usuário e senha e chama o token endpoint. Isso não é OAuth moderno — é phishing caseiro com branding OAuth.
Redirect URI aberta
Permitir * ou redirects não registrados entrega o code ao atacante. Allowlist exata.
Ignorar state e nonce
Sem state, CSRF no callback; sem nonce no OIDC, replay do id_token.

04Implementação

Troca do code com PKCE

// Authorization Code + PKCE (SPA / mobile). Nunca o fluxo implícito.
// 1) App gera code_verifier e code_challenge (S256).
// 2) Redireciona o usuario ao IdP com client_id, redirect_uri, challenge.
// 3) IdP autentica (e MFA) e devolve ?code=...
// 4) App troca code + verifier por tokens no token endpoint (back-channel).

async function trocarCodigo(code: string, verifier: string) {
  const body = new URLSearchParams({
    grant_type: "authorization_code",
    code,
    redirect_uri: REDIRECT,
    client_id: CLIENT_ID,
    code_verifier: verifier,
  });
  const res = await fetch(TOKEN_URL, { method: "POST", body });
  if (!res.ok) throw new Error("token exchange falhou");
  return res.json(); // access_token, refresh_token?, id_token?
}

05Decisão

Quando usar × quando evitar

Use quando

SSO, login social, APIs para terceiros.
Identidade centralizada entre produtos.

Evite quando

App único sem IdP e sem terceiros — sessão local bem feita.
Fluxos depreciados (implícito, password).

Testar o que ficou

3 armadilhas de OAuth 2.0 viram perguntas, com o nome do padrão escondido, misturadas com padrões parecidos.

Onde isto aparece de verdade

Você já usa isto, talvez sem saber o nome.

Login with Google / GitHubO botão de SSO que redireciona ao IdP e volta com autorização — sem a senha no seu form.
Auth0, Keycloak, CognitoIdentity providers que implementam OAuth/OIDC para você não operar o protocolo na mão.
escopos read:email / offline_accessO pedido explícito do que o cliente poderá fazer em nome do usuário.

O padrão em uma linha

Sem nome de domínio, sem cerimônia. Só a ideia.

// Código no front, tokens no back-channel — com PKCE.
grant_type=authorization_code&code=…&code_verifier=…

O que ele cobra

2 saltos a mais entre a chamada e o efeito.

Operar ou integrar um IdP, redirect URIs, rotação de secrets de client confidential
Debugging de redirect, state/nonce e escopos é mais caro que um login local bem feito

Não vale se: só há um app seu, sem terceiros nem SSO — sessão própria com autenticação sólida costuma bastar.