Résumé

  • La révision 04 d’OAuth for First-Party Applications introduit un point de terminaison HTTPS capable de rendre un code, de demander au client natif une nouvelle donnée utilisateur ou d’imposer un retour au navigateur. Le client installé, sa preuve d’éditeur, son interface et sa discipline de repli deviennent alors des éléments du périmètre de confiance.
  • auth_session, PKCE et DPoP peuvent relier une suite d’échanges à une instance et à une clé. Ils ne démontrent ni que le binaire est réellement de première partie, ni que l’utilisateur a vu le bon défi, ni que les applications sœurs présentent les mêmes repères, ni que l’opération finale a eu lieu.

L’application bancaire a demandé un code à usage unique, l’a transmis au serveur d’autorisation puis a reçu un code d’autorisation. L’utilisateur n’a jamais changé de fenêtre. L’expérience est plus fluide, mais l’autorité de présentation a changé de mains.

Le projet OAuth 2.0 for First-Party Applications définit l’Authorization Challenge Endpoint. Le client peut envoyer un identifiant, un défi passkey signé, un code MFA ou une donnée propre au déploiement. Le serveur peut délivrer le code, répondre insufficient_authorization pour poursuivre l’échange, ou renvoyer redirect_to_web afin de reprendre la main dans un navigateur.

La révision 04, datée du 1er juillet 2026 et expirant le 2 janvier 2027, est un Internet-Draft actif du groupe OAuth, prévu pour Standards Track. Ce n’est pas un RFC. Les sources ne prouvent ni inscription IANA achevée, ni interopérabilité, ni déploiement, ni couverture d’attestation des boutiques, ni baisse du phishing, ni résultat métier.

Une API native déplace la surface de présentation

Dans le code flow traditionnel, le serveur d’autorisation contrôle la page où les secrets sont saisis. Ici, un client de confiance maîtrise une partie de la cérémonie. Il POSTe les paramètres OAuth et peut joindre ce qu’il vient de recueillir. Les extensions sont admises, même si certains paramètres propres au Web n’ont pas de sens évident dans un échange natif.

Le serveur décide toujours si l’information suffit à délivrer un code. Le client peut cependant choisir la représentation de l’invite, le composant qui lit l’entrée, le vocabulaire de l’erreur et les endpoints propriétaires des étapes intermédiaires. Or le format de ces étapes, les schémas de défi et leur ordre sont hors du champ de la révision 04. Des profils de déploiement restent nécessaires pour obtenir une solution interopérable.

Le reçu doit donc conserver le contrat d’interface : build, instance installée, profil de défi, classe d’entrée sans valeur secrète, scopes, version de politique, réponse et instruction suivante. Un code valide atteste que le serveur a produit un artefact de grant ; il ne reconstitue pas ce que la personne a vu.

La première partie est une relation, pas un paramètre

Le texte exige que le serveur vérifie la « first-partyness » avant de continuer. L’application doit être contrôlée par la même entité que le serveur et reconnue par l’utilisateur comme appartenant à cette entité. Le mécanisme exact de cette vérification est laissé hors spécification.

Une attestation de plateforme peut identifier un logiciel, une clé, un signataire ou une origine de distribution. Attestation-Based Client Authentication et Dynamic Client Registration peuvent compléter la preuve. Mais aucun objet ne fusionne contrôle de l’entreprise, garde de la distribution, intégrité du binaire installé, possession de clé et reconnaissance de marque.

Un package authentique peut être ancien ou compromis. Une application bien signée peut afficher une invite trompeuse. Une clé DPoP valide peut appartenir à une instance clonée si l’enrôlement n’a pas fixé sa granularité. Une apparence familière peut être imitée.

Il faut donc préserver l’émetteur de l’attestation, sa fraîcheur, son nonce, le publisher, le canal de distribution, l’instance et la décision de politique séparément de client_id, auth_session et du code. « Première partie vérifiée » est une conclusion dépendante, non une propriété auto-authentifiée.

auth_session est un cookie dont l’application assure le portage

auth_session est opaque au client et associe les requêtes d’une même instance. Comme un cookie, il référence un état détenu par le serveur ; à la différence du navigateur, l’application doit l’enregistrer et le renvoyer elle-même. Une réponse peut le remplacer. Le client doit accepter la rotation, le conserver après émission du code et l’effacer à la déconnexion.

