共用方式為


使用 Azure Active Directory B2C 以LinkedIn帳戶設定註冊和登入

開始之前,請使用 [選擇原則類型 選取器] 來選擇您要設定的原則類型。 Azure Active Directory B2C 提供兩種方法來定義使用者如何與您的應用程式互動:透過預先 定義的使用者流程 ,或透過完全可設定 的自定義原則。 本文中每個方法所需的步驟都不同。

注意

在 Azure Active Directory B2C 中, 自定義原則 的設計主要是為了解決複雜的案例。 在大部分情況下,我們建議您使用內 建的使用者流程。 如果您尚未這麼做,請了解開始使用 Active Directory B2C 中的自定義原則入門套件。

必要條件

建立LinkedIn應用程式

若要在 Azure Active Directory B2C (Azure AD B2C) 中啟用具有LinkedIn帳戶的使用者登入,您必須在 LinkedIn 開發人員網站建立應用程式。 如需詳細資訊,請參閱 授權碼流程。 如果您還沒有LinkedIn帳戶,您可以在 註冊 https://www.linkedin.com/

  1. 使用LinkedIn帳戶認證登入 LinkedIn開發人員網站
  2. 選取 [我的應用程式],然後按兩下 [建立應用程式]。
  3. 輸入 應用程式名稱LinkedIn頁面隱私策略URL應用程式標誌
  4. 同意LinkedIn API使用 規定,然後按兩下 [ 建立應用程式]。
  5. 選取 [驗證] 索引標籤。在 [驗證金鑰] 底下,複製 [用戶端識別符] 和 [客戶端密碼] 的值 您需要這兩者,才能將LinkedIn設定為租使用者中的識別提供者。 用戶端密碼 是重要的安全性認證。
  6. 選取應用程式授權重新導向 URL 旁的編輯鉛筆,然後選取 [新增重新導向 URL]。 輸入 https://your-tenant-name.b2clogin.com/your-tenant-name.onmicrosoft.com/oauth2/authresp。 如果您使用 自訂網域,請輸入 https://your-domain-name/your-tenant-name.onmicrosoft.com/oauth2/authresp。 取代為您的租使用者名稱,並以your-domain-name您的自訂網域取代 your-tenant-name 。 即使租使用者是以 Azure AD B2C 中的大寫字母定義,您也必須在輸入租用戶名稱時使用所有小寫字母。 選取更新
  7. 根據預設,您的LinkedIn應用程式不會針對與登入相關的範圍核准。 若要要求檢閱,請選取 [產品 ] 索引標籤,然後選取 [ 使用LinkedIn登入]。 當檢閱完成時,必要的範圍將會新增至您的應用程式。

    注意

    您可以在 OAuth 2.0 範圍區段中的 [驗證] 索引標籤上,檢視應用程式目前允許的範圍

將LinkedIn設定為識別提供者

  1. 以 Azure AD B2C 租使用者的全域管理員身分登入 Azure 入口網站
  2. 如果您有多個租使用者的存取權,請選取頂端功能表中的 設定 圖示,從 [目錄 + 訂用帳戶] 功能表切換至您的 Azure AD B2C 租使用者。
  3. 選擇 Azure 入口網站 左上角的 [所有服務],搜尋並選取 [Azure AD B2C]。
  4. 選取 [ 識別提供者],然後選取 [LinkedIn]。
  5. 輸入名稱。 例如, LinkedIn
  6. 針對 [ 用戶端識別符],輸入您稍早建立之LinkedIn應用程式的用戶端標識符。
  7. 針對 [ 客戶端密碼],輸入您記錄的 [用戶端密碼]。
  8. 選取 [儲存]。

將LinkedIn識別提供者新增至使用者流程

