Résumé

  • Le premier draft des Transactional Access Tokens impose une décision de politique à chaque demande, un seul resource server par audience et un identifiant txn différent pour chaque audience.
  • Une durée recommandée de 300 secondes borne l’exposition du jeton ; elle ne raccourcit ni le refresh token, ni le client credential, ni le consentement, ni le pouvoir de demander à nouveau.

draft-tulshi-oauth-transactional-access-tokens-00 date du 29 septembre 2026. C’est un Internet-Draft individuel visant le Standards Track, pas un document adopté par le groupe OAuth, pas un consensus IETF et pas un RFC. Aucune des sources examinées ne prouve une implémentation ou un déploiement. La nouvelle utile se trouve dans la chaîne de contrôle proposée, non dans un succès opérationnel encore absent.

Un Txn-AT reprend le profil JWT access token de RFC 9068, mais porte le type txnat+jwt. Ce choix doit provoquer un échec chez un serveur qui ne comprend pas la sémantique transactionnelle. Le champ aud désigne exactement une ressource. txn identifie la transaction pour cette audience, tandis que tctx et rctx transportent le contexte que l’authorization server a évalué et affirme.

Le serveur décide à chaque demande. Même un grant, un credential ou un handle valide ne suffit pas : la politique peut refuser avec transaction_denied. Pour une nouvelle transaction, le serveur remet aussi un handle opaque, lié au client, au sujet et, lorsque nécessaire, à la clé de sender constraint. Ce handle peut servir à demander d’autres Txn-AT pour la même transaction.

Il faut donc conserver plusieurs reçus. Le credential durable explique le droit de demander. Le reçu de politique explique le choix réalisé maintenant. Le handle relie des demandes sans être montré aux ressources. Chaque Txn-AT représente une assertion destinée à une seule ressource. Un éventuel Txn-Token reprend une partie du contexte dans le domaine de confiance interne. Le commit et le résultat viennent ensuite.

Le brouillage commence lorsque l’on appelle toute cette chaîne « autorisation ». Un refresh token valide n’approuve pas la prochaine opération. Un handle valide ne garantit pas que la transaction peut s’étendre à une nouvelle ressource. Une signature JWT correcte ne prouve pas que le contexte était frais. L’acceptation du token ne prouve ni l’exécution, ni l’unicité de l’effet, ni le succès.

Le draft reconnaît la tension : le consentement et l’autorité du client restent durables. L’utilisateur peut consentir une fois, puis un refresh token déclenche des demandes ultérieures sans nouvelle interaction. Les client credentials jouent le même rôle de racine persistante. Une compromission ne contourne pas nécessairement la politique, mais elle donne à l’attaquant la capacité de la solliciter encore et encore.

La sécurité dépend alors du verbe « évaluer ». Le serveur ne doit pas recopier les données du client dans tctx ou rctx sans les soumettre à sa politique. Il doit considérer sujet, méthode d’authentification, attestation, ressource, authorization details et environnement. Une politique obsolète peut toutefois signer proprement une conclusion erronée. La cryptographie protège l’assertion du serveur ; elle ne garantit pas la qualité de son jugement.

L’identifiant par audience réduit une corrélation précise. Deux resource servers ne peuvent pas comparer simplement txn pour découvrir la même transaction. Mais client_id reste commun, le timing reste visible, un sujet peut ne pas être pairwise, et un contexte trop riche peut devenir une empreinte. L’authorization server, lui, connaît l’identifiant interne et observe chaque demande.

Une construction suggérée applique HMAC à l’identifiant interne et à l’audience. Elle évite une table, mais crée une dette de clés : rotation, conservation des anciennes clés, séparation des accès et durée d’audit. Si la clé et l’état interne fuient ensemble, la corrélation inter-ressources réapparaît. Le centre de décision devient aussi le centre d’observation.

Le rejeu ne disparaît pas avec l’horloge. Un Txn-AT bearer peut être réutilisé pendant sa durée de vie. Le draft accepte ce risque pour garder les resource servers sans état, recommande DPoP ou mutual TLS et permet de mémoriser jti quand l’usage unique compte. Il n’impose pas ce registre. Cinq minutes permettent plusieurs paiements, suppressions ou changements non idempotents.

txn n’est pas non plus un identifiant métier universel. Il ne dit pas si deux requêtes HTTP doivent produire un seul effet. Il ne résout pas le commit partiel quand une transaction touche plusieurs ressources. Il faut encore un identifiant de requête applicatif, une politique de doublon, un reçu d’exécution et une compensation.

Les essais négatifs comptent davantage que la démonstration nominale. Une route Txn-AT doit rejeter at+jwt; une charge interne doit rejeter le Txn-AT externe à la place de txntoken+jwt; une audience multiple doit échouer; un handle expiré ou lié à un autre sujet doit échouer. La métadonnée d’enregistrement ne prouve pas que chaque route applique réellement la règle.

La couche commune peut rester mince : type exact, audience, provenance et contexte évalué sont portables. Le jugement du serveur d’autorisation ne devient pas une vérité globale, et la réception du token ne devient pas un résultat. La décision locale garde sa valeur si elle demeure vérifiable, remplaçable et séparée de l’effet.

Sources