Le serveur doit assurer l’unicité ; un aléa devrait offrir au moins 256 bits d’entropie. Il devrait lier la session au terminal et refuser une autre provenance. La spécification ne fixe aucune durée : expiration, événement de sécurité ou révocation peuvent l’invalider, et l’application ne doit pas compter sur une longévité donnée.

Le suivi doit représenter une machine d’état : génération, prédécesseur, instance, contexte utilisateur, clé DPoP, étape, rotation, déconnexion et terminaison. La valeur opaque elle-même ne doit pas contaminer les journaux usuels.

Une session acceptée prouve seulement que le serveur accepte de poursuivre un contexte. Elle ne prouve pas l’honnêteté des écrans précédents, l’identité continue de la personne ni l’actualité de la confiance dans le build.

DPoP maintient une clé, pas une provenance ni une interface

La révision 04 décrit DPoP pour contraindre code et jetons, ainsi que pour protéger auth_session. Le serveur peut imposer la même clé publique depuis la première requête jusqu’au token endpoint et vérifier la possession de la clé privée à chaque présentation de session.

Cette chaîne limite le rejeu d’une session ou d’un code volé depuis un autre terminal. Elle ne dit pas qui a autorisé l’enrôlement de la clé, quel package dessine l’écran, si l’instance reste saine, si le serveur accepte encore l’éditeur ou si l’utilisateur voulait ce scope.

Il faut rendre visibles des états séparés : correspondance DPoP, attestation acceptée, registration active, politique de première partie, profil d’invite et autorisation utilisateur. Les condenser en « client lié » détruit l’explication utile lors d’un incident.

Le retour au Web est une transition de sécurité

redirect_to_web permet au serveur de reprendre la présentation pour un risque élevé, une méthode absente du client, une récupération de compte ou une exception. L’application démarre alors un nouveau code flow dans un external user agent. La réponse peut contenir un request_uri de PAR.

Si la requête native initiale ne contenait pas de PKCE code_challenge, le serveur ne doit pas renvoyer ce request_uri. Le repli doit aussi respecter les règles pour applications natives, l’identification d’issuer et les recommandations OAuth actuelles.

Il faut journaliser le déclencheur, le niveau de risque, la présence de PKCE, l’issuer, la référence de requête, le navigateur externe, l’URI de retour, la continuité de state et le résultat du callback. Ouvrir une fenêtre ne prouve pas qu’elle vise le bon serveur ; rester en natif ne prouve pas que le repli était inutile.

Transformer silencieusement redirect_to_web en nouvel essai natif, ou utiliser une webview intégrée qui imite le navigateur externe, franchit une frontière de politique. Le test doit suivre la transition jusqu’au callback lié à l’issuer.

Plusieurs applications reproduisent la décision de confiance

Lorsque plusieurs applications de première partie existent, le projet exige une expérience native identique. L’enjeu dépasse la marque : multiplier les formes de saisie légitimes entraîne l’utilisateur à accepter davantage de faux possibles. Chaque implémentation ajoute aussi son parser, son stockage, son accessibilité, sa version de SDK et ses failles.

Un SDK commun réduit la divergence mais devient une dépendance partagée. Sa signature, son déploiement et son retrait d’urgence font partie du contrôle. L’identité de l’expérience doit couvrir les messages, indices d’origine, traitement des secrets, captures d’écran, accessibilité, erreurs, repli, stockage de session et redaction des traces, pas seulement les couleurs.

Le serveur doit relier chaque client et politique d’attestation à une entité, un publisher, un canal, des builds, un SDK, un profil et un plan de retrait. Une application sœur moins sûre ne doit pas hériter du niveau de confiance de la famille.

Le code natif n’est pas encore l’effet

Le code, PKCE, DPoP, auth_session, step-up et access token ont des sens distincts. Le code porte le grant ; PKCE le relie à un verifier ; DPoP relie les échanges à une clé ; la session pointe un contexte ; les paramètres step-up expriment une exigence ; le jeton transporte une autorisation que le resource server doit encore appliquer.

Aucun ne prouve le résultat externe. La ressource peut refuser, réduire la permission ou accepter sans terminer l’action en aval. L’utilisateur peut fermer l’application, une opération peut être annulée, un credential émis peut ne jamais être installé. Le reçu final vient après OAuth : décision de la ressource et conséquence observée.