Visão geral
Transforme seu projeto em um provedor OAuth 2.1 e OpenID Connect, para que outros produtos ofereçam "Entrar com o seu app".
Seu projeto já autentica pessoas. O Servidor OAuth inverte isso: ele permite que outras aplicações autentiquem pessoas com o seu produto, do jeito que você entra em serviços com Google ou GitHub.
Uma vez ligado, um desenvolvedor terceiro registra um app no seu projeto, manda os usuários dele para o seu endpoint de autorização, e recebe tokens que carregam a identidade dos seus usuários. Você decide quem são, o que o app pode ver e quando o acesso termina.
Não é assim que você entra no seu próprio app
Para o seu próprio frontend, continue usando auth.signIn e a sessão que ele
devolve. O Servidor OAuth é para aplicações de outras pessoas. Usá-lo para
entrar no seu próprio produto adiciona uma ida e volta de redirect e uma tela de
consentimento que você não precisa.
As três partes
Todo fluxo OAuth tem três, e quase toda confusão vem de misturá-las.
Servidor de autorizaçãoseu projetoOptionalRoda na nulvless. Autentica o usuário, mostra o consentimento, emite tokens. O endereço dele é o emissor.
Clienteo app de terceiroOptionalRegistrado no seu projeto. Tem um client_id, e um client_secret se puder
guardar um. Nunca vê a senha do usuário.
Dono do recursoseu usuárioOptionalA pessoa que decide se aquele app pode agir em nome dela.
Há uma quarta participante fácil de esquecer: o seu próprio frontend. A tela de consentimento é uma página sua, não algo que a nulvless renderiza. Isso é deliberado — no momento em que alguém concede acesso, essa pessoa deve estar olhando para o seu produto, não para o nosso. Construí-la é uma página à parte.
O que o OAuth 2.1 muda
OAuth 2.1 é consolidação, não protocolo novo. Ele traz uma década de prática para a base, e o que importa aqui é o que ele remove.
- PKCE é obrigatório, para todo cliente, não só os públicos. Não existe rodar
o fluxo sem
code_challenge. - O grant implícito acabou. Sem
response_type=token. Só código. - O grant de senha acabou. Nenhum app manipula as credenciais dos seus usuários.
- Redirect URIs casam exatamente. Sem curinga, sem prefixo.
Se você já integrou um provedor OAuth antigo, o fluxo vai parecer familiar e um pouco mais estrito. Nada do que dá para fazer aqui é inseguro por padrão, porque as opções inseguras foram removidas em vez de desencorajadas.
O que existe aqui
Início rápido
Ligar o servidor, registrar um cliente e rodar um fluxo inteiro.
Fluxo de autorização
Cada redirect e requisição, em ordem, com os parâmetros reais.
Tela de consentimento
A página que você constrói, em Next.js, Nuxt, SvelteKit e Remix.
Clientes
Registrar apps, segredos, redirect URIs, registro dinâmico.
Tokens
O que tem dentro e como um resource server valida.
Referência
Endpoints, escopos, códigos de erro.
Escopos
Quatro, e significam o que o OpenID Connect diz que significam.
| Escopo | O cliente recebe |
|---|---|
openid | Um ID token. Sem ele, isto é OAuth puro e nenhuma identidade é afirmada. |
email | O e-mail do usuário e se está verificado. |
profile | Nome e foto. |
phone | Telefone e se está verificado. |
Uma requisição sem scope cai em email em vez de falhar. Peça o conjunto mais
estreito que faz a integração funcionar — cada escopo extra é algo que o usuário
tem que ler e aceitar.
Ambientes
Cada ambiente do seu projeto é um servidor de autorização separado, com emissor, clientes e segredos próprios. Um cliente registrado em staging não existe em produção, e um token emitido em um não valida no outro.
Essa separação é o ponto: você pode entregar credenciais de staging a um parceiro sem dar nada que funcione contra usuários reais.