Como um agente de IA faz login no seu app: OAuth 2.1 e o passo humano

Um agente de IA que administra a sua aplicação precisa de uma credencial. Sem ela, ele só consegue conversar sobre o sistema, não operá-lo. O problema é dar essa credencial sem entregar a chave da conta a um processo que ninguém está olhando.

No Infrastructure, o caminho é OAuth 2.1 com o device flow: o agente pede acesso, uma pessoa confirma com um código de 8 caracteres lido no próprio e-mail, e o token sai escopado para aquele recurso. A senha nunca passa pelo agente.

O que o agente precisa, e o que ele não precisa

Um agente de IA pode operar um sistema por uma interface de ferramentas, o Model Context Protocol (MCP). Para isso, ele precisa responder a duas perguntas: quem é o usuário que o autorizou, e sobre qual aplicação ele pode agir.

Ele não precisa de:

• a senha da conta;

• uma chave secreta do backend, que assina sessões;

• acesso ao navegador da pessoa.

A chave secreta (ak_) fica no servidor da aplicação. O agente não a vê. O que ele recebe é um token curto, emitido para o recurso específico que ele vai usar.

O fluxo, passo a passo

No device flow, o agente mostra um código e espera que alguém o confirme em outro lugar, como fazem as TVs que pedem login pelo celular.

1. O agente se conecta ao servidor MCP da aplicação, em um endereço que já traz o identificador dela:

https://auth.worker.myinfrastructure.click/mcp/<applicationId>

2. O servidor responde pedindo autorização, com a lista de escopos que o agente quer usar.

3. A pessoa abre a página de consentimento e vê quais permissões estão sendo pedidas para qual aplicação.

4. Um código de 8 caracteres chega no e-mail da pessoa, no formato ABCD-EFGH. Ela o informa ao agente, que o apresenta no fluxo do device code.

5. O token é emitido com audiência restrita ao recurso MCP daquela aplicação.

O passo 4 é o único que exige uma pessoa de verdade. Ele serve para provar que quem autorizou tem acesso à caixa de entrada. O código vale 10 minutos e funciona uma vez.

A autorização é por produto, não global

O consentimento não dá acesso a tudo: vale para uma aplicação específica. Se você autorizou um agente a administrar a aplicação de blog, ele não ganha acesso à aplicação de loja. O token traz o recurso no claim aud (RFC 8707), e o servidor MCP recusa qualquer token cuja audiência não seja a dele.

Isso muda a forma de pensar a permissão. Em vez de "o agente tem acesso à minha conta", a pergunta passa a ser "o agente tem acesso a esta aplicação, com estes escopos". Se você quiser revogar, revoga aquela aplicação e o restante continua intacto.

Do lado de quem constrói o servidor MCP

Se você está criando um servidor MCP próprio sobre o Auth, o contrato tem três partes:

• publicar a Protected Resource Metadata (RFC 9728), para o cliente descobrir onde autorizar;

• validar o aud do token em cada requisição, comparando com a URL do seu recurso;

• usar PKCE no fluxo de código, que é o que a spec exige.

const { payload } = await jwtVerify(token, JWKS, {
    audience: 'https://auth.worker.myinfrastructure.click/mcp/<applicationId>',
})

Se a verificação falhar, responda 401 com o cabeçalho WWW-Authenticate apontando para a metadata. O cliente usa essa resposta para iniciar o fluxo de novo.

O que o agente não consegue fazer sozinho

O device flow tem um limite de propósito. Um agente não cria a própria conta, não aprova o próprio acesso e não escolhe os escopos além do que foi pedido na tela de consentimento. Se o agente precisa de algo fora do que foi autorizado, ele recebe um erro e o pedido volta para a pessoa.

Esse desenho é o que deixa um agente útil em produção. Ele opera dentro do que foi permitido, e cada ação fica associada a uma autorização visível.

Perguntas frequentes

O agente guarda a minha senha?

Não. Ele nunca recebe a senha. Recebe um token OAuth 2.1, que expira, e que você pode revogar pela aplicação a qualquer momento.

Por que um código no e-mail, e não um link?

O código é lido pela pessoa e digitado no lugar onde o pedido foi feito. Como não há link, não existe URL de retorno que possa ser fixada ou sequestrada.

Um token dá acesso a todas as minhas aplicações?

Não. Cada token é emitido para um recurso específico, identificado pela audiência. Autorizar uma aplicação não autoriza as outras.

O agente consegue criar uma conta nova sozinho?

Não. A entrada continua exigindo a leitura do código no e-mail, que prova que alguém controla a caixa de entrada.

Para continuar lendo

• Login sem senha com código no e-mail: como funciona e quando usar

• Liberar e bloquear partes do app pelo plano do usuário

• Guardar dados e arquivos do app sem migration nem credencial de nuvem

Quando faz sentido dar acesso a um agente

Vale a pena quando o agente vai executar ações repetíveis sobre a aplicação, como listar usuários, revisar sessões ou consultar estatísticas. Para uma tarefa única, o painel costuma ser mais simples. O Auth serve aos dois casos, com a mesma credencial e os mesmos limites.

Fontes

• Referência do Auth para pessoas e agentes (llms.txt)

• Página do Auth