Flux de code d’autorisation avec les demandes d’autorisation poussées

Apprenez à utiliser les demandes d’autorisation poussées avec le flux de code d’autorisation.

Pour utiliser les fonctionnalités de l’identité très réglementée (HRI), vous devez disposer d’un plan Enterprise avec le module complémentaire Identité très réglementée. Consultez Tarification Auth0 pour plus de détails.

La Pushed Authorization Request (PAR) (Demande d’autorisation poussée) est un protocole du système dorsal permettant de pousser les demandes d’autorisation directement vers le serveur d’autorisation. Il s’agit d’un élément technique du Financial-Grade API (FAPI) Security Profile 1.0 (Profil de sécurité 1.0 de l’API de grade financier) chargé de protéger les API par lesquels transigent des actifs de grande valeur.

​

Fonctionnement

La demande PAR permet à votre application d’envoyer les paramètres des demandes d’autorisation OAuth 2.0 directement au point de terminaison PAR du serveur d’autorisation (1). En réponse, le serveur d’autorisation envoie une valeur d’URI de demande, request_uri (2), à utiliser lorsque vous appelez le point de terminaison /authorize(3). Le request_uri est une référence aux demandes d’autorisation stockées au point de terminaison /par, de sorte que ces demandes ne sont pas exposées (4). Pour en savoir plus, lisez Configurer les demandes d’autorisation Push.

​

Avantages

L’un des avantages de l’utilisation de la demande PAR est la validation précoce. Dans d’autres flux OAuth 2.0, tels que le Flux de code d’autorisation, les utilisateurs finaux sont redirigés vers le serveur d’autorisation pour validation. Dans la demande PAR, les paramètres de la demande sont validés au début de la demande d’autorisation avant que l’utilisateur final ne soit redirigé. Il n’est pas idéal de rediriger les utilisateurs pour leur montrer une page d’erreur.

La demande PAR transmet également les demandes d’autorisation sur le canal dorsal. Les communications sur le canal frontal reposent sur un intermédiaire (par exemple un navigateur) via des paramètres de requête HTTPS ajoutés (GET, POST). Les messages ne sont pas envoyés directement. Les communications sur le canal d’appui sont transmises dans le corps d’une requête authentifiée du système dorsal pour une approche plus directe.

Les demandes d’autorisation « push » transitent par le canal d’appui, ce qui signifie que le serveur d’autorisation peut se fier à l’endroit où la demande a été envoyée :

• Le serveur d’autorisation peut se fier à la provenance de la demande, et les demandes n’ont pas été modifiées par un utilisateur final.
• Les détails de la demande n’ont pas été exposés dans la barre du navigateur ou dans l’historique et la vie privée est préservée à ce stade de la chaîne.
• Les restrictions sur la longueur de l’URL ne sont pas une contrainte.

​

Limites

• La taille maximale de la charge utile de la demande est limitée à 10 Ko.
• Les applications publiques ne sont pas prises en charge actuellement. Pour en savoir plus, lisez Demandes publiques et confidentielles.

​

Appeler le point de terminaison PAR

​

Exigences

Pour appeler le point de terminaison PAR, vous devez :

• Définir le type de contenu de la demande comme application/x-www-form-urlencoded.
• Utiliser des chaînes pour tous les paramètres transmis.
• Inclure un paramètre supplémentaire pour la méthode d’authentification de l’application dans la demande. Seuls les clients confidentiels prennent en charge la demande PAR, de sorte que les méthodes d’authentification d’application suivantes sont disponibles : Secret du client, clé privée JWT et mTLS. Vous devez utiliser la même méthode d’authentification d’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 ne fait que stocker et traiter :

• Les paramètres OAuth 2.0 standard et les extensions applicables, que nous reconnaissons au niveau du point de terminaison d’autorisation.
• Jusqu’à 10 paramètres d’autorisation personnalisés précédés du préfixe ext-.

La demande PAR ignore les paramètres d’autorisation personnalisés supplémentaires. Les paramètres d’autorisation personnalisés ne sont pas disponibles dans les Auth0 Actions et les Journaux.

Si vous utilisez des paramètres d’autorisation personnalisés dans des Actions, vous devez les faire précéder de ext-. Autrement, ils ne seront pas disponibles.

​

Exemple de demande 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 pour les demandes d’autorisation stockées. Les valeurs de la demande sont transmises au point de terminaison GET /authorize en tant que paramètre request_uri.
• Le paramètre expires_in correspond au nombre de secondes pendant lesquelles le paramètre 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 qui 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 anti-attaques

Pour les locataires de production Essentiel, Professionel et Entreprise, les appels au point de terminaison PAR sont inclus dans la limite de débit standard de l’Authentication API. Pour plus d’informations, voir Configurations des limites de taux et 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 demande d’autorisation et redirige l’agent utilisateur vers le point de terminaison d’autorisation. Pour en savoir plus sur le paramètre request_uri, lisez Configurer les demandes d’autorisation Push.

L’exemple suivant demande à l’agent utilisateur d’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 est identique.

​

Validation de la PAR

• La PAR est validée par le serveur d’autorisation à ce stade, comme toute autre demande 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 demande non-PAR est rejetée si la PAR est requise au niveau du locataire ou du client.

​

En savoir plus

• Configurer les demandes d’autorisation poussées (PAR)