Clientes

Um cliente é uma aplicação autorizada a pedir acesso aos seus usuários. Registrar um produz um client_id, opcionalmente um client_secret, e a lista de redirect URIs para onde o fluxo pode voltar.

Público e confidencial

A divisão não é sobre confiança, é sobre conseguir guardar um segredo.

Uma single-page app é pública mesmo que o desenvolvedor insista que não. Qualquer coisa no bundle é legível por quem abrir o devtools.

Os dois tipos rodam o mesmo fluxo, e os dois precisam de PKCE. O segredo é um fator adicional para quem pode guardá-lo, não um substituto do verifier.

Redirect URIs

Registrados antes, casados exatamente.

Registrado:  https://acme.example.com/callback
Casa:        https://acme.example.com/callback
Rejeitado:   https://acme.example.com/callback/
Rejeitado:   https://acme.example.com/Callback
Rejeitado:   https://acme.example.com/callback?next=/home

Sem curinga, sem prefixo, sem substring. É mais estrito que provedores OAuth antigos e é a regra mais valiosa da especificação: casamento frouxo de redirect é como códigos de autorização acabam entregues à parte errada.

Valores dinâmicos que antes moravam no redirect URI vão no state, que volta intacto.

Registre um URI por ambiente que o cliente realmente usa — http://localhost:3000/callback para desenvolvimento é normal.

Registrando pelo Console

Servidor OAuth → Aplicações → Nova aplicação. Você informa:

O segredo é mostrado uma vez, na criação. Não há como lê-lo depois — regenerar é a única saída, e invalida o antigo imediatamente.

Registrando por código

const { data, error } = await nulvless.auth.oauth.register({
  name: 'Acme Analytics',
  redirectUris: ['https://acme.example.com/callback'],
  logoUri: 'https://acme.example.com/logo.png',
  clientUri: 'https://acme.example.com',
});

Registro dinâmico

A RFC 7591 permite que uma aplicação se registre sozinha, sem ninguém no seu Console. Vem desligado, e vale dizer o trade-off com clareza.

Ligue quando você quiser um ecossistema aberto — qualquer um constrói sem pedir — ou quando estiver atendendo clientes MCP e ferramentas de agentes, onde quem registra é software.

Deixe desligado quando suas integrações são parcerias. Todo cliente que existe é um nome que pode aparecer numa tela de consentimento ao lado do seu produto, e um endpoint aberto significa que você não controla essa lista.

Rotacionando um segredo

Aplicações → o app → Regenerar segredo. O antigo para de funcionar na hora: não há janela de sobreposição, então combine com quem opera o cliente antes.

Rotacione quando alguém com acesso sai, quando um segredo passou por log ou chamado de suporte, ou na cadência que seu programa de compliance definir.

O que o usuário pode revogar

Quem concedeu acesso pode retirar, e sua aplicação pode mostrar essa lista:

const { data: grants } = await nulvless.auth.oauth.list();
await nulvless.auth.oauth.revoke(clientId);

Vale construir nas configurações de conta. "Quais apps veem meus dados, e como eu corto um" é uma pergunta que as pessoas fazem depois de já terem concedido algo, e a resposta não deveria ser abrir um chamado.