Resumo

  • A RFC 9728 permite publicar metadados de um recurso protegido; o documento orienta descoberta e não autoriza uma chamada.
  • O campo resource precisa coincidir exatamente com a identidade esperada. Token, aceitação pelo recurso e efeito continuam sendo verificações separadas.

Descobrir um issuer é diferente de receber um direito. O documento pode dizer ao cliente quais servidores de autorização podem ser usados e quais scopes o recurso divulga. Ainda falta saber se o cliente obterá token, se o token terá audience apropriada, se será aceito e se a regra de negócio vigente permite a ação.

RFC 9728 coloca a descoberta em um endereço .well-known derivado do identificador da própria resource. Isso reduz ambiguidade, sobretudo quando um host contém várias rotas ou locatários. O sufixo é inserido antes do caminho precisamente para que recursos distintos possam publicar documentos distintos. Não é uma descrição geral do host nem uma permissão que se espalha por caminhos parecidos.

O controle decisivo é a correspondência exata. Em descoberta comum, o valor obrigatório resource deve ser idêntico ao identificador que gerou a URL de metadados. Se a URL veio de WWW-Authenticate, ele deve ser idêntico à URL solicitada ao servidor de recursos. Em caso de diferença, os dados não podem ser usados. A regra impede que um documento próximo adquira autoridade por semelhança.

Também não se deve tratar campos publicados como lista completa de direitos. authorization_servers pode omitir servidores suportados e scopes_supported pode omitir scopes. Essas listas descrevem interoperabilidade disponível para publicação; não resolvem consentimento, emissão, audience, expiração, revogação ou aceitação. Metadados assinados apenas acrescentam quem atestou o conjunto de afirmações; não autenticam o cliente nem substituem o validador da API.

O desafio WWW-Authenticate é outro ponto de descoberta, não uma admissão. Ele pode apontar resource_metadata; depois o cliente ainda busca metadados, obtém autorização e retorna com credencial. RFC 8414, RFC 8707 e RFC 6750 mantêm separados os papéis de metadados do servidor, alvo do recurso e uso bearer.

Sources