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

# Architecture des portails Universal

> Découvrez comment un portail Universal connecte les utilisateurs, obtient des jetons d’accès pour les serveurs de ressources, prend en charge l’authentification renforcée et les Forms, et gère les sessions.

> [!WARNING]
>
> **La fonctionnalité Auth0 Universal Portals est en .**

Un Portal est une application côté serveur hébergée par Auth0. Le serveur du portail connecte les utilisateurs, conserve leurs jetons et appelle les serveurs de ressources en leur nom. Le navigateur ne voit jamais de jeton d’accès ni de jeton d’actualisation : il ne détient qu’un témoin de session sécurisé.

Les sections suivantes présentent les actors d’un Portal, la façon dont les utilisateurs se connectent et dont les composants appellent les serveurs de ressources, ainsi que le fonctionnement de l’authentification renforcée, des Forms et des sessions.

Pour créer votre premier Portal, consultez [Démarrage rapide d’Universal Portals](https://auth0.com/docs/fr-ca/customize/portals/quickstart.md). Pour ouvrir un Portal à partir de votre application, consultez [Accéder aux Portals](https://auth0.com/docs/fr-ca/customize/portals/access-portals.md). Pour configurer l’application du portail, consultez [Configurer une application pour Universal Portals](https://auth0.com/docs/fr-ca/customize/portals/configure-portal-application.md).

## Acteurs

* **Navigateur** : affiche le Portail et les composants.
* **Serveur du Portail** : connecte les utilisateurs, stocke les jetons et relaie les appels des composants vers les serveurs de ressources.
* **Auth0** : le serveur d'autorisation qui connecte les utilisateurs et émet les jetons.
* **[API My Account](https://auth0.com/docs/fr-ca/manage-users/my-account-api.md) et [API My Organization](https://auth0.com/docs/fr-ca/manage-users/my-organization-api.md)** : les serveurs de ressources qu'appellent les composants.
* **Côté serveur de Forms** : exécute [Auth0 Forms](https://auth0.com/docs/fr-ca/customize/forms.md) et leurs flux.

```mermaid theme={null}
flowchart LR
    browser["Navigateur"] -- "Session cookie" --> portal["Serveur du portail"]
    portal -- "Sign-in, token requests" --> auth0["Auth0"]
    portal -- "Access token per call" --> apis["API My Account<br/>API My Organization"]
    browser -- "Form submissions" --> forms["Services côté serveur de Forms"]
```

## Accès avec authentification unique

Lorsqu’un utilisateur ouvre l’URL du portail, le serveur du portail lance un flux de code d’autorisation avec [Proof Key for Code Exchange (PKCE)](https://auth0.com/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce.md). Si l’utilisateur a déjà une session Auth0, Auth0 renvoie un code d’autorisation sans afficher d’invite de connexion. Le serveur du portail échange ce code contre un jeton d’ID, un jeton d’accès et un jeton d’actualisation, puis les stocke. Il définit ensuite le témoin de session.

```mermaid theme={null}
sequenceDiagram
    participant B as Browser
    participant P as Portal server
    participant A as Auth0

    B->>P: Open portal URL
    P-->>B: Redirect to /authorize
    B->>A: GET /authorize
    Note over A: User has an Auth0 session
    A-->>B: Redirect to /portals/auth/callback with code
    B->>P: GET /portals/auth/callback
    P->>A: Exchange code for tokens
    A-->>P: ID token, access token, refresh token
    Note over P: Tokens stay on the server
    P-->>B: Session cookie and portal page
```

Si l'utilisateur n'a pas de session Auth0, Auth0 affiche la page de connexion avant de renvoyer le code.

## Accès avec un jeton de transfert de session

Une [application native](https://auth0.com/docs/fr-ca/get-started/auth0-overview/create-applications/native-apps.md) peut transmettre un jeton de transfert de session dans l'URL du portail. Le serveur du portail transmet ensuite le jeton à `/authorize`. Auth0 valide le jeton, connecte l'utilisateur sans afficher d'invite et renvoie le code, comme pour l'authentification unique (Authentification unique (SSO) : service qui, après la connexion d'un utilisateur à une application, le connecte automatiquement à d'autres applications. La déconnexion unique fonctionne de la même façon, mais en sens inverse.). Un jeton de transfert de session est à usage unique et expire au bout de 60 secondes. Si Auth0 rejette le jeton, l'utilisateur est redirigé vers la page de connexion.

```mermaid theme={null}
sequenceDiagram
    participant N as Native application
    participant B as In-app browser
    participant P as Portal server
    participant A as Auth0

    N->>A: Exchange refresh token for session transfer token
    A-->>N: Session transfer token
    N->>B: Open portal URL with the token
    B->>P: GET portal URL
    P-->>B: Redirect to /authorize with the token
    B->>A: GET /authorize
    A-->>B: Redirect to callback with code
    B->>P: GET callback
    P->>A: Exchange code for tokens
    P-->>B: Session cookie and portal page
```

Pour mettre en œuvre ce scénario, consultez [Ouvrir un portail à partir d'une application native](https://auth0.com/docs/fr-ca/customize/portals/access-portals.md#open-a-portal-from-a-native-application).

## Appels d'un composant à un serveur de ressources

Un composant n'appelle jamais un serveur de ressources directement depuis le navigateur. Il envoie plutôt la requête au serveur du portail, à l'adresse `/portals/{slug}/proxy/...`, en précisant le public et la permission dont il a besoin. Le serveur du portail ajoute un jeton d'accès, puis transmet la requête à l'API.

### Émission des jetons d’accès

Les portails exigent toujours un jeton d’actualisation (Jeton d'actualisation : type particulier de jeton qui permet d'obtenir un jeton d'accès renouvelé. Il est utile pour renouveler les jetons d'accès qui expirent sans obliger l'utilisateur à se reconnecter.). Le serveur du portail s’en sert comme principal mécanisme pour émettre des jetons d’accès pour chaque serveur de ressources qu’appellent vos composants. Il s’appuie sur un jeton d’actualisation multiressource (MRRT) pour passer d’un public à l’autre, de sorte que l’utilisateur n’a à se connecter qu’une seule fois. Le portail réutilise un jeton d’accès jusqu’à son expiration, puis en émet un nouveau.

L’application du portail requiert deux paramètres pour chaque serveur de ressources : une autorisation client qui accorde les permissions et une politique de jeton d’actualisation qui autorise l’échange. Pour en savoir plus, consultez [Multi-Resource Refresh Token](https://auth0.com/docs/fr-ca/secure/tokens/refresh-tokens/multi-resource-refresh-token.md).

```mermaid theme={null}
sequenceDiagram
    participant B as Browser
    participant P as Portal server
    participant A as Auth0
    participant R as Resource server

    B->>P: Request to /portals/{slug}/proxy/...
    alt The portal has a valid access token for the audience and scope
        Note over P: Reuse the access token
    else No valid access token
        P->>A: Refresh token grant for the audience and scope
        A-->>P: Access token
    end
    P->>R: Request with the access token
    R-->>P: Response
    P-->>B: Response
```

### Serveurs de ressources autorisés

Les appels des composants sont acheminés uniquement vers l'API My Account et l'API My Organization de votre locataire, et seulement vers celles pour lesquelles l'application du portail dispose d'une autorisation client. La configuration recommandée accorde l'accès aux deux. Le serveur du portail rejette avec le code `403` toute requête destinée à un autre public.

### Limites anti-attaques

Si l'API My Account renvoie `429 Too Many Requests` pendant qu'un composant d'[authentification multifacteur (MFA)](https://auth0.com/docs/fr-ca/secure/multi-factor-authentication.md) ou de clé d'identification charge des données, le Portal remplace ce composant par le message « Too many requests » accompagné d'un bouton Réessayer.

## Authentification renforcée

C’est en fonction des politiques et des Actions de votre locataire qu’une opération exige ou non la MFA. Par exemple, imaginons que votre locataire dispose de l’Action post-login suivante. Celle-ci déclenche un défi MFA lorsqu’un échange de jeton d’actualisation demande l’accès à l’API My Account avec la permission de supprimer une méthode d’authentification. Comme le domaine est tiré du nom d’hôte de la requête, l’Action fonctionne aussi bien avec votre domaine Auth0 qu’avec un domaine personnalisé :

```javascript wrap lines theme={null}
exports.onExecutePostLogin = async (event, api) => {
    const { protocol } = event.transaction ?? {};
    const { hostname, body } = event.request ?? {};

    const isRefreshTokenExchange = protocol === "oauth2-refresh-token";
    const isMyAccountApi = body?.audience === `https://${hostname}/me/`;
    const deletesAuthenticator = body?.scope?.includes("delete:me:authentication_methods");

    if (isRefreshTokenExchange && isMyAccountApi && deletesAuthenticator) {
        api.authentication.challengeWithAny([{ type: "email" }, { type: "otp" }]);
    }
};
```

Lorsque le Portail demande un jeton d'accès pour ce public et cette permission, Auth0 exécute l'Action, qui invite l'utilisateur à choisir un facteur, puis répond avec `mfa_required`. Le Portail lance le défi MFA dans une fenêtre contextuelle et relance la requête initiale une fois que l'utilisateur l'a complété. Pour en savoir plus, consultez [Déclencheurs d'Actions : post-login - Objet API](https://auth0.com/docs/fr-ca/actions/reference/post-login/post-login-api-object.md).

```mermaid theme={null}
sequenceDiagram
    participant B as Browser
    participant P as Portal server
    participant A as Auth0
    participant R as My Account API

    B->>P: Delete an authenticator
    P->>A: Request an access token with the delete scope
    A-->>P: mfa_required
    P-->>B: Start the MFA challenge
    B->>A: Complete the MFA challenge
    A-->>P: Access token with the delete scope
    P->>R: Retry the request with the access token
    R-->>P: Response
    P-->>B: Response
```

## Soumission des Forms

Un [Form Auth0](https://auth0.com/docs/fr-ca/customize/forms.md) s’affiche dans la page du portail, mais ses requêtes vont directement du navigateur au côté serveur de Forms, sans passer par le serveur du portail. C’est le côté serveur de Forms qui exécute le flux. Si le flux appelle une API, il utilise les informations d’identification d’une connexion au coffre-fort de Forms. L’API est un serveur de ressources, généralement la Management API, mais il peut s’agir de n’importe quelle API.

```mermaid theme={null}
sequenceDiagram
    participant B as Browser
    participant F as Forms backend
    participant R as Resource server

    B->>F: Submit the Form
    F->>F: Run the Flow
    F->>F: Read credentials from the vault
    F->>R: Call the API with the credentials
    R-->>F: Response
    F-->>B: Form response and completion message
```

Le Form reçoit son contexte du jeton d’ID de l'utilisateur au chargement du Portal. Pour en savoir plus, consultez [Variables de contexte des Forms](https://auth0.com/docs/fr-ca/customize/portals/portal-components.md#forms-context-variables).

## Sessions et durées de vie des jetons

Un Portal comporte deux sessions et deux types de jetons :

* Session Auth0 : établie par Auth0 lorsque l’utilisateur se connecte. Elle est régie par les paramètres de session de votre locataire.
* Session du Portal : le témoin de session du Portal. Elle prend fin après 1 heure d’inactivité ou 1 jour après la connexion, selon la première éventualité.
* Jeton d’actualisation : l’information d’identification qu’utilise le serveur du portail pour générer des jetons d’accès. Tous les appels d’API en dépendent; configurez donc ses durées de vie en fonction de la session du portail.
* Jeton d’accès : généré lorsqu’un composant en a besoin, puis réutilisé jusqu’à son expiration. Configurez sa durée de vie sur le serveur de ressources conformément à votre politique de sécurité.

Lorsque la session du portail prend fin, le Portal redirige l’utilisateur vers Auth0 pour qu’il se reconnecte.

```mermaid theme={null}
flowchart LR
    ended["La session du portail se termine"] --> check{"La session Auth0 est-elle<br/>toujours active?"}
    check -- "Yes" --> silent["L’utilisateur poursuit<br/>sans invite"]
    check -- "No" --> login["L’utilisateur voit<br/>la page de connexion"]
```

Si le jeton d'actualisation expire avant la session du portail, les appels d'API échouent jusqu'à ce que l'utilisateur se reconnecte. Pour éviter ce problème, utilisez les durées de vie recommandées dans [Configurer une application pour les portails Universal](https://auth0.com/docs/fr-ca/customize/portals/configure-portal-application.md#recommended-configuration).

## Prochaines étapes

> [card] [Démarrage rapide des Universal Portals](https://auth0.com/docs/fr-ca/customize/portals/quickstart.md)
>
> Créez votre premier Portal en quelques minutes.

> [card] [Configurer une application pour les Universal Portals](https://auth0.com/docs/fr-ca/customize/portals/configure-portal-application.md)
>
> Définissez les autorisations client et les politiques de jeton d'actualisation requises pour l'émission des jetons d'accès.

> [card] [Accéder aux Portals](https://auth0.com/docs/fr-ca/customize/portals/access-portals.md)
>
> Redirigez les utilisateurs de vos applications vers le Portal.

> [card] [Dépanner les Universal Portals](https://auth0.com/docs/fr-ca/customize/portals/troubleshoot-portals.md)
>
> Corrigez les erreurs de connexion, de session et d'API.