Passer au contenu principal
Pour utiliser les fonctionnalités Highly Regulated Identity, vous devez disposer d’un forfait Enterprise avec le module complémentaire Highly Regulated Identity. Consultez Auth0 Pricing pour en savoir plus.
La fonctionnalité Pushed Authorization Request (PAR) est un protocole côté serveur qui permet d’acheminer directement les requêtes d’autorisation vers le . Il s’agit d’un composant technique du profil de sécurité Financial-Grade API (FAPI) 1.0, conçu pour protéger les API dans des contextes à haute valeur.

​
Fonctionnement

PAR permet à votre application de transmettre directement au point de terminaison PAR du serveur d’autorisation (1) les paramètres des requêtes d’autorisation . En réponse, le serveur d’autorisation renvoie une valeur d’URI de requête, request_uri (2), à utiliser lorsque vous appelez le point de terminaison /authorize (3). Le request_uri est une référence aux requêtes d’autorisation stockées au point de terminaison /par, de sorte qu’elles ne sont pas exposées (4). Pour en savoir plus, consultez Configurer les requêtes d’autorisation poussées.

​
Avantages

L’un des avantages de PAR est la validation précoce. Dans d’autres flux OAuth 2.0, comme le flux de code d’autorisation, les utilisateurs finaux sont redirigés vers le serveur d’autorisation pour la validation. Avec PAR, les paramètres de la requête sont validés dès le début de la requête d’autorisation, avant que l’utilisateur final soit redirigé. Il n’est pas souhaitable de rediriger les utilisateurs uniquement pour leur afficher une page d’erreur. PAR transmet également les requêtes d’autorisation par le back-channel. Les communications en front-channel reposent sur un intermédiaire (p. ex. un navigateur) au moyen de paramètres de requête HTTPS ajoutés (GET, POST). Les messages ne sont pas envoyés directement. Les communications en back-channel sont transmises dans le corps d’une requête backend authentifiée, pour une approche plus directe. Les requêtes d’autorisation poussées transitent par le back-channel, ce qui signifie :
  • Le serveur d’autorisation peut se fier à la provenance de la requête, et les requêtes n’ont pas été modifiées par un utilisateur final.
  • Les détails de la requête ne sont pas exposés dans la barre d’adresse du navigateur ni dans l’historique, ce qui préserve la confidentialité à cette étape du processus.
  • Les restrictions liées à la longueur des URL ne posent pas de contrainte.

​
Limitations

  • La taille maximale du payload de la requête est de 10 KB.
  • Les applications publiques ne sont pas prises en charge pour le moment. Pour en savoir plus, consultez Public and Confidential Applications.

​
Appelez le point de terminaison PAR

​
Exigences

Pour appeler le point de terminaison PAR, vous devez :
  • Définir le type de contenu de la requête à application/x-www-form-urlencoded.
  • Utiliser des chaînes pour tous les paramètres transmis.
  • Inclure dans la requête un paramètre supplémentaire pour la méthode d’authentification de l’application. Seules les prennent en charge PAR; les méthodes d’authentification de l’application suivantes sont donc disponibles : , à clé privée et mTLS. Vous devez utiliser la même méthode d’authentification de l’application pour le point de terminaison /token lorsque vous récupérez un .

​
Paramètres pris en charge

Le point de terminaison PAR stocke et traite uniquement :
  • Les paramètres OAuth 2.0 standard et les extensions applicables, reconnus au point de terminaison d’autorisation.
  • Jusqu’à 10 paramètres d’autorisation personnalisés préfixés par ext-.
PAR ignore les paramètres d’autorisation personnalisés additionnels. Les paramètres d’autorisation personnalisés ne sont pas disponibles dans Auth0 Actions ni dans les journaux.
Si vous utilisez des paramètres d’autorisation personnalisés dans Actions, vous devez les préfixer par ext-. Sinon, ils ne seront pas disponibles.

​
Exemple de requête PAR

curl --location --request POST https://$tenant/oauth/par \
  -H "content-type: application/x-www-form-urlencoded" \
  -d "client_id=CLIENT_ID"\
"&client_secret=CLIENT_SECRET"\
"&redirect_uri=https://jwt.io"\
"&audience=urn:my-notes-api"\
"&scope=openid%20profile%20read:notes"\
"&response_type=code"

​
Exemple de réponse PAR

Dans l’exemple de réponse PAR suivant :
  • Le request_uri est une référence aux requêtes d’autorisation stockées. Les valeurs de la requête sont transmises au point de terminaison GET /authorize sous forme de paramètre request_uri.
  • Le expires_in correspond au nombre de secondes pendant lesquelles le request_uri est valide. Passé ce délai, le request_uri expire s’il n’est pas utilisé. La durée d’expiration de trente secondes est une valeur statique et ne peut pas être configurée.
HTTP/1.1 201 Created
 Content-Type: application/json

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

​
Limites de débit

Pour les locataires de production Essential, Professional et Enterprise, les appels au point de terminaison PAR sont inclus dans la limite de débit standard de l’Authentication API. Pour en savoir plus, consultez Configurations des limites de débit, puis cliquez sur votre type d’abonnement. Cliquez ensuite sur Authentication API.

​
Appeler le point de terminaison d’autorisation

Votre application utilise la valeur request_uri renvoyée par le point de terminaison /oauth/par dans la requête d’autorisation et redirige l’agent utilisateur vers le point de terminaison d’autorisation. Pour en savoir plus sur le paramètre request_uri, consultez Configurer les requêtes d’autorisation poussées. L’exemple suivant redirige l’agent utilisateur pour qu’il effectue la requête HTTP suivante : 
GET /authorize?client_id=CLIENT_ID&request_uri=urn%3Aietf%3Aparam...qrwSI HTTP/1.1 Host: TENANT.auth0.com
Si request_uri est valide, le reste du est le même.

​
Validation

  • PAR est de nouveau validé par le serveur d’autorisation à cette étape, comme toute autre demande d’autorisation.
  • La valeur request_uri ne peut être utilisée qu’une seule fois.
  • Un request_uri expiré sera rejeté par le serveur d’autorisation.
  • Une demande sans PAR est rejetée si PAR est requis au niveau du locataire ou de l’application.

​
En savoir plus