此時,已設定LinkedIn識別提供者,但尚未在任何登入頁面中提供。 若要將LinkedIn識別提供者新增至使用者流程:

  1. 在您的 Azure AD B2C 租使用者中,選取 [ 使用者流程]。
  2. 按兩下您要新增LinkedIn識別提供者的使用者流程。
  3. 在 [ 社交識別提供者] 底下,選取 [LinkedIn]。
  4. 選取 [儲存]。
  5. 若要測試您的原則,請選取 [ 執行使用者流程]。
  6. 針對 [ 應用程式],選取您先前註冊的名為 testapp1 的Web應用程式。 回覆 URL 應該會顯示 https://jwt.ms
  7. 選取 [ 執行使用者流程 ] 按鈕。
  8. 從 [註冊或登入] 頁面中,選取 [LinkedIn 以LinkedIn帳戶登入。

如果登入程式成功,您的瀏覽器會重新導向至 https://jwt.ms,以顯示 Azure AD B2C 所傳回令牌的內容。

建立原則金鑰

您必須儲存您先前在 Azure AD B2C 租用戶中記錄的客戶端密碼。

  1. 登入 Azure 入口網站
  2. 如果您有多個租使用者的存取權,請選取頂端功能表中的 [設定] 圖示,從 [目錄 + 訂用帳戶] 功能表切換至您的 Azure AD B2C 租使用者。
  3. 選擇 Azure 入口網站 左上角的 [所有服務],然後搜尋並選取 [Azure AD B2C]。
  4. 在 [概觀] 頁面上,選取 [ 身分識別體驗架構]。
  5. 選取 [ 原則密鑰 ],然後選取 [ 新增]。
  6. 針對 [ 選項],選擇 Manual
  7. 輸入 原則金鑰的 [名稱 ]。 例如: LinkedInSecret前置詞B2C_1A_會自動新增至金鑰的名稱。
  8. 在 [ 秘密] 中,輸入您先前記錄的客戶端密碼。
  9. 針對 [ 金鑰使用方式],選取 Signature
  10. 按一下 [建立]。

將LinkedIn設定為識別提供者

若要讓使用者使用LinkedIn帳戶登入,您必須將帳戶定義為 Azure AD B2C 可以透過端點通訊的宣告提供者。 端點提供一組宣告,供 Azure AD B2C 用來驗證特定使用者已驗證。

將LinkedIn帳戶新增至 原則延伸檔案中的 ClaimsProviders 元素,將它定義為宣告提供者。

  1. 編輯器中開啟 SocialAndLocalAccounts/TrustFrameworkExtensions.xml 檔案。 此檔案位於 您在其中一個必要條件中下載的自定義原則入門套件 中。

  2. 尋找 ClaimsProviders 元素。 如果不存在,請在根元素底下新增它。

  3. 新增 ClaimsProvider,如下所示:

    <ClaimsProvider>
      <Domain>linkedin.com</Domain>
      <DisplayName>LinkedIn</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="LinkedIn-OAuth2">
          <DisplayName>LinkedIn</DisplayName>
          <Protocol Name="OAuth2" />
          <Metadata>
            <Item Key="ProviderName">linkedin</Item>
            <Item Key="authorization_endpoint">https://www.linkedin.com/oauth/v2/authorization</Item>
            <Item Key="AccessTokenEndpoint">https://www.linkedin.com/oauth/v2/accessToken</Item>
            <Item Key="ClaimsEndpoint">https://api.linkedin.com/v2/me</Item>
            <Item Key="scope">r_emailaddress r_liteprofile</Item>
            <Item Key="HttpBinding">POST</Item>
            <Item Key="external_user_identity_claim_id">id</Item>
            <Item Key="BearerTokenTransmissionMethod">AuthorizationHeader</Item>
            <Item Key="ResolveJsonPathsInJsonTokens">true</Item>
            <Item Key="UsePolicyInRedirectUri">false</Item>
            <Item Key="client_id">Your LinkedIn application client ID</Item>
          </Metadata>
          <CryptographicKeys>
            <Key Id="client_secret" StorageReferenceId="B2C_1A_LinkedInSecret" />
          </CryptographicKeys>
          <InputClaims />
          <OutputClaims>
            <OutputClaim ClaimTypeReferenceId="issuerUserId" PartnerClaimType="id" />
            <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="firstName.localized" />
            <OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="lastName.localized" />
            <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="linkedin.com" AlwaysUseDefaultValue="true" />
            <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
          </OutputClaims>
          <OutputClaimsTransformations>
            <OutputClaimsTransformation ReferenceId="ExtractGivenNameFromLinkedInResponse" />
            <OutputClaimsTransformation ReferenceId="ExtractSurNameFromLinkedInResponse" />
            <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
            <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
            <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
            <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
          </OutputClaimsTransformations>
          <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>
    
  4. 將 client_id的值取代為您先前記錄之LinkedIn應用程式的用戶端識別碼。

  5. 儲存檔案。

新增宣告轉換

LinkedIn技術配置檔需要 ExtractGivenNameFromLinkedInResponseExtractSurNameFromLinkedInResponse 宣告轉換,才能新增至 ClaimsTransformations 列表。 如果您沒有 在檔案中定義的 ClaimsTransformations 元素,請新增父 XML 元素,如下所示。 宣告轉換也需要名為 nullStringClaim 的新宣告類型。

TrustFrameworkExtensions.xml 檔案頂端附近新增 BuildingBlocks 元素。 如需範例,請參閱 TrustFrameworkBase.xml

<BuildingBlocks>
  <ClaimsSchema>
    <!-- Claim type needed for LinkedIn claims transformations -->
    <ClaimType Id="nullStringClaim">
      <DisplayName>nullClaim</DisplayName>
      <DataType>string</DataType>
      <AdminHelpText>A policy claim to store output values from ClaimsTransformations that aren't useful. This claim should not be used in TechnicalProfiles.</AdminHelpText>
      <UserHelpText>A policy claim to store output values from ClaimsTransformations that aren't useful. This claim should not be used in TechnicalProfiles.</UserHelpText>
    </ClaimType>
  </ClaimsSchema>

  <ClaimsTransformations>
    <!-- Claim transformations needed for LinkedIn technical profile -->
    <ClaimsTransformation Id="ExtractGivenNameFromLinkedInResponse" TransformationMethod="GetSingleItemFromJson">
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="givenName" TransformationClaimType="inputJson" />
      </InputClaims>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="nullStringClaim" TransformationClaimType="key" />
        <OutputClaim ClaimTypeReferenceId="givenName" TransformationClaimType="value" />
      </OutputClaims>
    </ClaimsTransformation>
    <ClaimsTransformation Id="ExtractSurNameFromLinkedInResponse" TransformationMethod="GetSingleItemFromJson">
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="surname" TransformationClaimType="inputJson" />
      </InputClaims>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="nullStringClaim" TransformationClaimType="key" />
        <OutputClaim ClaimTypeReferenceId="surname" TransformationClaimType="value" />
      </OutputClaims>
    </ClaimsTransformation>
  </ClaimsTransformations>
</BuildingBlocks>

新增使用者旅程圖

此時,識別提供者已設定,但尚未在任何登入頁面中提供。 如果您沒有自己的自定義使用者旅程圖,請建立現有範本使用者旅程圖的重複項目,否則請繼續進行下一個步驟。

  1. 從入門套件開啟 TrustFrameworkBase.xml 檔案。
  2. 尋找並複製包含 Id="SignUpOrSignIn"之 UserJourney 元素的整個內容
  3. 開啟 TrustFrameworkExtensions.xml 並尋找 UserJourneys 元素。 如果專案不存在,請新增一個。
  4. 貼上您複製為 UserJourneys 元素子系之 UserJourney 元素整個內容。
  5. 重新命名使用者旅程圖的標識碼。 例如: Id="CustomSignUpSignIn"

將識別提供者新增至使用者旅程圖

現在您已擁有使用者旅程圖,請將新的識別提供者新增至使用者旅程圖。 您必須先新增登入按鈕,然後將按鈕連結至動作。 動作是您稍早建立的技術配置檔。

  1. 尋找在 Type="CombinedSignInAndSignUp"使用者旅程圖中包含 或 Type="ClaimsProviderSelection" 的協調流程步驟元素。 通常是第一個協調流程步驟。 ClaimsProviderSelections 元素包含使用者可以登入的識別提供者清單。 元素的順序會控制向用戶呈現的登入按鈕順序。 新增 ClaimsProviderSelection XML 元素。 將 TargetClaimsExchangeId 的值設定為易記名稱。

  2. 在下一個 協調流程步驟中,新增 ClaimsExchange 元素。 將標識符設定為目標宣告交換標識碼的值。將TechnicalProfileReferenceId的值更新為您稍早建立之技術配置檔的標識碼。

下列 XML 示範使用者旅程圖的前兩個協調流程步驟與識別提供者:

<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
  <ClaimsProviderSelections>
    ...
    <ClaimsProviderSelection TargetClaimsExchangeId="LinkedInExchange" />
  </ClaimsProviderSelections>
  ...
</OrchestrationStep>

<OrchestrationStep Order="2" Type="ClaimsExchange">
  ...
  <ClaimsExchanges>
    <ClaimsExchange Id="LinkedInExchange" TechnicalProfileReferenceId="LinkedIn-OAuth2" />
  </ClaimsExchanges>
</OrchestrationStep>

設定信賴憑證者原則

信賴憑證者原則,例如 SignUpSignIn.xml,會指定 Azure AD B2C 將執行的使用者旅程圖。 尋找信賴憑證者內的DefaultUserJourney元素。 更新 ReferenceId 以符合您新增識別提供者的使用者旅程圖標識碼。

在下列範例中 CustomSignUpSignIn ,針對使用者旅程圖, ReferenceId 會設定為 CustomSignUpSignIn

<RelyingParty>
  <DefaultUserJourney ReferenceId="CustomSignUpSignIn" />
  ...
</RelyingParty>

上傳自定義原則

  1. 登入 Azure 入口網站
  2. 在入口網站工具列中選取 [ 目錄 + 訂 用帳戶] 圖示,然後選取包含 Azure AD B2C 租使用者的目錄。
  3. 在 Azure 入口網站中,搜尋並選取 [Azure AD B2C]
  4. 在 [原則] 底下,選取 [身分識別體驗架構]。
  5. 選取 [ 上傳自定義原則],然後上傳您變更的兩個原則檔案,順序如下:擴充原則,例如 TrustFrameworkExtensions.xml,然後是信賴憑證者原則,例如 SignUpSignIn.xml

測試您的自定義原則

  1. 選取您的信賴憑證者原則,例如 B2C_1A_signup_signin
  2. 針對 [ 應用程式],選取您 先前註冊的 Web 應用程式。 回覆 URL 應該會顯示 https://jwt.ms
  3. 選取 [ 立即 執行] 按鈕。
  4. 從 [註冊或登入] 頁面中,選取 [LinkedIn 以LinkedIn帳戶登入。

如果登入程式成功,您的瀏覽器會重新導向至 https://jwt.ms,以顯示 Azure AD B2C 所傳回令牌的內容。

從 v1.0 移轉至 v2.0

LinkedIn最近 將其 API 從 v1.0 更新為 v2.0。 若要將現有的組態移轉至新的組態,請使用下列各節中的資訊來更新技術配置檔中的元素。

取代元數據中的專案

在 TechnicalProfile 的現有 Metadata 元素中,從 更新下列 Item 元素:

<Item Key="ClaimsEndpoint">https://api.linkedin.com/v1/people/~:(id,first-name,last-name,email-address,headline)</Item>
<Item Key="scope">r_emailaddress r_basicprofile</Item>

變更為:

<Item Key="ClaimsEndpoint">https://api.linkedin.com/v2/me</Item>
<Item Key="scope">r_emailaddress r_liteprofile</Item>

將專案新增至元數據

TechnicalProfile 的元數據,新增下列 Item 元素:

<Item Key="external_user_identity_claim_id">id</Item>
<Item Key="BearerTokenTransmissionMethod">AuthorizationHeader</Item>
<Item Key="ResolveJsonPathsInJsonTokens">true</Item>

更新 OutputClaims

在 TechnicalProfile 的現有 OutputClaims 中,從更新下列 OutputClaim 元素:

<OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="firstName" />
<OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="lastName" />

變更為:

<OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="firstName.localized" />
<OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="lastName.localized" />

新增 OutputClaimsTransformation 元素

在 TechnicalProfile 的 OutputClaimsTransformations 中,新增下列 OutputClaimsTransformation 元素:

<OutputClaimsTransformation ReferenceId="ExtractGivenNameFromLinkedInResponse" />
<OutputClaimsTransformation ReferenceId="ExtractSurNameFromLinkedInResponse" />

定義新的宣告轉換和宣告類型

在最後一個步驟中,您已新增需要定義的宣告轉換。 若要定義宣告轉換,請將這些轉換新增至 ClaimsTransformations 清單。 如果您沒有 在檔案中定義的 ClaimsTransformations 元素,請新增父 XML 元素,如下所示。 宣告轉換也需要名為 nullStringClaim 的新宣告類型。

BuildingBlocks 元素應該新增在檔案頂端附近。 請參閱 TrustframeworkBase.xml 作為範例。

<BuildingBlocks>
  <ClaimsSchema>
    <!-- Claim type needed for LinkedIn claims transformations -->
    <ClaimType Id="nullStringClaim">
      <DisplayName>nullClaim</DisplayName>
      <DataType>string</DataType>
      <AdminHelpText>A policy claim to store unuseful output values from ClaimsTransformations. This claim should not be used in a TechnicalProfiles.</AdminHelpText>
      <UserHelpText>A policy claim to store unuseful output values from ClaimsTransformations. This claim should not be used in a TechnicalProfiles.</UserHelpText>
    </ClaimType>
  </ClaimsSchema>

  <ClaimsTransformations>
    <!-- Claim transformations needed for LinkedIn technical profile -->
    <ClaimsTransformation Id="ExtractGivenNameFromLinkedInResponse" TransformationMethod="GetSingleItemFromJson">
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="givenName" TransformationClaimType="inputJson" />
      </InputClaims>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="nullStringClaim" TransformationClaimType="key" />
        <OutputClaim ClaimTypeReferenceId="givenName" TransformationClaimType="value" />
      </OutputClaims>
    </ClaimsTransformation>
    <ClaimsTransformation Id="ExtractSurNameFromLinkedInResponse" TransformationMethod="GetSingleItemFromJson">
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="surname" TransformationClaimType="inputJson" />
      </InputClaims>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="nullStringClaim" TransformationClaimType="key" />
        <OutputClaim ClaimTypeReferenceId="surname" TransformationClaimType="value" />
      </OutputClaims>
    </ClaimsTransformation>
  </ClaimsTransformations>
</BuildingBlocks>

取得電子郵件位址

LinkedIn從 v1.0 移轉至 v2.0 時,需要對另一個 API 進行額外的呼叫,才能取得電子郵件位址。 如果您需要在註冊期間取得電子郵件位址,請執行下列動作:

  1. 完成上述步驟,以允許 Azure AD B2C 與LinkedIn同盟,讓使用者登入。 作為同盟的一部分,Azure AD B2C 會接收LinkedIn的存取令牌。

  2. 將LinkedIn存取令牌儲存到宣告中。 請參閱這裡的指示。

  3. 新增下列宣告提供者,以向LinkedIn的 /emailAddress API 提出要求。 若要授權此要求,您需要LinkedIn存取令牌。

    <ClaimsProvider>
      <DisplayName>REST APIs</DisplayName>
      <TechnicalProfiles>
        <TechnicalProfile Id="API-LinkedInEmail">
          <DisplayName>Get LinkedIn email</DisplayName>
          <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
          <Metadata>
              <Item Key="ServiceUrl">https://api.linkedin.com/v2/emailAddress?q=members&amp;projection=(elements*(handle~))</Item>
              <Item Key="AuthenticationType">Bearer</Item>
              <Item Key="UseClaimAsBearerToken">identityProviderAccessToken</Item>
              <Item Key="SendClaimsIn">Url</Item>
              <Item Key="ResolveJsonPathsInJsonTokens">true</Item>
          </Metadata>
          <InputClaims>
              <InputClaim ClaimTypeReferenceId="identityProviderAccessToken" />
          </InputClaims>
          <OutputClaims>
              <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="elements[0].handle~.emailAddress" />
          </OutputClaims>
          <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
        </TechnicalProfile>
      </TechnicalProfiles>
    </ClaimsProvider>
    
  4. 將下列協調流程步驟新增至您的使用者旅程圖,以便在使用者使用LinkedIn登入時觸發API宣告提供者。 請務必適當地更新 Order 號碼。 在觸發LinkedIn技術配置檔的協調流程步驟之後,立即新增此步驟。

    <!-- Extra step for LinkedIn to get the email -->
    <OrchestrationStep Order="3" Type="ClaimsExchange">
      <Preconditions>
        <Precondition Type="ClaimsExist" ExecuteActionsIf="false">
          <Value>identityProvider</Value>
          <Action>SkipThisOrchestrationStep</Action>
        </Precondition>
        <Precondition Type="ClaimEquals" ExecuteActionsIf="false">
          <Value>identityProvider</Value>
          <Value>linkedin.com</Value>
          <Action>SkipThisOrchestrationStep</Action>
        </Precondition>
      </Preconditions>
      <ClaimsExchanges>
        <ClaimsExchange Id="GetEmail" TechnicalProfileReferenceId="API-LinkedInEmail" />
      </ClaimsExchanges>
    </OrchestrationStep>
    

在註冊期間從LinkedIn取得電子郵件地址是選擇性的。 如果您選擇不從LinkedIn取得電子郵件,但在註冊期間需要一封電子郵件,則用戶必須手動輸入電子郵件位址並加以驗證。

如需使用LinkedIn識別提供者之原則的完整範例,請參閱 自定義原則入門套件

從 v1.0 移轉至 v2.0

LinkedIn最近 將其 API 從 v1.0 更新為 v2.0。 在移轉過程中,Azure AD B2C 只能在註冊期間取得LinkedIn使用者的完整名稱。 如果電子郵件地址是註冊期間收集的屬性之一,用戶必須手動輸入電子郵件位址並加以驗證。