在 Azure Active Directory B2C 中設定會話行為
開始 之前,請使用 [選擇原則類型 選取器] 來選擇您要設定的原則類型。 Azure Active Directory B2C 提供兩種方法來定義使用者如何與您的應用程式互動:透過預先 定義的使用者流程 ,或透過完全可設定 的自訂原則 。 本文中每個方法所需的步驟都不同。
單一登入 (SSO) 會在使用者跨 Azure Active Directory B2C (Azure AD B2C) 中的應用程式登入時,新增安全性和便利性。 本文說明 Azure AD B2C 中使用的單一登入方法,並協助您在設定原則時選擇最適當的 SSO 方法。
使用單一登入,使用者一次使用單一帳戶登入,並取得多個應用程式的存取權。 不論平臺或功能變數名稱為何,應用程式都可以是 Web、行動或單頁應用程式。
當使用者一開始登入應用程式時,Azure AD B2C 會保存以 Cookie 為基礎的會話。 在後續的驗證要求之後,Azure AD B2C 會讀取並驗證以 Cookie 為基礎的會話,併發出存取權杖,而不會提示使用者再次登入。 如果 Cookie 型會話過期或變成無效,系統會提示使用者再次登入。
必要條件
- 建立使用者流程 ,讓使用者可以註冊並登入您的應用程式。
- 註冊 Web 應用程式 。
- 完成開始使用 Active Directory B2C 中的自訂原則中的 步驟
- 註冊 Web 應用程式 。
Azure AD B2C 會話概觀
與 Azure AD B2C 整合牽涉到三種類型的 SSO 會話:
- Azure AD B2C - 由 Azure AD B2C 管理的會話
- 同盟識別提供者 - 由識別提供者管理的會話,例如 Facebook、Salesforce 或 Microsoft 帳戶
- 應用程式 - 由 Web、行動或單一頁面應用程式管理的會話
Azure AD B2C 會話
當使用者成功向本機或社交帳戶進行驗證時,Azure AD B2C 會在使用者的瀏覽器中儲存以 Cookie 為基礎的會話。 Cookie 會儲存在 Azure AD B2C 租使用者功能變數名稱下,例如 https://contoso.b2clogin.com
。
當使用者使用同盟帳戶登入時,會話時間範圍,也稱為存留時間範圍 (TTL),就會啟動。 如果使用者在此 TTL 內登入相同或不同的應用程式,Azure AD B2C 會嘗試從同盟識別提供者取得新的存取權杖。 如果同盟識別提供者會話已過期或無效,同盟識別提供者會提示使用者輸入其認證。 如果使用者的會話正在進行中,或者如果使用者使用本機帳戶登入,而不是同盟帳戶,Azure AD B2C 會授權使用者,並防止任何進一步的提示。
您可以設定會話行為,包括會話 TTL,以及 Azure AD B2C 如何跨原則和應用程式共用會話。
同盟識別提供者會話
社交或企業識別提供者會管理自己的會話。 Cookie 會儲存在識別提供者的功能變數名稱下,例如 https://login.salesforce.com
。 Azure AD B2C 不會控制同盟識別提供者會話。 相反地,會話行為是由同盟識別提供者所決定。
試想以下情況:
- 使用者登入 Facebook 以檢查其摘要。
- 稍後,使用者會開啟您的應用程式並啟動登入程式。 應用程式會將使用者重新導向至 Azure AD B2C,以完成登入程式。
- 在 Azure AD B2C 註冊或登入頁面上,使用者選擇使用其 Facebook 帳戶登入。 使用者會重新導向至 Facebook。 如果 Facebook 有作用中的會話,則不會提示使用者提供其認證,且會立即使用 Facebook 權杖重新導向至 Azure AD B2C。
應用程式會話
OAuth2 存取權杖、識別碼權杖或 SAML 權杖可以保護 Web、行動或單頁應用程式。 當使用者嘗試存取應用程式上的受保護資源時,應用程式會檢查應用程式端是否有作用中的會話。 如果應用程式會話不存在或會話過期,應用程式會將使用者導向至 Azure AD B2C 登入頁面。
應用程式會話可以是以 Cookie 為基礎的會話,儲存在應用程式功能變數名稱下,例如 https://contoso.com
。 行動應用程式可能會以不同的方式儲存會話,但使用類似的方法。
設定 Azure AD B2C 會話行為
您可以設定 Azure AD B2C 會話行為,包括:
Web 應用程式會話存留期 (分鐘) - 成功驗證之後,Azure AD B2C 會話 Cookie 儲存在使用者的瀏覽器中的時間量。 您可以將會話存留期設定為 24 小時。
Web 應用程式會話逾時 - 指出會話存留期設定或 [讓我保持登入] 設定的延伸方式。
- 滾動 - 指出每次使用者執行 Cookie 型驗證時,會話都會延長(預設值)。
- Absolute - 指出使用者被迫在指定的時間週期之後重新驗證。
單一登入設定 - Azure AD B2C 會話可以使用下列範圍進行設定:
- 租使用者 - 此設定為預設值。 使用此設定可讓 B2C 租使用者中的多個應用程式和使用者流程共用相同的使用者會話。 例如,一旦使用者登入應用程式,使用者也可以在存取應用程式時順暢地登入另一個應用程式。
- 應用程式 - 此設定可讓您單獨維護應用程式的使用者會話,與其他應用程式無關。 例如,如果您希望使用者登入 Contoso Pharmacy,不論使用者是否已登入 Contoso Groceries,則可以使用此設定。
- 原則 - 此設定可讓您僅針對使用者流程維護使用者會話,而不受應用程式使用。 例如,如果使用者已經登入並完成多重要素驗證 (MFA) 步驟,Azure AD B2C 會授與使用者對多個應用程式較高安全性部分的存取權。 只要與使用者流程相關聯的會話保持作用中,此存取就會繼續。
- 已隱藏 - 此設定會強制使用者在每次執行原則時,透過整個使用者流程執行。
設定使用者流程
若要在使用者流程中設定會話行為,請遵循下列步驟:
- 登入 Azure 入口網站。
- 如果您有多個租使用者的存取權,請選取 頂端功能表中的 [設定 ] 圖示,從 [目錄 + 訂 用帳戶] 功能表切換至您的 Azure AD B2C 租使用者。
- 選擇 Azure 入口網站左上角的 [所有服務 ],然後搜尋並選取 [Azure AD B2C ]。
- 選取 [ 使用者流程 ]。
- 開啟您先前建立的使用者流程。
- 選取 [屬性] 。
- 設定 Web 應用程式會話存留期(分鐘) 、 Web 應用程式會話逾時 、 單一登入 設定,以及 視需要在登出要求 中要求要求識別碼權杖。
- 按一下 [檔案] 。
設定自訂原則
若要在自訂原則中設定會話行為,請遵循下列步驟:
開啟信賴憑證者 (RP) 檔案,例如 SignUpOrSignin.xml
如果它尚未存在,請將下列
<UserJourneyBehaviors>
專案新增至<RelyingParty>
元素。 它必須緊接在 之後<DefaultUserJourney ReferenceId="UserJourney Id"/>
。<UserJourneyBehaviors> <SingleSignOn Scope="Application" /> <SessionExpiryType>Absolute</SessionExpiryType> <SessionExpiryInSeconds>86400</SessionExpiryInSeconds> </UserJourneyBehaviors>
新增使用者旅程行為元素之後,元素
RelyingParty
看起來應該會像下列範例所示:<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>
將 屬性的值
Scope
變更為其中一個可能的值:Suppressed
、Tenant
、Application
或Policy
。 如需詳細資訊,請參閱 RelyingParty 參考文章。將
SessionExpiryType
專案設定為Rolling
或Absolute
。 如需詳細資訊,請參閱 RelyingParty 參考文章。將
SessionExpiryInSeconds
元素設定為介於 900 秒(15 分鐘)和 86,400 秒(24 小時)之間的數值。 如需詳細資訊,請參閱 RelyingParty 參考文章。
啟用 [讓我保持登入] (KMSI)
您可以為 Azure AD B2C 目錄中具有本機帳戶的 Web 和原生應用程式使用者啟用 KMSI 功能。 當您啟用此功能時,使用者可以選擇保持登入,讓會話在關閉瀏覽器之後保持作用中。 會話會藉由設定 持續性 Cookie 來維護。 選取 KMSI 的使用者,可以重新開啟瀏覽器,而不會提示您重新輸入其使用者名稱和密碼。 當使用者登出時,會撤銷此存取權(持續性 Cookie)。如需詳細資訊,請參閱 即時示範 。
KMSI 可在個別的使用者流程層級進行設定。 為使用者流程啟用 KMSI 之前,請考慮下列事項:
- KMSI 僅支援 註冊和登入(SUSI)、登入和設定檔編輯使用者流程的建議 版本。 如果您目前有 標準版(舊版) 或 舊版預覽版 - 這些使用者流程的 v2 版本,而且想要啟用 KMSI,您必須建立這些使用者流程的新 建議 版本。
- 密碼重設或註冊使用者流程不支援 KMSI。
- 如果您想要為租使用者中的所有應用程式啟用 KMSI,建議您為租使用者中的所有使用者流程啟用 KMSI。 因為使用者可以在會話期間顯示多個原則,所以他們可能會遇到未啟用 KMSI 的原則,這會從會話中移除 KMSI Cookie。
- KMSI 不應該在公用電腦上啟用。
設定使用者流程的 KMSI
若要為您的使用者流程啟用 KMSI:
登入 Azure 入口網站。
如果您有多個租使用者的存取權,請選取 頂端功能表中的 [設定 ] 圖示,從 [目錄 + 訂 用帳戶] 功能表切換至您的 Azure AD B2C 租使用者。
選擇 Azure 入口網站 左上角的 [所有服務],然後搜尋並選取 [Azure AD B2C]。
選取 [使用者流程] [原則]。
開啟您先前建立的使用者流程。
選取 [屬性] 。
在 [工作話行為] 底下,選取 [啟用讓我保持登入會話]。 在 [讓我保持登入會話(天)] 旁,輸入介於 1 到 90 的值,以指定會話可以保持開啟的天數。
用戶不應該在公用計算機上啟用此選項。
設定頁面標識碼
若要啟用 KMSI,請將內容定義DataUri
元素設定為頁面識別碼unifiedssp
和頁面 1.1.0 版或更新版本。
開啟原則的擴充檔案。 例如:
SocialAndLocalAccounts/
TrustFrameworkExtensions.xml
。 此擴充檔案是自定義原則入門套件中包含的其中一個原則檔案,您可以在必要條件中取得此檔案: 開始使用自定義原則。搜尋 BuildingBlocks 元素。 如果專案不存在,請加以新增。
將 ContentDefinitions 元素新增至 原則的 BuildingBlocks 元素。
您的自訂原則看起來應該像下列代碼段:
<BuildingBlocks> <ContentDefinitions> <ContentDefinition Id="api.signuporsignin"> <DataUri>urn:com:microsoft:aad:b2c:elements:unifiedssp:1.1.0</DataUri> </ContentDefinition> </ContentDefinitions> </BuildingBlocks>
將元數據新增至自我判斷技術配置檔
若要將 KMSI 複選框新增至註冊和登入頁面,請將 setting.enableRememberMe
元數據設定為 true。 覆寫延伸模組檔案中的 SelfAsserted-LocalAccountSignin-Email 技術配置檔。
尋找 ClaimsProviders 元素。 如果專案不存在,請加以新增。
將下列宣告提供者新增至 ClaimsProviders 元素:
<ClaimsProvider> <DisplayName>Local Account</DisplayName> <TechnicalProfiles> <TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email"> <Metadata> <Item Key="setting.enableRememberMe">True</Item> </Metadata> </TechnicalProfile> </TechnicalProfiles> </ClaimsProvider>
儲存延伸模組檔案。
設定信賴憑證者檔案
更新起始您所建立使用者旅程圖的信賴憑證者 (RP) 檔案。 參數 keepAliveInDays
可讓您設定讓我持續登入的時間長度(KMSI) 會話 Cookie。 例如,如果您將值設定為 30,KMSI 會話 Cookie 會持續 30 天。 值的範圍是從 1 到 90 天。 將值設定為 0 會關閉 KMSI 功能。
開啟您的自定義原則檔案。 例如, SignUpOrSignin.xml。
如果尚未存在,請將
<UserJourneyBehaviors>
子節點新增至<RelyingParty>
節點。 它必須緊接在 之後<DefaultUserJourney ReferenceId="User journey Id" />
,例如:<DefaultUserJourney ReferenceId="SignUpOrSignIn" />
。將下列節點新增為 專案的子
<UserJourneyBehaviors>
系。<UserJourneyBehaviors> <SingleSignOn Scope="Tenant" KeepAliveInDays="30" /> <SessionExpiryType>Absolute</SessionExpiryType> <SessionExpiryInSeconds>1200</SessionExpiryInSeconds> </UserJourneyBehaviors>
您可以同時設定 KeepAliveInDays 和 SessionExpiryInSeconds,以便在登入期間,如果使用者啟用 KMSI,則會使用 KeepAliveInDays 來設定 Cookie,否則會使用 SessionExpiryInSeconds 參數中指定的值。 建議您將 SessionExpiryInSeconds 的值設定為短期間 (1200 秒),而 KeepAliveInDays 的值可以設定為相對較長的期間 (30 天),如下列範例所示:
<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>
登出
當您想要將使用者註銷應用程式時,還不足以清除應用程式的 Cookie,或結束與使用者的會話。 您必須將使用者重新導向至 Azure AD B2C 以註銷。否則,使用者可能無法重新驗證您的應用程式,而不需要再次輸入其認證。
註銷要求時,Azure AD B2C:
- 使 Azure AD B2C Cookie 型會話失效。
- 嘗試從同盟識別提供者註銷。
- 使 Azure AD B2C Cookie 型會話失效。
- 嘗試從同盟識別提供者註銷:
- 選擇性地註銷其他應用程式。 如需詳細資訊,請參閱 單一註銷 一節。
注意
您可以將識別提供者技術配置檔元數據 SingleLogoutEnabled
設定為 false
,以停用同盟識別提供者的註銷。
註銷會清除使用者使用 Azure AD B2C 的單一登錄狀態,但可能不會將使用者註銷其社交識別提供者會話。 如果使用者在後續登入期間選取相同的識別提供者,他們可能會重新驗證而不輸入其認證。 如果使用者想要註銷應用程式,不一定表示他們想要註銷其 Facebook 帳戶。 不過,如果使用本機帳戶,使用者的會話就會正確結束。
單一註銷
當您將使用者重新導向至 Azure AD B2C 註銷端點(適用於 OAuth2 和 OpenID 連線),或傳送 LogoutRequest
(適用於 SAML),Azure AD B2C 會從瀏覽器清除使用者的會話。 不過,使用者可能仍會登入其他使用 Azure AD B2C 進行驗證的應用程式。 若要將使用者註銷具有作用中會話的所有應用程式,Azure AD B2C 支援單一註銷,也稱為單一註銷(SLO)。
在註銷期間,Azure AD B2C 會同時將 HTTP 要求傳送至使用者目前登入之所有應用程式的已註冊註銷 URL。
設定您的自定義原則
若要支援單一註銷,JWT 和 SAML 的令牌簽發者技術設定檔必須指定:
- 通訊協定名稱,例如
<Protocol Name="OpenIdConnect" />
- 工作階段技術設定檔的參考,例如
UseTechnicalProfileForSessionManagement ReferenceId="SM-jwt-issuer" />
。
下列範例說明具有單一註銷的 JWT 和 SAML 令牌簽發者:
<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>
設定您的應用程式
為了讓應用程式參與單一登出:
- 若為 SAML 服務提供者,請使用其 SAML 元數據檔中的 SingleLogoutService 位置來設定應用程式。 您也可以設定應用程式註冊
logoutUrl
。 如需詳細資訊,請參閱 設定註銷 URL。 - 針對 OpenID 連線 或 OAuth2 應用程式,請設定
logoutUrl
應用程式註冊指令清單的屬性。 若要設定註銷 URL:- 從 [Azure AD B2C] 功能表中,選取 [應用程式註冊]。
- 選取您的應用程式註冊。
- 在 [管理] 底下,選取 [驗證]。
- 在 [ 前端通道註銷 URL] 底下,設定您的註銷 URL。
處理單一登出要求
當 Azure AD B2C 收到註銷要求時,它會使用前端通道 HTML iframe,將 HTTP 要求傳送至使用者目前登入之每個參與應用程式的已註冊註銷 URL。 請注意,觸發註銷要求的應用程式會取得此註銷訊息。 您的應用程式必須清除識別使用者的應用程式會話,以回應註銷要求。
- 針對OpenID連線和OAuth2應用程式,Azure AD B2C會將 HTTP GET 要求傳送至已註冊的註銷 URL。
- 針對 SAML 應用程式,Azure AD B2C 會將 SAML 註銷要求傳送至已註冊的註銷 URL。
當 Azure AD B2C 通知所有應用程式註銷時,它會繼續執行下列其中一項作業:
- 針對 OpenID 連線 或 OAuth2 應用程式,它會將使用者重新導向至要求
post_logout_redirect_uri
,包括初始要求中指定的 (選擇性)state
參數。 例如https://contoso.com/logout?state=foo
。 - 針對 SAML 應用程式,它會透過 HTTP POST 將 SAML 註銷回應傳送至最初傳送註銷要求的應用程式。
保護您的註銷重新導向
註銷之後,不論您為應用程式指定的回復 URL 為何,用戶都會重新導向至 參數中指定的 post_logout_redirect_uri
URI。 不過,如果傳遞有效 id_token_hint
且 開啟註銷要求 中的 [需要標識符令牌],Azure AD B2C 會在 post_logout_redirect_uri
執行重新導向之前,先確認的值符合其中一個應用程式設定的重新導向 URI。 如果未為應用程式設定相符的回復 URL,則會顯示錯誤訊息,且不會重新導向使用者。
若要要求註銷要求中的識別碼令牌:
- 登入 Azure 入口網站。
- 如果您有多個租使用者的存取權,請選取頂端功能表中的 [設定] 圖示,從 [目錄 + 訂用帳戶] 功能表切換至您的 Azure AD B2C 租使用者。
- 選擇 Azure 入口網站 左上角的 [所有服務],然後搜尋並選取 [Azure AD B2C]。
- 選取 [ 使用者流程]。
- 開啟您先前建立的使用者流程。
- 選取 [屬性] 。
- 在註銷要求中啟用 [需要標識符令牌]。
若要要求註銷要求中的標識碼令牌,請在 RelyingParty 元素內新增 UserJourneyBehaviors 元素。 然後將 SingleSignOn 元素的 EnforceIdTokenHintOnLogout 設定為 true
。 如需詳細資訊,請參閱 實時示範。 您的 UserJourneyBehaviors 元素看起來應該像下列範例:
<UserJourneyBehaviors>
<SingleSignOn Scope="Tenant" EnforceIdTokenHintOnLogout="true"/>
</UserJourneyBehaviors>
若要設定您的應用程式註銷 URL:
- 選取 [應用程式註冊],然後選取您的應用程式。
- 選取驗證。
- 在 [ 註銷 URL] 文本框中,輸入您的註銷后重新導向 URI,然後選取 [ 儲存]。
下一步
- 瞭解如何 在 Azure AD B2C 中設定令牌。