Flux de code d’autorisation avec des requêtes d’autorisation poussées (PAR)

Découvrez comment utiliser les requêtes d’autorisation poussées (PAR) avec le flux de code d’autorisation.

Pour utiliser les fonctionnalités de Highly Regulated Identity, vous devez avoir un Enterprise Plan avec l’add-on Highly Regulated Identity. Consultez Auth0 Pricing pour en savoir plus.

Une requête d’autorisation poussée (PAR) est un protocole côté serveur qui permet d’envoyer des requêtes d’autorisation directement au serveur d’autorisation. 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 scénarios à enjeux élevés.

​

Fonctionnement

PAR permet à votre application d’envoyer directement au point de terminaison PAR du serveur d’autorisation les paramètres des requêtes d’autorisation OAuth 2.0 (1). En réponse, le serveur d’autorisation renvoie une valeur 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 que ces requêtes 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 en amont. 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 requête sont validés dès le début de la requête d’autorisation, avant la redirection de l’utilisateur final. Il n’est pas souhaitable de rediriger les utilisateurs seulement pour leur afficher une page d’erreur.

PAR transmet aussi les requêtes d’autorisation par le canal arrière. Les communications en canal frontal 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 canal arrière 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 canal arrière, 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 du navigateur ni dans l’historique, ce qui préserve la confidentialité à cette étape du processus.
• Les limites de longueur des URL ne constituent pas une contrainte.

​

Limitations

• La taille maximale de la charge utile de la requête est de 10 Ko.
• Les applications publiques ne sont pas prises en charge pour le moment. Pour en savoir plus, consultez Applications publiques et confidentielles.

​

Effectuer une requête vers le point de terminaison PAR

​

Exigences

Pour faire une requête au point de terminaison PAR, vous devez :

• Définir le type de contenu de la requête sur application/x-www-form-urlencoded.
• Utiliser des chaînes de caractères 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. Seuls les clients confidentiels prennent en charge PAR; les méthodes d’authentification de l’application suivantes sont donc offertes : Secret client, clé privée JWT 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 jeton d’accès.

​

Paramètres pris en charge

Le point de terminaison PAR stocke et traite uniquement ce qui suit :

• 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écédés du préfixe ext-.

PAR ignore les paramètres d’autorisation personnalisés additionnels. Les paramètres d’autorisation personnalisés ne sont pas disponibles dans les Auth0 Actions et les Logs.

Si vous utilisez des paramètres d’autorisation personnalisés dans Actions, vous devez les faire précéder de 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 au moyen du paramètre request_uri.
• Le expires_in correspond au nombre de secondes pendant lesquelles le request_uri est valide. Après ce délai, le request_uri expire s’il n’est pas utilisé. Le délai d’expiration de trente secondes est une valeur statique et ne peut pas être configuré.

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 tenants 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 Rate Limit Configurations, puis cliquez sur votre type d’abonnement. Ensuite, cliquez 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, puis 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 amène l’agent utilisateur à effectuer la requête HTTP suivante :

GET /authorize?client_id=CLIENT_ID&request_uri=urn%3Aietf%3Aparam...qrwSI HTTP/1.1 Host: TENANT.auth0.com

Dans le cas d’un request_uri valide, le reste du flux d’autorisation se déroule de la même façon.

​

Validation

• PAR est de nouveau validé par le serveur d’autorisation à cette étape, comme toute autre requête d’autorisation.
• La valeur request_uri ne peut être utilisée qu’une seule fois.
• Une valeur request_uri expirée sera rejetée par le serveur d’autorisation.
• Une requête non PAR est rejetée si PAR est exigé au niveau du tenant ou du client.

​

Pour en savoir plus

• Configurer les requêtes d’autorisation poussées (PAR)