Architecture des portails Universal

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. Pour ouvrir un Portal à partir de votre application, consultez Accéder aux Portals. Pour configurer l’application du portail, consultez Configurer une application pour Universal Portals.

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 et API My Organization : les serveurs de ressources qu’appellent les composants.
Côté serveur de Forms : exécute Auth0 Forms et leurs flux.

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). 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. 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 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’. 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. Pour mettre en œuvre ce scénario, consultez Ouvrir un portail à partir d’une application native.

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

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) 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é :

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.

Soumission des Forms

Un Form Auth0 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. 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.

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

Prochaines étapes

Démarrage rapide des Universal Portals

Créez votre premier Portal en quelques minutes.

Configurer une application pour les Universal Portals

Définissez les autorisations client et les politiques de jeton d’actualisation requises pour l’émission des jetons d’accès.

Accéder aux Portals

Redirigez les utilisateurs de vos applications vers le Portal.

Dépanner les Universal Portals

Corrigez les erreurs de connexion, de session et d’API.

Personnalisation de l’image de marque

Personnalisation du code

Personnalisation par des tiers

Architecture des portails Universal

Acteurs

Accès avec authentification unique

Accès avec un jeton de transfert de session

Appels d’un composant à un serveur de ressources

Émission des jetons d’accès

Serveurs de ressources autorisés

Limites anti-attaques

Authentification renforcée

Soumission des Forms

Sessions et durées de vie des jetons

Prochaines étapes

Démarrage rapide des Universal Portals

Configurer une application pour les Universal Portals

Accéder aux Portals

Dépanner les Universal Portals

​Acteurs

​Accès avec authentification unique

​Accès avec un jeton de transfert de session

​Appels d’un composant à un serveur de ressources

​Émission des jetons d’accès

​Serveurs de ressources autorisés

​Limites anti-attaques

​Authentification renforcée

​Soumission des Forms

​Sessions et durées de vie des jetons

​Prochaines étapes

Démarrage rapide des Universal Portals

Configurer une application pour les Universal Portals

Accéder aux Portals

Dépanner les Universal Portals

Acteurs

Accès avec authentification unique

Accès avec un jeton de transfert de session

Appels d’un composant à un serveur de ressources

Émission des jetons d’accès

Serveurs de ressources autorisés

Limites anti-attaques

Authentification renforcée

Soumission des Forms

Sessions et durées de vie des jetons

Prochaines étapes