Qu'est-ce que PAR (Pushed Authorization Requests) ?

PAR en bref#

Dans OAuth 2.0 et OpenID Connect, la demande d’autorisation voyage dans l’URL du navigateur : identifiant du client, adresse de retour, scopes, state, code_challenge, parfois des demandes de claims détaillées. Tout cela passe entre les mains de l’utilisateur, de ses extensions de navigateur et des journaux intermédiaires.

PAR (Pushed Authorization Requests) change l’ordre des opérations. L’application commence par pousser sa demande au serveur d’autorisation, directement, de serveur à serveur. Le serveur la vérifie, la conserve et répond par une référence courte, le request_uri. Le navigateur ne transporte plus que cette référence.

Ce que PAR résout#

Une demande d’autorisation classique présente plusieurs faiblesses, toutes liées au fait qu’elle transite par le navigateur :

• Elle n’est ni authentifiée ni protégée en intégrité. N’importe qui peut fabriquer une URL /authorize au nom d’un client, ou modifier un paramètre en route. Le serveur ne découvre qui est vraiment le client qu’au moment de l’échange du code.
• Elle est visible. Les paramètres apparaissent dans l’historique, les journaux des proxys et les en-têtes Referer. Ce peut être gênant quand la demande contient des informations personnelles.
• Elle est limitée en taille. Les demandes riches (claims détaillés, request objects signés) produisent des URL trop longues pour certains navigateurs ou équipements réseau.
• Les erreurs arrivent tard. Une demande mal formée n’est détectée qu’une fois l’utilisateur redirigé, ce qui complique le diagnostic.

Avec PAR, le client s’authentifie en poussant la demande, avec la même méthode qu’à l’endpoint de jeton. Le serveur sait donc, avant même que l’utilisateur n’arrive, que la demande vient bien de ce client et qu’elle n’a pas été modifiée.

Comment ça marche#

La requête poussée contient exactement les paramètres qu’aurait portés l’URL, envoyés en formulaire :

POST /tosiam/oauth2/clients/par HTTP/1.1
Host: login.example.fr
Content-Type: application/x-www-form-urlencoded
Authorization: Basic bm90ZXMtZGUtZnJhaXM6Li4u

response_type=code
&redirect_uri=https%3A%2F%2Fapp.example.fr%2Fcallback
&scope=openid%20profile
&state=af0ifjsldkj
&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
&code_challenge_method=S256

Le serveur répond par une référence et sa durée de vie en secondes :

{
  "request_uri": "urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc014ltc14eY22c",
  "expires_in": 120
}

L’application redirige ensuite le navigateur vers une URL devenue très courte :

https://login.example.fr/tosiam/oauth2/clients/authorize?client_id=notes-de-frais&request_uri=urn%3Aietf%3Aparams%3Aoauth%3Arequest_uri%3A6esc_11ACC5bwc014ltc14eY22c

La suite est inchangée : authentification de l’utilisateur, consentement, retour avec un code, échange du code contre des jetons.

Les points clés de la norme#

• Le request_uri est éphémère. RFC 9126 laisse sa durée de vie au serveur, en citant une plage typique de 5 à 600 secondes. Il ne sert qu’à relayer une redirection.
• Il est à usage unique. Le client ne doit l’utiliser qu’une fois ; le serveur devrait le considérer comme consommé après usage.
• Il est lié au client. Le client_id de la redirection doit être celui du client qui a poussé la demande.
• PAR se combine avec les request objects. La demande poussée peut elle-même contenir un JWT signé (paramètre request, RFC 9101), pour les contextes qui exigent une preuve d’intégrité de bout en bout.
• PAR peut devenir obligatoire. La norme définit la métadonnée require_pushed_authorization_requests, côté serveur et côté client, pour refuser toute demande qui n’est pas passée par PAR. Les profils de sécurité comme FAPI 2.0 l’imposent.

Bonnes pratiques#

• Utilisez PAR pour les applications confidentielles qui manipulent des données sensibles : il ne coûte qu’un appel serveur supplémentaire.
• Continuez d’envoyer state et PKCE dans la demande poussée : PAR protège le transport de la demande, pas le retour du code.
• Redirigez l’utilisateur dès la réception du request_uri, sans le mettre en cache.
• Gérez l’erreur d’une référence expirée en relançant une nouvelle demande poussée, plutôt qu’en réessayant l’ancienne.

PAR dans TOSIAM#

TOSIAM expose l’endpoint PAR dans chaque royaume où le service OAuth2 Provider est actif, à l’adresse de l’émetteur suivie de /par, par exemple https://login.example.fr/tosiam/oauth2/clients/par. Le document de découverte l’annonce dans pushed_authorization_request_endpoint.

À la réception. TOSIAM authentifie un client confidentiel avec la méthode déclarée dans sa fiche (secret, private_key_jwt ou certificat mTLS) et refuse la demande si un client_id transmis ne correspond pas au client authentifié. Il exige response_type et redirect_uri, puis applique les mêmes contrôles qu’à l’endpoint d’autorisation, scopes compris. Une demande invalide est donc rejetée avant toute redirection.

Les paramètres retenus. TOSIAM conserve une liste fermée de paramètres : response_type, redirect_uri, scope, state, nonce, prompt, max_age, ui_locales, acr_values, code_challenge, code_challenge_method, claims et request. La demande est stockée dans le Core Token Store sous une référence de la forme urn:ietf:params:oauth:request_uri: suivie d’un identifiant aléatoire.

La durée de vie. Le réglage « Durée de vie des demandes d’autorisation poussées » du fournisseur fixe la validité du request_uri, 120 secondes par défaut.

À l’autorisation. Quand /authorize reçoit un request_uri, TOSIAM recharge la demande, refuse une référence expirée ou inconnue, vérifie que le client_id est celui du client qui l’a poussée, et rejette tout paramètre de l’URL dont la valeur contredit celle de la demande poussée. La référence est supprimée dès que l’autorisation aboutit : elle ne peut pas resservir.

L’usage de PAR reste au choix de l’application : les demandes d’autorisation classiques restent acceptées.

Pour aller plus loin#

• RFC 9126, OAuth 2.0 Pushed Authorization Requests
• RFC 9101, JWT-Secured Authorization Request (JAR)
• RFC 6749, The OAuth 2.0 Authorization Framework