Résumé

  • RFC9470 permet à une ressource de demander une authentification plus forte ou plus récente. La date d’émission du jeton n’est pas la date de l’événement d’authentification ; renouveler les titres issus d’une même réponse d’autorisation ne renouvelle pas cette preuve.
  • La demande et son résultat doivent rester distincts. Pour les jetons d’accès, l’extension recommande de satisfaire le contexte demandé ou de renvoyer un échec explicite, plutôt que de fournir à répétition des jetons toujours insuffisants.
  • Validation du titre, âge et contexte de l’authentification, portée des droits et exécution de l’opération répondent à des questions différentes. Leur contrat commun n’impose ni une approbation centrale de chaque acte ni une redéfinition d’OAuth comme protocole d’authentification.

Les compteurs peuvent annoncer la mauvaise réussite

Dans un scénario hypothétique, un exploitant voit ses renouvellements de jetons fonctionner sans interruption. La ressource protégée réclame pourtant une authentification active récente. Les nouveaux jetons proviennent d’une réponse d’autorisation antérieure, sans nouvel événement utilisateur. Le compteur de délivrance dit vrai : des titres ont été émis. Mais il n’établit pas la condition qui intéresse la ressource.

Ce n’est pas un défaut constaté dans un produit par cette enquête. C’est une manière de séparer deux événements avant de les réunir sous le mot « frais ». Un titre d’accès peut être récent comme titre et rester lié à une authentification plus ancienne. Inversement, une condition peut déjà être satisfaite sans demander une interaction nouvelle à chaque opération. Il faut connaître le critère applicable et la preuve réelle, non décréter un renouvellement universel des gestes de l’utilisateur.

Publié en septembre 2023, RFC9470 décrit le protocole OAuth de défi d’authentification renforcée. Il permet de communiquer que l’événement associé au jeton ne répond pas à une exigence de force ou de caractère récent. Il ne décrit pas lui-même la mécanique de l’authentification. Le texte dépend d’une couche séparée et interdit expressément de s’en servir pour présenter OAuth comme un protocole d’authentification.

Cette précision évite un déplacement de responsabilité par le vocabulaire. Une nouvelle demande d’autorisation ne signifie pas nécessairement une nouvelle connexion de l’utilisateur. Un jeton obtenu n’est pas encore la preuve du niveau demandé. Et l’acceptation d’une condition d’authentification ne démontre pas à elle seule que l’opération a été autorisée puis exécutée. Chacune de ces réussites a son objet.

Le champ iat d’un JWT désigne, dans RFC7519, sa date d’émission et peut servir à déterminer son âge. Il ne désigne pas le dernier moment où l’utilisateur s’est activement authentifié. Sa présence générique est facultative ; un profil peut imposer ses propres exigences. Dans tous les cas, une date d’émission valide ne remplace pas une date d’authentification absente.

RFC9068 permet des informations d’authentification, dont auth_time, acr et amr, dans les autorisations concernées. Leurs valeurs restent fixes pour les jetons dérivés d’une même réponse d’autorisation, y compris par renouvellement ou échange. RFC9470 rappelle cette distinction pour auth_time et acr. Il faut conserver la réserve sur l’origine commune : une authentification utilisateur effectivement nouvelle apporte une autre preuve. Le texte ne démontre pas que tout renouvellement imaginable exclut toute authentification.

Le contrat doit donc permettre de reconnaître l’événement, pas seulement la dernière production de titre. Une automatisation peut prolonger la disponibilité du service ; elle n’acquiert pas pour autant le pouvoir de remettre à zéro l’âge d’un événement qui n’a pas eu lieu de nouveau. C’est une limite à la signification du succès annoncé, non une condamnation des renouvellements.

Ce que demande la ressource

Le code insufficient_user_authentication porte sur les exigences d’authentification de la ressource. Ce diagnostic n’est pas interchangeable avec une expiration du jeton ou une portée de droits insuffisante. RFC9470 permet de préciser acr_values, une liste de classes de contexte acceptables par ordre de préférence, et max_age, le temps écoulé admis depuis l’authentification active. Les deux peuvent être présents ; une portée scope peut aussi être indiquée selon les règles Bearer lorsqu’elle manque.

