Resumo

  • O continuation access token do GNAP é vinculado à chave do cliente e serve para continuar uma solicitação específica, não para chamar um servidor de recursos.
  • Enquanto a solicitação está pendente, a RFC 9635 veda a emissão de tokens de API e a liberação de informação de sujeito. Uma interação concluída ainda precisa ser reavaliada pelo servidor de autorização.

Uma tela pode informar que a pessoa terminou a etapa de aprovação. Esse aviso é útil, mas não diz que acesso foi concedido, para qual recurso, nem se alguma chamada foi executada. Pode significar apenas que o navegador voltou ao cliente, que existe uma URI de continuação ou que a posse de uma chave foi provada.

A RFC 9635 estrutura o GNAP para impedir essa ampliação indevida. O cliente abre um pedido de concessão no servidor de autorização. Se ainda for necessário consentimento do proprietário do recurso ou interação do usuário, o pedido fica em pending. O servidor pode devolver meios de continuação, mas não pode conceder tokens para API nem devolver informação de sujeito. A conversa sobre acesso continua; o acesso ainda não foi concedido.

A credencial de continuação tem uma tarefa estreita. Ela precisa estar vinculada à chave da instância cliente, não pode ser bearer token e deve ser apresentada, com prova daquela chave, à URI de continuação. O servidor de autorização valida a assinatura e a ligação com a chave adequada. Isso protege quem pode retomar a mesma conversa. Não cria uma autorização para um recurso protegido.

A separação é obrigatória nos dois sentidos. Um access token comum não pode ser usado no endpoint de continuação. Em sentido inverso, o continuation access token não pode fazer uma solicitação autorizada a um servidor de recursos, mesmo se ele estiver no mesmo ambiente do servidor de autorização. A aparência parecida de dois valores não lhes dá o mesmo verificador, escopo ou efeito.

O fim da interação também não encerra a decisão automaticamente. Depois dele, o servidor de autorização devolve o pedido ao processamento e reavalia seu contexto completo, tenha o proprietário do recurso aprovado ou negado. Só um pedido aprovado pode devolver tokens de API ou informação de sujeito. Um pedido finalizado não emite tokens novos, não devolve informação e não reabre a interação; acesso futuro exige novo pedido.

O gerenciamento de token é um terceiro plano. Um token de API pode trazer URI e credencial próprias para rotação ou revogação. A rotação conserva direitos e propriedades do token original; não amplia escopo. Direitos diferentes exigem atualização pela continuação e nova avaliação, ou uma solicitação nova. Continuidade administrativa não é expansão de poder.

O servidor de recursos preserva sua própria fronteira de validação. O token de API GNAP é apresentado com a prova exigida, e o servidor pode desafiar uma chamada sem token ou com token inválido. Mesmo isso não demonstra que a finalidade de negócio ainda é desejada, que a condição operacional atual permite o ato ou que o efeito ocorreu.

A trilha de evidência precisa manter fatos distintos: identificação e acesso pedido, estado pendente, URI e prova de continuação, resultado da interação, reavaliação, escopo do token de API, validação pelo recurso, recebimento da chamada e efeito observado. Chamar todo o conjunto de “autorizado” apaga os limites que o protocolo preserva.

Fontes