> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-docs-event-stream-action-templates.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

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

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  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](https://auth0.com/pricing/) pour plus de détails.
</Callout>

[La Pushed Authorization Request (PAR) (Demande d’autorisation poussée)](https://datatracker.ietf.org/doc/html/rfc9126) 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)](https://openid.net/specs/openid-financial-api-part-2-1_0.html) 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 <Tooltip href="/docs/fr-ca/glossary?term=oath2" tip="OAuth 2.0
Cadre d’applications d’autorisation qui définit les protocoles d’autorisation et les flux de production." cta="Voir le glossaire">OAuth 2.0</Tooltip> 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](/docs/fr-ca/get-started/applications/configure-par).

<Frame>
  <img src="https://mintcdn.com/docs-dev-docs-event-stream-action-templates/1giWs3MwX5Akld9c/docs/images/fr-ca/cdy7uua7fh8z/6ivWNzZR7pnV79AXtjhJca/5adaff0719cfa1be13e80812f941ce71/Template_for_Docs_-_Authorization_Code_Flow_with_PAR.png?fit=max&auto=format&n=1giWs3MwX5Akld9c&q=85&s=032e13d0e03abd2368197a2b6d94cdfa" alt="null" width="1500" height="1000" data-path="docs/images/fr-ca/cdy7uua7fh8z/6ivWNzZR7pnV79AXtjhJca/5adaff0719cfa1be13e80812f941ce71/Template_for_Docs_-_Authorization_Code_Flow_with_PAR.png" />
</Frame>

## 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](/docs/fr-ca/get-started/applications/confidential-and-public-applications).

## 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](https://auth0.com/docs/api/authentication#authentication-methods) suivantes sont disponibles : Secret du client, clé privée <Tooltip href="/docs/fr-ca/glossary?term=json-web-token" tip="Jeton Web JSON (JWT)
  Format standard de jeton d’ID (et souvent de jeton d’accès) utilisé pour représenter en toute sécurité des demandes entre deux parties." cta="Voir le glossaire">JWT</Tooltip> 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](/docs/fr-ca/customize/actions) et les [Journaux](/docs/fr-ca/deploy-monitor/logs).

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  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.
</Callout>

### Exemple de demande PAR

```bash lines theme={null}
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.

```lines theme={null}
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](/docs/fr-ca/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-configurations) 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](/docs/fr-ca/get-started/applications/configure-par).

L’exemple suivant demande à l’agent utilisateur d’effectuer la requête HTTP suivante :

```lines theme={null}
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)](/docs/fr-ca/get-started/applications/configure-par)