Résumé

  • Dans GNAP, le jeton de continuation lié à une clé permet au client de poursuivre une demande précise ; il ne permet pas d’appeler un serveur de ressources.
  • Tant que la demande est en attente, aucun jeton d’API ni aucune information sur le sujet ne peut être remis. Une interaction terminée déclenche encore une réévaluation.

Une interface peut annoncer que l’utilisateur a terminé son parcours. Cette annonce est utile, mais elle ne dit pas qui a accordé quel droit, pour quelle ressource, à quel instant, ni si l’action demandée a été exécutée. Elle ne dit même pas nécessairement que le serveur d’autorisation a fini son examen.

RFC 9635 place cette nuance au cœur de GNAP. Le client ouvre une demande de délégation auprès d’un serveur d’autorisation. Si le consentement du propriétaire de la ressource ou une interaction est encore nécessaire, la demande entre dans l’état pending. Dans cet état, le serveur peut transmettre des informations de continuation, mais ne peut ni remettre un jeton d’accès aux API ni divulguer des informations sur le sujet. La demande est encore une négociation, pas l’accès obtenu.

Le jeton qui accompagne cette négociation a un périmètre volontairement étroit. Il est lié à la clé de l’instance cliente, ne peut pas être un jeton au porteur et doit être présenté, avec une preuve de cette clé, à l’URI de continuation. Le serveur d’autorisation vérifie la signature et son lien avec la clé attendue. Cette preuve protège la reprise de la conversation ; elle ne transforme pas la conversation en mandat auprès d’une API.

La règle est explicite des deux côtés. Un jeton d’accès ordinaire ne doit pas fonctionner auprès du point de continuation. Inversement, un jeton de continuation ne doit pas servir à faire une requête autorisée au serveur de ressources, même si ce serveur est hébergé avec le serveur d’autorisation. Une même apparence de jeton ne crée ni un même vérificateur ni le même effet permis.

La fin de l’interaction ne supprime pas cette frontière. Après l’interaction, le serveur d’autorisation replace la demande en traitement et réévalue son contexte complet, que le propriétaire ait accepté ou refusé. Seule une demande approuvée peut produire des jetons utilisables pour une API ou des informations de sujet. Une demande finalisée ne peut plus émettre de nouveau jeton, fournir ces informations ni relancer l’interaction. Il faut alors une nouvelle demande.

La gestion de jeton est encore un autre plan. Un jeton d’API peut porter une URI et un jeton de gestion distincts pour la rotation ou la révocation. Une rotation conserve les droits et les propriétés du jeton d’origine ; elle ne les élargit pas. Pour demander d’autres droits, le client doit mettre à jour la négociation ou ouvrir une nouvelle demande. La continuité administrative n’est pas une extension de pouvoir.

Le serveur de ressources reste son propre point de contrôle. Un jeton d’API GNAP est présenté avec la preuve prévue, et le serveur peut mettre au défi une requête sans jeton ou munie d’un jeton invalide. Ce contrôle n’établit pas, à lui seul, que le processus métier demeure souhaité, que les conditions opérationnelles sont réunies ou que l’effet demandé s’est produit.

Le dossier exploitable doit donc conserver des faits séparés : demande et accès sollicités, état en attente, URI de continuation et preuve de clé, résultat d’interaction, nouvelle évaluation, portée du jeton d’API, validation par le serveur de ressources, réception de la requête et effet observé. Réduire cette chaîne à « autorisé » efface précisément les limites que le protocole a construites.

Sources