> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

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

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

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

Une [requête d’autorisation poussée (PAR)](https://datatracker.ietf.org/doc/html/rfc9126) est un protocole côté serveur qui permet d’envoyer des requêtes d’autorisation directement au <Tooltip tip="Serveur d’autorisation : Serveur centralisé qui contribue à définir les limites de l’accès d’un utilisateur. Par exemple, votre serveur d’autorisation peut contrôler les données, les tâches et les fonctionnalités accessibles à un utilisateur." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=authorization+server">serveur d’autorisation</Tooltip>. Il s’agit d’un composant technique du [profil de sécurité Financial-Grade API (FAPI) 1.0](https://openid.net/specs/openid-financial-api-part-2-1_0.html), conçu pour protéger les API dans des scénarios à enjeux élevés.

<div id="how-it-works">
  ## Fonctionnement
</div>

PAR permet à votre application d’envoyer directement au point de terminaison PAR du serveur d’autorisation les paramètres des requêtes d’autorisation <Tooltip tip="OAuth 2.0 : cadre d’autorisation qui définit les protocoles et les processus d’autorisation." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip> **(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](/docs/fr-ca/get-started/applications/configure-par).

<Frame>
  <img src="https://mintcdn.com/translations/6GE5Z24GDCZehiJ9/docs/images/cdy7uua7fh8z/6ivWNzZR7pnV79AXtjhJca/ad707b701d2a6d8b965ca3afe8846868/Template_for_Docs_-_Authorization_Code_Flow_with_PAR.png?fit=max&auto=format&n=6GE5Z24GDCZehiJ9&q=85&s=8bafb3103b84f8a0c3d6b5476bbd0dc5" alt="" width="1500" height="1000" data-path="docs/images/cdy7uua7fh8z/6ivWNzZR7pnV79AXtjhJca/ad707b701d2a6d8b965ca3afe8846868/Template_for_Docs_-_Authorization_Code_Flow_with_PAR.png" />
</Frame>

<div id="benefits">
  ## Avantages
</div>

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](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow), 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.

<div id="limitations">
  ## Limitations
</div>

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

<div id="call-the-par-endpoint">
  ## Effectuer une requête vers le point de terminaison PAR
</div>

<div id="requirements">
  ### Exigences
</div>

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 <Tooltip tip="Client confidentiel : client (application) qui peut conserver des informations d’identification de façon sécurisée au moyen d’un backend fiable. Parmi les exemples, on compte une application web avec un backend sécurisé et une application machine-to-machine (M2M)." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=confidential+clients">clients confidentiels</Tooltip> prennent en charge PAR; les [méthodes d’authentification de l’application](https://auth0.com/docs/api/authentication#authentication-methods) suivantes sont donc offertes : <Tooltip tip="Secret client : secret utilisé par un client (application) pour s’authentifier auprès du serveur d’autorisation; il ne doit être connu que du client et du serveur d’autorisation et doit être suffisamment aléatoire pour ne pas pouvoir être deviné." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Client+Secret">Secret client</Tooltip>, clé privée <Tooltip tip="Secret client : secret utilisé par un client (application) pour s’authentifier auprès du serveur d’autorisation; il ne doit être connu que du client et du serveur d’autorisation et doit être suffisamment aléatoire pour ne pas pouvoir être deviné." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=JWT">JWT</Tooltip> 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 <Tooltip tip="Jeton d’accès : information d’identification d’autorisation, sous la forme d’une chaîne opaque ou d’un JWT, utilisée pour accéder à une API." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=access+token">jeton d’accès</Tooltip>.

<div id="supported-parameters">
  ### Paramètres pris en charge
</div>

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](/docs/fr-ca/customize/actions) et les [Logs](/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 Actions, vous devez les faire précéder de `ext-`. Sinon, ils ne seront pas disponibles.
</Callout>

<div id="example-par-request">
  ### Exemple de requête PAR
</div>

```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"
```

<div id="example-par-response">
  ### Exemple de réponse PAR
</div>

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

```json 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
 }
```

<div id="rate-limits">
  ### Limites de débit
</div>

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](/docs/fr-ca/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-configurations), puis cliquez sur votre type d’abonnement. Ensuite, cliquez sur **Authentication API**.

<div id="call-the-authorization-endpoint">
  ## Appeler le point de terminaison d’autorisation
</div>

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](/docs/fr-ca/get-started/applications/configure-par).

L’exemple suivant amène l’agent utilisateur à effectuer la requête HTTP suivante :

```http wrap 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 <Tooltip tip="Flux d’autorisation : grant d’autorisation (ou workflow) défini dans le framework OAuth 2.0." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=authorization+flow">flux d’autorisation</Tooltip> se déroule de la même façon.

<div id="validation">
  ### Validation
</div>

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

<div id="learn-more">
  ## Pour en savoir plus
</div>

* [Configurer les requêtes d’autorisation poussées (PAR)](/docs/fr-ca/get-started/applications/configure-par)