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

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.

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.

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.

• 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.

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.

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.

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"

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
 }

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.

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.

• 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.

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