Configurer le comportement de session dans Azure Active Directory B2C
Avant de commencer, utilisez le sélecteur Choisir un type de stratégie pour choisir le type de stratégie que vous configurez. Azure Active Directory B2C offre deux possibilités pour définir la façon dont les utilisateurs interagissent avec vos applications : via des flux utilisateurs prédéfinis ou via des stratégies personnalisées entièrement configurables. La procédure donnée dans cet article est différente pour chaque méthode.
Lorsque les utilisateurs s’authentifient auprès d’applications dans Azure Active Directory B2C (Azure AD B2C), l’authentification unique (SSO) constitue la méthode la plus sécurisée et la plus pratique. Cet article décrit les différentes méthodes d’authentification unique utilisées dans Azure AD B2C et vous aide à choisir la méthode SSO la plus appropriée lors de la configuration de votre stratégie.
Avec l’authentification unique, les utilisateurs se connectent une seule fois avec un seul compte et accèdent à plusieurs applications. L’application peut être une application web, mobile ou monopage, indépendamment du nom de la plateforme ou du domaine.
Lorsque l’utilisateur se connecte pour la première fois à une application, Azure AD B2C maintient une session basée sur un cookie. Lors des demandes d’authentification suivantes, Azure AD B2C lit et valide la session basée sur un cookie et émet un jeton d’accès sans inviter l’utilisateur à se reconnecter. Si la session basée sur un cookie expire ou devient non valide, l’utilisateur est invité à se connecter à nouveau.
Prérequis
- Créez un flux d’utilisateurs pour permettre aux utilisateurs de s’inscrire et de se connecter à votre application.
- Inscrire une application web.
Vue d’ensemble de la session Azure AD B2C
L’intégration avec Azure AD B2C implique trois types de sessions SSO :
- Azure AD B2C : session gérée par Azure AD B2C
- Fournisseur d’identité fédéré : session gérée par le fournisseur d’identité, par exemple Facebook, Salesforce ou compte Microsoft
- Application : session gérée par l’application web, mobile ou monopage
Session Azure AD B2C
Quand un utilisateur réussit à s’authentifier avec un compte local ou social, Azure AD B2C stocke une session basée sur un cookie sur le navigateur de l’utilisateur. Le cookie est stocké sous le nom de domaine du locataire Azure AD B2C, par exemple, https://contoso.b2clogin.com
.
Lorsqu'un utilisateur se connecte avec un compte fédéré, une fenêtre temporelle de session, également connue sous le nom de time-to-live (TTL), démarre. Si l'utilisateur se connecte à la même application ou à une application différente dans ce délai, Azure AD B2C tente d'obtenir un nouveau jeton d'accès auprès du fournisseur d'identité fédéré. Si la session du fournisseur d’identité fédéré a expiré ou n’est pas valide, le fournisseur d’identité fédéré invite l’utilisateur à entrer ses informations d’identification. Si la session de l’utilisateur est en cours, ou si l’utilisateur est connecté avec un compte local au lieu d’un compte fédéré, Azure AD B2C autorise l’utilisateur et empêche toute autre invite.
Vous pouvez configurer le comportement de la session, dont sa durée de vie et la façon dont Azure AD B2C partage la session entre les stratégies et les applications.
Session du fournisseur d’identité fédéré
Un fournisseur d’identité de réseaux sociaux ou d’entreprise gère sa propre session. Le cookie est stocké sous le nom de domaine du fournisseur d’identité, par exemple https://login.salesforce.com
. Azure AD B2C ne contrôle pas la session du fournisseur d’identité fédéré. Au lieu de cela, le comportement de session est déterminé par le fournisseur d’identité fédéré.
Examinez le cas suivant :
- Un utilisateur se connecte à Facebook pour vérifier son flux.
- Plus tard, l’utilisateur ouvre votre application et démarre le processus de connexion. L’application redirige l’utilisateur vers Azure AD B2C pour terminer le processus de connexion.
- Sur la page d’inscription ou de connexion d’Azure AD B2C, l’utilisateur choisit de se connecter avec son compte Facebook. L’utilisateur est redirigé vers Facebook. S’il existe une session active sur Facebook, l’utilisateur n’est pas invité à fournir ses informations d’identification et est immédiatement redirigé vers Azure AD B2C avec un jeton Facebook.
Session d’application
Un jeton d'accès OAuth2, un jeton d'identification ou un jeton SAML peut protéger une application web, mobile ou à page unique. Quand un utilisateur tente d’accéder à une ressource protégée sur l’application, celle-ci vérifie s’il existe une session active côté application. Si une session d'application n'existe pas ou si la session expire, l'application dirige l'utilisateur vers la page d'ouverture de session Azure AD B2C.
La session d’application peut être une session basée sur un cookie stockée sous le nom de domaine de l’application, par exemple https://contoso.com
. Les applications mobiles peuvent stocker la session d’une façon différente, mais dont l’approche est similaire.
Configurer le comportement de la session Azure AD B2C
Vous pouvez configurer le comportement de la session Azure AD B2C, notamment les éléments suivants :
Durée de vie de la session de l’application web (minutes) : durée pendant laquelle le cookie de session Azure AD B2C est stocké sur le navigateur de l’utilisateur après une authentification réussie. Vous pouvez définir la durée de vie de la session à 24 heures maximum.
Délai d’expiration de session d’application web : indique comment une session est étendue par le paramètre de durée de vie de la session ou par le paramètre Maintenir la connexion.
- Continue : indique que la session est étendue chaque fois que l’utilisateur effectue une authentification basée sur un cookie (valeur par défaut).
- Absolue : indique que l’utilisateur est obligé de se réauthentifier après la période spécifiée.
Configuration de l’authentification unique : vous pouvez configurer la session Azure AD B2C avec les étendues suivantes :
- Client : il s’agit du paramètre par défaut. L’utilisation de ce paramètre permet à plusieurs applications et flux d’utilisateur dans votre locataire B2C de partager la même session utilisateur. Par exemple, quand un utilisateur se connecte à une application, il peut également se connecter sans problème à une autre en y accédant.
- Application: ce paramètre vous permet de maintenir une session utilisateur exclusivement pour une application, indépendamment des autres applications. Par exemple, vous pouvez utiliser ce paramètre si vous voulez que l’utilisateur se connecte à Contoso Pharmacy, que l’utilisateur y soit ou non déjà connecté.
- Stratégie : ce paramètre vous permet de maintenir une session utilisateur exclusivement pour un flux d’utilisateur, indépendamment des applications qui l’utilisent. Par exemple, Azure AD B2C permet à l'utilisateur d'accéder à des parties plus sécurisées de plusieurs applications si l'utilisateur s'est déjà connecté et a effectué une étape d'authentification multifactorielle (MFA). Cet accès est maintenu tant que la session associée au flux d'utilisateurs reste active.
- Supprimé : ce paramètre oblige l’utilisateur à réexécuter tout le flux d’utilisateur à chaque exécution de la stratégie.
Configurer le flux utilisateur
Pour configurer le comportement de la session dans votre flux utilisateur, effectuez les étapes suivantes :
- Connectez-vous au portail Azure.
- Si vous avez accès à plusieurs tenants (locataires), sélectionnez l’icône Paramètres dans le menu supérieur pour basculer vers votre tenant Azure AD B2C à partir du menu Annuaires + abonnements.
- Choisissez Tous les services dans le coin supérieur gauche du portail Azure, puis recherchez et sélectionnez Azure AD B2C.
- Sélectionnez Flux d’utilisateurs.
- Ouvrez le flux utilisateur que vous avez créé précédemment.
- Sélectionner Propriétés.
- Configurez Durée de vie de la session de l’application web (minutes) , Délai d’expiration de la session de l’application web , Configuration de l’authentification unique et Exiger un jeton d’ID dans les demandes de déconnexion, selon les besoins.
- Cliquez sur Enregistrer.
Configurer la stratégie personnalisée
Pour configurer le comportement de la session dans votre stratégie utilisateur, effectuez les étapes suivantes :
Ouvrez le fichier de partie de confiance (RP), par exemple SignUpOrSignin.xml.
S’il n’existe pas déjà, ajoutez l’élément suivant
<UserJourneyBehaviors>
à l’élément<RelyingParty>
. Il doit être placé immédiatement après<DefaultUserJourney ReferenceId="UserJourney Id"/>
.<UserJourneyBehaviors> <SingleSignOn Scope="Application" /> <SessionExpiryType>Absolute</SessionExpiryType> <SessionExpiryInSeconds>86400</SessionExpiryInSeconds> </UserJourneyBehaviors>
Une fois que vous avez ajouté les éléments de comportement du parcours utilisateur, l’élément
RelyingParty
doit ressembler à l’exemple suivant :<RelyingParty> <DefaultUserJourney ReferenceId="SignUpOrSignIn" /> <UserJourneyBehaviors> <SingleSignOn Scope="Application" /> <SessionExpiryType>Absolute</SessionExpiryType> <SessionExpiryInSeconds>86400</SessionExpiryInSeconds> </UserJourneyBehaviors> <TechnicalProfile Id="PolicyProfile"> <DisplayName>PolicyProfile</DisplayName> <Protocol Name="OpenIdConnect" /> <OutputClaims> <OutputClaim ClaimTypeReferenceId="displayName" /> <OutputClaim ClaimTypeReferenceId="givenName" /> ... </OutputClaims> <SubjectNamingInfo ClaimType="sub" /> </TechnicalProfile> </RelyingParty>
Remplacez la valeur de l’attribut
Scope
par une des valeurs possibles :Suppressed
,Tenant
,Application
ouPolicy
. Pour plus d’informations, consultez l’article de référence RelyingParty.Définissez l’élément
SessionExpiryType
surRolling
ouAbsolute
. Pour plus d’informations, consultez l’article de référence RelyingParty.Définissez l’élément
SessionExpiryInSeconds
sur une valeur numérique comprise entre 900 secondes (15 minutes) et 86 400 secondes (24 heures). Pour plus d’informations, consultez l’article de référence RelyingParty.
Activer le maintien de la connexion (KMSI)
Vous pouvez activer la fonctionnalité Maintenir la connexion pour les utilisateurs de vos applications web et natives qui ont des comptes locaux dans votre répertoire Azure AD B2C. Lorsque vous activez la fonctionnalité, les utilisateurs peuvent choisir de rester connectés afin que la session reste active après avoir fermé le navigateur. La session est maintenue en définissant un cookie persistant. Les utilisateurs qui sélectionnent KMSI peuvent ensuite rouvrir le navigateur sans avoir à entrer à nouveau leur nom d’utilisateur et leur mot de passe. Cet accès (cookie persistant) est révoqué quand un utilisateur se déconnecte. Pour plus d’informations, consultez la démonstration en direct.
La fonction Maintenir la connexion est configurable au niveau du flux de l’utilisateur individuel. Avant d’activer la fonction Maintenir la connexion pour vos flux d’utilisateurs, prenez en compte les éléments suivants :
- Maintenir la connexion est pris en charge uniquement pour les versions recommandées des flux d’utilisateur d’inscription et de connexion (SUSI), de connexion et de modification de profil. Si vous disposez actuellement de versions Standard (hérité) ou Préversion héritée (v2) de ces flux d’utilisateur et que vous voulez activer Maintenir la connexion, vous devez créer des versions recommandées de ces flux.
- Maintenir la connexion n’est pas pris en charge avec les flux d’utilisateur de réinitialisation de mot de passe ou d’inscription.
- Si vous souhaitez activer Maintenir la connexion pour toutes les applications de votre locataire, nous vous recommandons d’activer cette fonctionnalité pour tous les flux d’utilisateurs de votre locataire. Étant donné qu’un utilisateur peut être présenté avec plusieurs stratégies au cours d’une session, il est possible qu’un utilisateur n’ait pas la fonction Maintenir la connexion activée, ce qui supprime le cookie Maintenir la connexion de la session.
- La fonction Maintenir la connexion ne doit pas être activée sur les ordinateurs publics.
Configurer Maintenir la connexion pour un flux utilisateur
Pour activer Maintenir la connexion pour votre flux utilisateur :
Connectez-vous au portail Azure.
Si vous avez accès à plusieurs tenants (locataires), sélectionnez l’icône Paramètres dans le menu supérieur pour basculer vers votre tenant Azure AD B2C à partir du menu Annuaires + abonnements.
Choisissez Tous les services dans le coin supérieur gauche du portail Azure, puis recherchez et sélectionnez Azure AD B2C.
Sélectionnez Flux utilisateur (stratégies) .
Ouvrez le flux utilisateur que vous avez créé précédemment.
Sélectionner Propriétés.
Sous Comportement de session, sélectionnez Activer Maintenir ma connexion dans la session. En regard de Maintenir la session de connexion (jours) , entrez une valeur comprise entre 1 et 90 pour indiquer le nombre de jours pendant lesquels une session peut rester ouverte.
Vous ne devez pas activer cette option sur les ordinateurs publics.
Configurer l’identificateur de page
Pour activer la fonctionnalité « Maintenir la connexion », définissez l’élément DataUri
de définition de contenu sur l’identificateur de pageunifiedssp
et la version de page1.1.0 ou ultérieure.
Ouvrez le fichier d’extension de votre stratégie. Par exemple :
SocialAndLocalAccounts/
TrustFrameworkExtensions.xml
. Ce fichier d’extension est un des fichiers de stratégie inclus dans le pack de démarrage des stratégies personnalisées, que vous obtenez en suivant la rubrique pré-requise Bien démarrer avec les stratégies personnalisées.Recherchez l’élément BuildingBlocks. Si l’élément n’existe pas, ajoutez-le.
Ajoutez l’élément ContentDefinitions à l’élément BuildingBlocks de la stratégie.
Votre stratégie personnalisée doit se présenter comme l’extrait de code suivant :
<BuildingBlocks> <ContentDefinitions> <ContentDefinition Id="api.signuporsignin"> <DataUri>urn:com:microsoft:aad:b2c:elements:unifiedssp:1.1.0</DataUri> </ContentDefinition> </ContentDefinitions> </BuildingBlocks>
Ajouter les métadonnées au profil technique autodéclaré
Pour ajouter la case à cocher Maintenir la connexion dans les pages d’inscription et de connexion, définissez les métadonnées setting.enableRememberMe
sur true. Remplacez les profils techniques SelfAsserted-LocalAccountSignin-Email dans le fichier d’extension.
Recherchez l’élément ClaimsProviders. Si l’élément n’existe pas, ajoutez-le.
Ajoutez le fournisseur de revendications suivant à l’élément ClaimsProviders :
<ClaimsProvider> <DisplayName>Local Account</DisplayName> <TechnicalProfiles> <TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email"> <Metadata> <Item Key="setting.enableRememberMe">True</Item> </Metadata> </TechnicalProfile> </TechnicalProfiles> </ClaimsProvider>
Enregistrez le fichier d’extensions.
Configurer un fichier de partie de confiance
Mettez à jour le fichier de partie de confiance qui lance le parcours utilisateur que vous avez créé. Le paramètre keepAliveInDays
vous permet de configurer la façon dont le cookie de session de maintien de la connexion (KMSI) doit persister. Par exemple, si vous définissez la valeur sur 30, le cookie de session KMSI est conservé pendant 30 jours. La plage de la valeur est comprise entre 1 et 90 jours. Affecter la valeur 0 désactive la fonctionnalité KMSI.
Ouvrez votre fichier de stratégie personnalisée. Par exemple SignUpOrSignin.xml.
S’il n’existe pas déjà, ajoutez un nœud enfant
<UserJourneyBehaviors>
au nœud<RelyingParty>
. Il doit être placé immédiatement après<DefaultUserJourney ReferenceId="User journey Id" />
, par exemple :<DefaultUserJourney ReferenceId="SignUpOrSignIn" />
.Ajoutez le nœud suivant en tant qu’enfant de l’élément
<UserJourneyBehaviors>
.<UserJourneyBehaviors> <SingleSignOn Scope="Tenant" KeepAliveInDays="30" /> <SessionExpiryType>Absolute</SessionExpiryType> <SessionExpiryInSeconds>1200</SessionExpiryInSeconds> </UserJourneyBehaviors>
Vous définissez à la fois KeepAliveInDays et SessionExpiryInSeconds de sorte que lors d’une connexion, si un utilisateur active KMSI, le paramètre KeepAliveInDays est utilisé pour définir les cookies ; sinon, la valeur spécifiée dans le paramètre SessionExpiryInSeconds est utilisée. Nous vous recommandons de définir la valeur de SessionExpiryInSeconds sur une courte période (1 200 secondes), tandis que vous pouvez définir la valeur de KeepAliveInDays sur une période relativement longue (30 jours), comme l’illustre l’exemple suivant :
<RelyingParty>
<DefaultUserJourney ReferenceId="SignUpOrSignIn" />
<UserJourneyBehaviors>
<SingleSignOn Scope="Tenant" KeepAliveInDays="30" />
<SessionExpiryType>Absolute</SessionExpiryType>
<SessionExpiryInSeconds>1200</SessionExpiryInSeconds>
</UserJourneyBehaviors>
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="OpenIdConnect" />
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="displayName" />
<OutputClaim ClaimTypeReferenceId="givenName" />
<OutputClaim ClaimTypeReferenceId="surname" />
<OutputClaim ClaimTypeReferenceId="email" />
<OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
<OutputClaim ClaimTypeReferenceId="identityProvider" />
<OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
</OutputClaims>
<SubjectNamingInfo ClaimType="sub" />
</TechnicalProfile>
</RelyingParty>
Déconnexion
Quand vous souhaitez déconnecter l’utilisateur de l’application, il ne suffit pas de supprimer les cookies de l’application ou d’arrêter la session de l’utilisateur. Vous devez rediriger l’utilisateur vers Azure AD B2C pour le déconnecter. Autrement, l’utilisateur peut être en mesure de se réauthentifier auprès de votre application sans entrer à nouveau ses informations d’identification.
Lors d’une demande de déconnexion, Azure AD B2C effectue les opérations suivantes :
- Invalide la session Azure AD B2C basée sur un cookie.
- Tente de se déconnecter des fournisseurs d’identité fédérés.
- Invalide la session Azure AD B2C basée sur un cookie.
- Tente de se déconnecter des fournisseurs d’identité fédérés :
- OpenId Connect : si le point de terminaison de configuration connu du fournisseur d’identité spécifie un emplacement
end_session_endpoint
. La demande de déconnexion ne passe pas le paramètreid_token_hint
. Si le fournisseur d’identité fédérée requiert ce paramètre, la demande de déconnexion échoue. - OAuth2 : si les métadonnées du fournisseur d’identité contiennent l’emplacement
end_session_endpoint
. - SAML : si les métadonnées du fournisseur d’identité contiennent l’emplacement
SingleLogoutService
.
- OpenId Connect : si le point de terminaison de configuration connu du fournisseur d’identité spécifie un emplacement
- Si vous le souhaitez, se déconnecte d’autres applications. Pour plus d’informations, consultez la section Déconnexion unique.
Notes
Vous pouvez désactiver la déconnexion des fournisseurs d’identité fédérés en définissant les métadonnées du profil technique du fournisseur d’identité SingleLogoutEnabled
sur false
.
La déconnexion efface l’état d’authentification unique de l’utilisateur auprès d’Azure AD B2C, mais il est possible qu’elle ne déconnecte pas l’utilisateur de sa session de fournisseur d’identité sociale. Si l’utilisateur sélectionne le même fournisseur d’identité lors d’une connexion ultérieure, il pourrait se réauthentifier sans avoir à entrer ses informations d’identification. Si un utilisateur veut se déconnecter de l’application, cela ne signifie pas nécessairement qu’il souhaite se déconnecter de son compte Facebook. Toutefois, si les comptes locaux sont utilisés, la session de l’utilisateur se termine correctement.
Déconnexion unique
Quand vous redirigez l’utilisateur vers le point de terminaison de déconnexion Azure AD B2C (pour OAuth2 et OpenID Connect) ou que vous envoyez une LogoutRequest
(pour SAML), Azure AD B2C efface la session de l’utilisateur du navigateur. Toutefois, l’utilisateur pourrait rester connecté à d’autres applications utilisant Azure AD B2C pour l’authentification. Pour déconnecter l’utilisateur de toutes les applications qui ont une session active, Azure AD B2C prend en charge la déconnexion unique, également appelée SLO (Single Log-Out).
Lors de la déconnexion, Azure AD B2C envoie simultanément une requête HTTP à l’URL de déconnexion inscrite de toutes les applications auxquelles l’utilisateur est actuellement connecté.
Configurer votre stratégie personnalisée
Pour prendre en charge la déconnexion unique, les profils techniques de l’émetteur de jetons pour JWT et SAML doivent spécifier les éléments suivants :
- Le nom du protocole, tel que
<Protocol Name="OpenIdConnect" />
- La référence au profil technique de session, tel que
UseTechnicalProfileForSessionManagement ReferenceId="SM-jwt-issuer" />
.
L’exemple suivant illustre les émetteurs de jetons JWT et SAML avec la fonctionnalité de déconnexion unique :
<ClaimsProvider>
<DisplayName>Local Account SignIn</DisplayName>
<TechnicalProfiles>
<!-- JWT Token Issuer -->
<TechnicalProfile Id="JwtIssuer">
<DisplayName>JWT token Issuer</DisplayName>
<Protocol Name="OpenIdConnect" />
<OutputTokenFormat>JWT</OutputTokenFormat>
...
<UseTechnicalProfileForSessionManagement ReferenceId="SM-jwt-issuer" />
</TechnicalProfile>
<!-- Session management technical profile for OIDC based tokens -->
<TechnicalProfile Id="SM-jwt-issuer">
<DisplayName>Session Management Provider</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.OAuthSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
</TechnicalProfile>
<!--SAML token issuer-->
<TechnicalProfile Id="Saml2AssertionIssuer">
<DisplayName>SAML token issuer</DisplayName>
<Protocol Name="SAML2" />
<OutputTokenFormat>SAML2</OutputTokenFormat>
...
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-issuer" />
</TechnicalProfile>
<!-- Session management technical profile for SAML based tokens -->
<TechnicalProfile Id="SM-Saml-issuer">
<DisplayName>Session Management Provider</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
Configuration de votre application
Pour qu’une application participe à la déconnexion unique :
- Pour les fournisseurs de services SAML, configurez l’application avec l’emplacement SingleLogoutService dans son document de métadonnées SAML. Vous pouvez aussi configurer la
logoutUrl
de l’inscription de l’application. Pour plus d’informations, consultez Défini l’URL de déconnexion. - Pour les applications OpenID Connect ou OAuth2, définissez l’attribut
logoutUrl
du manifeste d’inscription de votre application. Pour configurer l’URL de déconnexion :- Dans le menu Azure AD B2C, sélectionnez Inscriptions d’applications.
- Sélectionnez votre inscription d’application.
- Sous Gérer, sélectionnez Authentification.
- Sous l’URL de déconnexion du canal frontal, configurez votre URL de déconnexion.
Gestion des demandes de déconnexion unique
Quand Azure AD B2C reçoit la demande de déconnexion, il utilise un iframe HTML de canal frontal pour envoyer une requête HTTP à l’URL de déconnexion inscrite de chaque application participante à laquelle l’utilisateur est actuellement connecté. Notez que l’application qui déclenche la demande de déconnexion ne reçoit pas ce message de déconnexion. Vos applications doivent répondre à la demande de déconnexion en effaçant la session d’application qui identifie l’utilisateur.
- Pour les applications OpenID Connect et OAuth2, Azure AD B2C envoie une requête HTTP GET à l’URL de déconnexion inscrite.
- Pour les applications SAML, Azure AD B2C envoie une requête de déconnexion SAML à l’URL de déconnexion inscrite.
Lorsque Azure AD B2C informe toutes les applications de la déconnexion, il procède à l'une des opérations suivantes :
- Pour les applications OpenID Connect ou OAuth2, cela redirige l’utilisateur vers le
post_logout_redirect_uri
demandé incluant le paramètre (facultatif)state
spécifié dans la demande initiale. Par exemple,https://contoso.com/logout?state=foo
. - Pour les applications SAML, il envoie une réponse de déconnexion SAML via HTTP POST à l’application qui a initialement envoyé la demande de déconnexion.
Sécuriser la redirection de déconnexion
Après la déconnexion, l’utilisateur est redirigé vers l’URI que vous spécifiez dans le paramètre post_logout_redirect_uri
, quelles que soient les URL de réponse qui ont été spécifiées pour l’application. Cependant, si un id_token_hint
valide est transmis et que l’option Exiger un jeton d’ID dans les demandes de déconnexion est activée, Azure AD B2C vérifie que la valeur de post_logout_redirect_uri
correspond à l’un des URI de redirection configurés de l’application avant d’effectuer la redirection. Si aucune URL de réponse correspondante n’a été configurée pour l’application, un message d’erreur s’affiche et l’utilisateur n’est pas redirigé.
Pour exiger un jeton d’ID dans les demandes de déconnexion :
- Connectez-vous au portail Azure.
- Si vous avez accès à plusieurs tenants (locataires), sélectionnez l’icône Paramètres dans le menu supérieur pour basculer vers votre tenant Azure AD B2C à partir du menu Annuaires + abonnements.
- Choisissez Tous les services dans le coin supérieur gauche du portail Azure, puis recherchez et sélectionnez Azure AD B2C.
- Sélectionnez Flux d’utilisateurs.
- Ouvrez le flux utilisateur que vous avez créé précédemment.
- Sélectionner Propriétés.
- Activez l’option Exiger un jeton d’ID dans les demandes de déconnexion.
Pour exiger un jeton d’ID dans les demandes de déconnexion, ajoutez un élément UserJourneyBehaviors à l’intérieur de l’élément RelyingParty. Définissez ensuite EnforceIdTokenHintOnLogout dans l’élément SingleSignOn sur true
. Pour plus d’informations, consultez la démonstration en direct. Votre élément UserJourneyBehaviors devrait ressembler à l’exemple suivant :
<UserJourneyBehaviors>
<SingleSignOn Scope="Tenant" EnforceIdTokenHintOnLogout="true"/>
</UserJourneyBehaviors>
Pour configurer l’URL de déconnexion de votre application :
- Sélectionnez Inscriptions d’applications, puis sélectionnez votre application.
- Sélectionnez Authentification.
- Dans la zone de texte URL de déconnexion, saisissez votre URI de redirection après déconnexion, puis sélectionnez Enregistrer.
Étapes suivantes
- Découvrez comment configurer les jetons dans Azure AD B2C.