Une classe de contexte ne vaut pas une méthode simplement parce qu’elle a un nom. OpenID Connect Core exige un accord sur le sens des valeurs, parfois propre au contexte. Le champ commun ne rend pas universellement portable la promesse d’assurance d’un fournisseur. La ressource doit savoir ce qu’elle accepte, et le service d’autorisation ce qui permet de satisfaire cette signification.

max_age exprime un nombre entier non négatif de secondes depuis l’événement actif, et non depuis le dernier jeton délivré. Contrôler seulement l’émission la plus récente ne permet donc pas d’établir cette durée. Cela ne prouve pas une faille déployée : cela précise l’élément nécessaire avant de promettre une authentification assez récente.

Le client devrait reprendre les paramètres présents dans sa demande d’autorisation. Leur transport est un progrès de coordination, pas un résultat d’authentification. Entre la formulation d’une exigence et la satisfaction de cette exigence, il reste une réponse à examiner. Une redirection suivie d’un jeton ne fait pas disparaître cette étape.

Un échec clair peut être la bonne réponse

Dans OpenID Connect Core, acr_values demande un attribut volontaire. Le traitement du contexte dans un ID Token n’équivaut pas à une garantie inconditionnelle que tout niveau souhaité sera atteint. Les règles de max_age imposent aussi une tentative de réauthentification active lorsque la durée admise est dépassée, et auth_time dans le jeton d’identité retourné. Elles ne constituent pas une preuve des champs de n’importe quel jeton d’accès envoyé à une ressource.

RFC9470 décrit précisément le comportement des jetons d’accès pour les serveurs conformes à son extension. Les informations acr et auth_time accompagnent la réponse aux paramètres correspondants. Il recommande surtout de considérer le contexte acr demandé comme nécessaire au succès : le satisfaire, ou échouer avec unmet_authentication_requirements. Renvoyer sans cesse un titre incapable de répondre à la ressource maintiendrait le client dans une boucle au lieu de produire un résultat utilisable.

Il faut respecter les deux limites de cette recommandation. Dire qu’il ne s’agit que d’une préférence toujours négligeable affaiblit le comportement conseillé par l’extension. Dire que tout défi garantit une authentification renforcée réussie l’exagère. Lorsque la condition ne peut pas être remplie, l’échec explicite peut être l’issue appropriée. Le nom de l’erreur OpenID fournit alors une information, non de nouveaux droits ni la preuve d’une opération effectuée.

Dans une expérience hypothétique, une boucle pourrait venir d’un contexte inaccessible, d’un âge non conforme ou d’une exigence que les deux services n’interprètent pas de la même manière. Aucun de ces cas n’a été observé ici chez un fournisseur. Ils montrent pourquoi la date du nouveau jeton ne permet pas de localiser le désaccord. Le couple de politiques doit préciser ses possibilités et ses issues terminales, pas seulement encourager une nouvelle tentative.

La gestion de l’échec est ainsi une question de responsabilité, pas uniquement de confort. Un résultat correctement négatif garde visible une condition non atteinte. Une délivrance techniquement réussie peut au contraire masquer le fait que la ressource refusera encore le titre. Le tableau de bord du service d’autorisation et celui de l’opération protégée peuvent donc raconter des réussites différentes.

Deux chemins de preuve, pas un modèle obligatoire

RFC9470 explique comment communiquer l’événement avec deux méthodes courantes : un jeton d’accès JWT validé selon son profil, ou une réponse d’introspection OAuth. D’autres encodages et validations restent possibles, mais hors de son champ. La ressource a besoin d’accéder à l’information pertinente ; le texte ne lui impose pas une seule architecture universelle.

Lire auth_time et acr dans un JWT ne dispense pas de valider le titre. Le contrat applicable reste déterminant pour l’émetteur, l’audience et les autres contrôles, puis pour le sens des informations d’authentification. Une valeur dans une entrée non fiable n’est pas devenue une preuve parce que son champ porte le bon nom. Cette distinction est conceptuelle ; elle n’est pas l’audit de sécurité d’une mise en œuvre particulière.

