使用LinkedIn帳戶設定註冊和登入 - Azure AD B2C

發行項
11/08/2023

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

注意

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

必要條件

建立使用者流程，讓使用者可以註冊並登入您的應用程式。
註冊 Web 應用程式。

完成開始使用 Active Directory B2C 中的自定義原則中的步驟
註冊 Web 應用程式。

建立LinkedIn應用程式

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

使用LinkedIn帳戶認證登入 LinkedIn開發人員網站。
選取 [我的應用程式]，然後按兩下 [建立應用程式]。
輸入 應用程式名稱、 LinkedIn頁面、 隱私策略URL和 應用程式標誌。
同意LinkedIn API使用 規定，然後按兩下 [ 建立應用程式]。
選取 [驗證] 索引標籤。在 [驗證金鑰] 底下，複製 [用戶端識別符] 和 [客戶端密碼] 的值。 您需要這兩者，才能將LinkedIn設定為租使用者中的識別提供者。 用戶端密碼 是重要的安全性認證。
選取應用程式授權重新導向 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 中的大寫字母定義，您也必須在輸入租用戶名稱時使用所有小寫字母。選取更新。
根據預設，您的LinkedIn應用程式不會針對與登入相關的範圍核准。若要要求檢閱，請選取 [產品 ] 索引標籤，然後選取 [ 使用LinkedIn登入]。當檢閱完成時，必要的範圍將會新增至您的應用程式。

注意

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

將LinkedIn設定為識別提供者

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

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

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

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

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

建立原則金鑰

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

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

將LinkedIn設定為識別提供者

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

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

在編輯器中開啟 SocialAndLocalAccounts/TrustFrameworkExtensions.xml 檔案。此檔案位於您在其中一個必要條件中下載的自定義原則入門套件中。
尋找 ClaimsProviders 元素。如果不存在，請在根元素底下新增它。

新增 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>

將 client_id的值取代為您先前記錄之LinkedIn應用程式的用戶端識別碼。
儲存檔案。

新增宣告轉換

LinkedIn技術配置檔需要 ExtractGivenNameFromLinkedInResponse 和 ExtractSurNameFromLinkedInResponse 宣告轉換，才能新增至 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>

新增使用者旅程圖

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

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

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

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

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

上傳自定義原則

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

測試您的自定義原則

選取您的信賴憑證者原則，例如 B2C_1A_signup_signin。
針對 [ 應用程式]，選取您先前註冊的 Web 應用程式。回覆 URL 應該會顯示 https://jwt.ms。
選取 [ 立即執行] 按鈕。
從 [註冊或登入] 頁面中，選取 [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 進行額外的呼叫，才能取得電子郵件位址。如果您需要在註冊期間取得電子郵件位址，請執行下列動作：

完成上述步驟，以允許 Azure AD B2C 與LinkedIn同盟，讓使用者登入。作為同盟的一部分，Azure AD B2C 會接收LinkedIn的存取令牌。
將LinkedIn存取令牌儲存到宣告中。請參閱這裡的指示。

新增下列宣告提供者，以向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>

將下列協調流程步驟新增至您的使用者旅程圖，以便在使用者使用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使用者的完整名稱。如果電子郵件地址是註冊期間收集的屬性之一，用戶必須手動輸入電子郵件位址並加以驗證。

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

必要條件

建立LinkedIn應用程式

將LinkedIn設定為識別提供者

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

建立原則金鑰

將LinkedIn設定為識別提供者

新增宣告轉換

新增使用者旅程圖

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

設定信賴憑證者原則

上傳自定義原則

測試您的自定義原則

從 v1.0 移轉至 v2.0

取代元數據中的專案

將專案新增至元數據

更新 OutputClaims

新增 OutputClaimsTransformation 元素

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

取得電子郵件位址

從 v1.0 移轉至 v2.0

其他資源