Resumen

  • RFC 9728 permite que un recurso protegido publique cómo se puede interactuar con él; esa publicación no concede acceso al recurso.
  • La coincidencia exacta del identificador de recurso decide si los metadatos se pueden usar. La emisión, aceptación y consecuencia de un token ocurren después, en otras superficies.

Que un documento nombre a un servidor de autorización no significa que ese servidor vaya a emitir un token para este cliente. Tampoco significa que el token sirva para el recurso, que el recurso lo acepte o que una operación siga permitida. Esos son hechos distintos que suelen comprimirse en un tablero con el rótulo «autorizado».

RFC 9728 ofrece una forma común de evitar esa compresión. El recurso publica un documento JSON en una ubicación .well-known derivada de su identificador. Puede anunciar servidores de autorización, scopes y métodos de presentación. Con ello reduce incertidumbre de descubrimiento; no adjudica una petición ni sustituye a quien evalúa la política.

La defensa central es literal: el valor obligatorio resource debe ser idéntico al identificador usado para derivar la URL de metadatos. Si la URL llegó en un desafío WWW-Authenticate, debe ser idéntico a la URL solicitada al servidor de recursos. Si no coincide, el contenido no se puede usar. No basta un mismo host ni una ruta parecida.

La regla importa en servidores con varios recursos o inquilinos. El sufijo well-known se inserta antes de la ruta, permitiendo documentos distintos para recursos distintos del mismo host. RFC 9728 aclara que esa técnica no anuncia información general del host. Convertirla en una lista global de permisos desplaza la frontera de política hacia una inferencia que el protocolo no hizo.

Las listas publicadas tampoco son un catálogo completo. authorization_servers es opcional y puede omitir servidores soportados; scopes_supported puede omitir scopes. Una entrada es información de interoperabilidad, no la resolución de una solicitud. La autorización, el audience y la validación del token siguen exigiendo sus propios verificadores.

Los metadatos firmados limitan la mejora a una cosa: quién avaló ciertos datos de descubrimiento. No autentican al cliente, no prueban consentimiento ni vuelven válido un token. RFC 8414, RFC 8707 y RFC 6750 mantienen separadas la descripción del servidor, el recurso objetivo y la presentación bearer. RFC 9728 añade la descripción del recurso, no una autoridad que absorba las demás.

Sources