Avec l’introspection, active:true décrit un état du titre, pas la satisfaction de toutes les politiques. L’événement associé peut être trop ancien ou appartenir à un contexte refusé. RFC7662 organise l’accès à l’état et aux métadonnées ; RFC9470 ajoute des membres relatifs à l’authentification. Leur présence et leur interprétation comptent séparément du simple état actif.

L’introspection ne devient donc pas une obligation de consulter un centre en ligne pour chaque opération. Le JWT ne rend pas non plus une validation hors ligne suffisante dans tous les cas. Le déploiement choisit son chemin de preuve selon ses responsabilités et les autres conditions applicables. Un contrat partagé peut décrire ce qui circule sans choisir une manière unique de faire fonctionner toutes les ressources.

Les métadonnées du serveur d’autorisation fournissent un troisième signal, plus limité. acr_values_supported annonce, selon RFC9470, la compréhension et le respect des paramètres concernés. Ce renseignement de capacité ne décrit pas un événement utilisateur précis, son âge réel ou l’exécution de l’action. Catalogue de possibilités, preuve d’événement et résultat d’opération sont trois objets, même si le fournisseur les expose ensemble.

La condition d’authentification n’est pas l’autorisation entière

Les règles de renouvellement OAuth ne permettent pas de demander une portée dépassant celle de l’octroi initial ; sans nouvelle valeur scope, cette portée est conservée. L’authentification du client au point de terminaison des jetons n’est pas non plus celle de l’utilisateur final. Une transaction automatisée ne démontre donc ni une présence utilisateur récente ni un élargissement de ses permissions.

Une ressource peut faire de la qualité de l’authentification une condition d’accès sans en faire la décision complète. Validité, audience, portée, contexte et âge peuvent intervenir selon le contrat. La satisfaction de l’un ne crée pas les autres. Et une décision d’accès correcte n’est toujours pas un constat que l’action a réussi. L’objet de chaque preuve doit rester nommé.

RFC9470 laisse les contraintes sur les politiques du couple ressource/serveur d’autorisation hors de son champ. Des exigences impossibles à remplir ou pénibles pour l’utilisateur sont donc possibles. Les moyens de les satisfaire, par exemple des appareils particuliers, ne sont pas définis par le simple identifiant de la condition. Un échange bien formé ne rend pas toutes les politiques compatibles.

Le défi ne prouve même pas que le jeton présenté a déjà été validé. Le texte permet la logique de défi avant ou après la validation habituelle et autorise une réponse sans vérification préalable d’un titre valide. Il souligne alors la divulgation de propriétés exigées à un acteur qui n’a pas démontré pouvoir obtenir ce titre. L’ordre choisi a des conséquences ; ce n’est pas une règle universelle supplémentaire imposée ici.

Les valeurs de contexte peuvent révéler des indices sur un utilisateur privilégié ou d’autres éléments ciblables. Le mécanisme peut aussi déclencher une interaction utilisateur et être abusé par une ressource malveillante. Aucune attaque ni personne affectée n’a été constatée dans cette recherche. La source décrit une possibilité et appelle à la prudence ; elle n’établit pas sa fréquence réelle.

RFC9700 apporte le contexte de sécurité OAuth actualisé, non une nouvelle date d’événement. La rotation des titres de renouvellement ou une meilleure protection des jetons répondent à des problèmes propres. Elles ne signifient pas automatiquement que l’utilisateur vient de s’authentifier. Des contrôles utiles peuvent se compléter sans devenir des preuves interchangeables.

Les principes de Lu Heng — spécification initiale minimale, décisions futures localisées, adoption volontaire — offrent un repère éditorial. La couche commune rend la demande et l’événement intelligibles. Le couple concerné explique ses conditions d’opération et leur faisabilité. Les adoptants choisissent sur cette base. Il n’est pas nécessaire d’ajouter une institution qui approuve chaque acte ; il reste nécessaire de rendre les responsabilités locales vérifiables.

Un jeton récent peut participer à une décision solide. Il ne doit pas, à lui seul, tenir lieu d’événement récent, de condition satisfaite et d’action accomplie. Garder ces différences visibles permet au protocole commun de faciliter la coordination sans attribuer à l’horloge de délivrance une autorité qu’elle n’a jamais reçue.

Sources