Resumen

  • El token de continuación de GNAP, ligado a la clave del cliente, sirve para seguir una solicitud concreta ante el servidor de autorización, no para llamar a un recurso protegido.
  • Mientras la solicitud está pendiente, RFC 9635 prohíbe emitir tokens de API y revelar información del sujeto. La interacción terminada aún requiere que el servidor reevalúe el contexto.

Es fácil convertir una señal de progreso en una conclusión demasiado grande. Una pantalla puede indicar que la persona terminó una interacción. Un cliente puede conservar una URI de continuación. Una firma puede demostrar control de una clave. Ninguno de esos hechos responde por sí solo a la pregunta decisiva: ¿puede este cliente hacer ahora esta llamada concreta a esta API?

RFC 9635 estructura GNAP precisamente para evitar esa confusión. El cliente presenta una solicitud de delegación al servidor de autorización. Si todavía hace falta consentimiento o interacción, la solicitud pasa a pending. El servidor puede devolver información para continuar, pero no puede conceder tokens de acceso para API ni entregar información del sujeto. Todavía se negocia el acceso; no se ha concedido.

La credencial de continuación tiene una función limitada. Debe estar vinculada a la clave de la instancia cliente, no puede ser de portador y debe presentarse con prueba de esa clave ante la URI de continuación. El servidor de autorización verifica tanto la prueba como su relación con la clave correspondiente. Así se protege quién continúa la misma conversación. No se crea por ello un permiso para un servidor de recursos.

La separación es normativa en ambos sentidos. Un token de acceso común no debe servir en un punto de continuación. A la inversa, un token de continuación no debe servir para hacer una solicitud autorizada a un servidor de recursos, incluso si ambos servidores están juntos. Que dos valores viajen en una cabecera parecida no les da el mismo destinatario, alcance ni consecuencia.

Tampoco la interacción completada cierra automáticamente la decisión. Después de ella, el servidor de autorización vuelve a procesar y reevaluar toda la solicitud, tanto si el propietario del recurso aprobó como si denegó. Solo una solicitud aprobada puede devolver tokens de API o información del sujeto. Una solicitud finalizada ya no puede emitir nuevos tokens, devolver información ni reiniciar la interacción; para acceder en el futuro se necesita otra solicitud.

La gestión del token es un tercer plano. Un token de API puede incluir una URI y una credencial de gestión para rotarlo o revocarlo. La rotación conserva los derechos y propiedades del token original; no amplía el alcance. Para obtener otros derechos hay que actualizar la solicitud mediante continuación o crear una nueva. Mantener una credencial no equivale a extender la delegación.

El servidor de recursos conserva otro control. Un token de API GNAP se presenta con la prueba exigida; un recurso puede desafiar una llamada sin token o con token inválido. Incluso esa validación no demuestra que el fin operativo siga siendo oportuno, que una política empresarial actual lo admita o que el efecto se haya producido.

La cadena de evidencia debe guardar piezas distintas: solicitud y acceso pedido, estado pendiente, URI y prueba de continuación, resultado de interacción, reevaluación, alcance del token de API, validación del recurso, recepción de la llamada y efecto observado. Llamar a todo ello «autorización» borra las responsabilidades que el protocolo distribuye deliberadamente.

Sources