Découvrez comment fonctionne le flux implicite avec Form Post et pourquoi vous devriez l’utiliser pour les applications web traditionnelles qui n’ont besoin que d’un jeton d’ID pour authentifier les utilisateurs.
Ne vous laissez pas induire en erreur par le terme « implicite » ! Bien qu’OAuth déconseille désormais l’utilisation du grant implicite pour obtenir des jetons d’accès dans les SPA, le scénario visé par le flux implicite avec Form Post est complètement différent et n’est pas concerné par les problèmes de sécurité qui ont mené à déconseiller son utilisation avec les SPA. Plus précisément, le flux implicite avec Form Post s’applique aux applications web traditionnelles, par opposition aux SPA. Vous obtenez des jetons d’ID plutôt que des jetons d’accès, dont l’usage prévu est complètement différent. Le flux utilise POST au lieu de placer les jetons dans des fragments d’URL (comme avec les SPA), ce qui peut exposer des éléments du jeton à des attaques liées à l’historique du navigateur, aux en-têtes de redirection, etc.
Vous pouvez utiliser Connect (OIDC) avec de nombreux flux pour permettre l’ouverture de session dans une application web traditionnelle. Dans un flux courant, vous obtenez un au moyen du flux de code d’autorisation exécuté par le backend de l’application. Cette méthode est efficace et robuste, mais elle exige que votre application web obtienne et gère un secret. Vous pouvez éviter cette contrainte si tout ce que vous voulez faire est de mettre en place la connexion et que vous n’avez pas besoin d’obtenir des pour appeler des API.Le flux implicite avec Form Post utilise OIDC pour mettre en place une ouverture de session sur le Web très semblable à la façon dont et WS-Federation fonctionnent. L’application web demande et obtient des jetons par le canal frontal, sans avoir besoin de secrets ni d’appels backend supplémentaires. Avec cette méthode, vous n’avez pas besoin d’obtenir, de gérer, d’utiliser ni de protéger un secret dans votre application.
Vous devriez utiliser ce flux uniquement pour les cas d’utilisation axés sur la connexion; si vous devez demander des jetons d’accès pendant la connexion de l’utilisateur afin de pouvoir appeler une API, utilisez le flux de code d’autorisation avec PKCE ou le flux hybride.
L’utilisateur clique sur Login dans l’application.
Le SDK d’Auth0 redirige l’utilisateur vers l’Auth0 Authorization Server (point de terminaison /authorize) en transmettant un paramètre response_type de id_token, qui indique le type de jeton demandé. Il transmet également un paramètre response_mode de form_post pour assurer la sécurité.
Votre Auth0 Authorization Server redirige l’utilisateur vers le prompt de connexion et d’autorisation.
L’utilisateur s’authentifie à l’aide de l’une des options de connexion configurées et peut voir une page de consentement énumérant les permissions qu’Auth0 accordera à l’application.
Votre Auth0 Authorization Server redirige l’utilisateur vers l’application avec un jeton d’ID.