Validação do token

O PEP aceita um único tipo de token: o que o AS do Xokepoint emitiu, por token exchange (headless) ou por um harness login (interativo). Um token emitido direto pelo IdP do cliente é rejeitado com 401, mesmo que seja válido para o IdP. Ele não tem agente, e uma decisão sem agente é a situação que o Xokepoint existe para evitar.

A audience é o ingress MCP do ambiente, <origin>/api/v1/mcp/<workspace>/<ambiente>: a mesma URL que o agente chama, sem a parte do servidor. Um token de outro ambiente falha aqui mesmo que alguém tenha copiado as chaves dos dois.

Os passos de agente, grant e connection dependem de estado que muda depois da emissão. Um agente desativado, uma máquina ou um consentimento revogados, ou uma identity connection desabilitada cortam um token que ainda tem minutos de vida. A connection é conferida de novo logo antes da execução.

Só o ator atual conta. Um token pode trazer claims act aninhados, que registram uma cadeia de atores anteriores. O RFC 8693 §4.1 diz que eles são informativos, e o Xokepoint segue isso: a decisão usa só act.sub.

O 401 e o resource metadataCopiar link da seção

Todo 401 do ingress traz WWW-Authenticate com dois challenges, Bearer e DPoP com seus algs (RFC 9449 §7.1). Cada um traz resource_metadata, a URL do protected resource metadata da URL MCP do servidor (RFC 9728):

WWW-Authenticate: Bearer resource_metadata="<origin>/.well-known/oauth-protected-resource/api/v1/mcp/<workspace>/<ambiente>/<servidor>", DPoP algs="ES256", resource_metadata="<origin>/.well-known/oauth-protected-resource/api/v1/mcp/<workspace>/<ambiente>/<servidor>"

É a URL well-known que um cliente monta a partir da própria URL MCP (RFC 9728 §3.1), então um harness que não lê o 401 antes encontra o mesmo metadata. Um servidor que não existe ou está desativado recebe 404. GET, HEAD e DELETE na URL MCP respondem 405 com Allow: POST: o ingress não oferece stream iniciado pelo servidor nem encerramento de sessão próprio.

Uma requisição com credencial também recebe um error, só no challenge do esquema que ela usou. Um cabeçalho Authorization malformado conta como Bearer.

• invalid_token: um token inválido, expirado ou desconhecido, ou um token usado com o esquema errado.
• invalid_dpop_proof: um token preso com Authorization: DPoP e uma prova ausente, repetida no cabeçalho, inválida ou reutilizada, ou uma prova de outra chave.

O corpo da resposta traz o mesmo code. invalid_dpop_proof diz ao harness para mandar uma prova nova; invalid_token diz para obter um token novo. O metadata traz resource (o ingress do ambiente, igual ao aud do token, um só para todos os seus servidores), authorization_servers (o AS do ambiente), bearer_methods_supported: ["header"] e dpop_signing_alg_values_supported. Um harness de código começa o login a partir dele (Conectar um harness de código).

DPoPCopiar link da seção

Um token com cnf.jkt está preso a uma chave do harness (RFC 9449). O PEP então exige Authorization: DPoP <token> e um cabeçalho DPoP com uma prova assinada pela mesma chave, e confere htm, htu, iat, ath e que o jti não foi usado antes. Um token copiado sem a chave é recusado com invalid_dpop_proof. Um token sem cnf mantém o esquema Bearer. A política vê o resultado em context.chokepoint.binding (Contexto confiável).

A URL da chamadaCopiar link da seção

A URL da chamada traz workspace, ambiente e MCP server. Ela escolhe o destino e não concede acesso. Quem concede é a política, a partir do que o token provou. Só claims com assinatura verificada viram entrada do pedido de autorização.