Настройка регистрации и входа с помощью учетной записи LinkedIn - Azure AD B2C

2025-05-02

Это важно

Начиная с 1 мая 2025 г. Azure AD B2C больше не будет доступен для приобретения для новых клиентов. Дополнительные сведения см. в разделе "Вопросы и ответы".

Прежде чем начать, используйте селектор типа политики в верхней части этой страницы, чтобы выбрать тип политики, которую вы настроите. Azure Active Directory B2C предлагает два метода определения способа взаимодействия пользователей с вашими приложениями: с помощью предопределенных потоков пользователей или полностью настраиваемых пользовательских политик. Действия, которые необходимо выполнить, отличаются для каждого метода.

Замечание

В Azure Active Directory B2C пользовательские политики преимущественно предназначены для выполнения сложных сценариев. В большинстве случаев рекомендуется использовать встроенные потоки пользователей. Ознакомьтесь со статьей Начало работы с настраиваемыми политиками в Azure Active Directory B2C, чтобы узнать о базовом пакете настраиваемых политик, если еще не сделали этого.

Предпосылки

Создайте поток пользователя, чтобы пользователи могли зарегистрироваться и входить в ваше приложение.
Зарегистрируйте веб-приложение.

Выполните действия, описанные в статье "Начало работы с настраиваемыми политиками в Active Directory B2C". В этом руководстве описано, как обновить пользовательские файлы политики для использования конфигурации клиента Azure AD B2C.
Зарегистрируйте веб-приложение.

Создание приложения LinkedIn

Чтобы включить вход для пользователей с учетной записью LinkedIn в Azure Active Directory B2C (Azure AD B2C), необходимо создать приложение на веб-сайте LinkedIn Developers. Если у вас еще нет учетной записи LinkedIn, вы можете зарегистрироваться по адресу https://www.linkedin.com/.

Войдите на веб-сайт LinkedIn Developers с учетными данными учетной записи LinkedIn.
Выберите "Мои приложения" и нажмите кнопку "Создать приложение".
Введите имя приложения, страницу LinkedIn, URL-адрес политики конфиденциальности и логотип приложения.
Примите условия использования API LinkedIn и нажмите кнопку "Создать приложение".
Перейдите на вкладку "Проверка подлинности ". В разделе "Ключи проверки подлинности" скопируйте значения идентификатора клиента и секрета клиента. Вам потребуется оба из них, чтобы настроить 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-tenant-name именем клиента и your-domain-name личным доменом. При вводе имени клиента необходимо использовать все строчные буквы, даже если клиент определен с прописными буквами в Azure AD B2C. Выберите Обновить.
По умолчанию ваше приложение LinkedIn не имеет разрешения на области, связанные с авторизацией. Чтобы запросить проверку, перейдите на вкладку "Продукты" и выберите "Войти в LinkedIn" с помощью OpenID Connect. По завершении проверки необходимые области будут добавлены в приложение.

Замечание

Вы можете просмотреть области, которые в настоящее время разрешены для приложения на вкладке "Проверка подлинности " в разделе областей OAuth 2.0 .

Настройка LinkedIn в качестве поставщика удостоверений

Войдите на портал Azure с учетной записью, которая имеет по крайней мере права администратора внешнего поставщика удостоверений .
Если у вас есть доступ к нескольким клиентам, щелкните значок Настройки в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню Каталоги и подписки.
В настройках портала на странице Каталоги и подписки найдите свой каталог Azure AD B2C в списке Имя каталога и выберите Переключить.
Выберите все службы в левом верхнем углу портала Azure, найдите и выберите Azure AD B2C.
Выберите поставщики удостоверений, а затем выберите новый поставщик OpenID Connect.
Введите Имя. Например, LinkedIn-OIDC.
Введите https://www.linkedin.com/oauth/.well-known/openid-configuration.
В поле идентификатора клиента введите идентификатор клиента созданного ранее приложения LinkedIn.
В качестве секрета клиента введите секрет клиента, записанный ранее.
В поле "Область" введите openid profile email.
Введите код для типа ответа.
Введите адрес электронной почты для идентификатора пользователя.
В поле Отображаемое имя введите имя.
В поле "Заданное имя" введите given_name.
Для фамилии введите family_name.
В поле "Электронная почта" введите сообщение электронной почты.
Нажмите кнопку "Сохранить".

Добавление поставщика удостоверений LinkedIn в поток пользователя

На этом этапе поставщик удостоверений LinkedIn был настроен, но он еще не доступен на любой из страниц входа. Чтобы добавить поставщика удостоверений LinkedIn в поток пользователя:

В клиенте Azure AD B2C выберите потоки пользователей.
Щелкните поток пользователя, в который вы хотите добавить поставщика удостоверений LinkedIn.
В разделе "Пользовательские поставщики удостоверений" выберите LinkedIn-OIDC.
Нажмите кнопку "Сохранить".
Чтобы протестировать вашу политику, выберите Запустить поток пользователя.
Для приложения выберите веб-приложение с именем testapp1 , которое вы ранее зарегистрировали. В поле URL-адрес ответа должно содержаться значение https://jwt.ms.
Нажмите на кнопку Запустить пользовательский поток.
На странице регистрации или входа выберите LinkedIn-OIDC , чтобы войти с помощью учетной записи LinkedIn.

Если процесс входа выполнен успешно, браузер перенаправляется на https://jwt.ms, где отображается содержимое токена, возвращаемого Azure AD B2C.

Создание ключа политики

Необходимо сохранить секрет клиента, записанный ранее в клиенте Azure AD B2C.

Войдите на портал Azure.
Если у вас есть доступ к нескольким клиентам, щелкните значок Настройки в верхнем меню, чтобы переключиться на клиент Azure AD B2C из меню Каталоги и подписки.
В настройках портала на странице Каталоги и подписки найдите свой каталог Azure AD B2C в списке Имя каталога и выберите Переключить.
Выберите все службы в левом верхнем углу портала Azure, а затем найдите и выберите Azure AD B2C.
На странице "Обзор" выберите Identity Experience Framework.
Выберите ключи политики и нажмите кнопку "Добавить".
В разделе "Параметры" выберите Manual.
Введите имя для ключа политики. Например: LinkedInSecret. Префикс B2C_1A_ добавляется автоматически в имя ключа.
В поле Secret введите секрет клиента, который вы записали ранее.
Для использования ключа выберите Signature.
Нажмите кнопку Создать.

Настройка LinkedIn в качестве поставщика удостоверений

Чтобы пользователи могли войти с помощью учетной записи LinkedIn, необходимо определить учетную запись в качестве поставщика утверждений, с которым Azure AD B2C может взаимодействовать через конечную точку. Конечная точка предоставляет набор утверждений, используемых Azure AD B2C для проверки подлинности определенного пользователя.

Определите учетную запись LinkedIn в качестве поставщика утверждений, добавив ее в элемент ClaimsProviders в файле расширения политики.

Откройте файл SocialAndLocalAccounts/TrustFrameworkExtensions.xml в редакторе. Этот файл находится в начальном пакете настраиваемой политики , который вы скачали в рамках одного из предварительных требований.
Найдите элемент ClaimsProviders . Если он не существует, добавьте его в корневой элемент.

Добавьте новый ClaimsProvider следующим образом:

<ClaimsProvider>
  <Domain>linkedin.com</Domain>
  <DisplayName>LinkedIn-OIDC</DisplayName>
  <TechnicalProfiles>
      <TechnicalProfile Id="LinkedIn-OIDC">
      <DisplayName>LinkedIn</DisplayName>
      <Protocol Name="OpenIdConnect" />
      <Metadata>
          <Item Key="METADATA">https://www.linkedin.com/oauth/.well-known/openid-configuration</Item>
          <Item Key="scope">openid profile email</Item>
          <Item Key="HttpBinding">POST</Item>
          <Item Key="response_types">code</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="email" />
          <OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
          <OutputClaim ClaimTypeReferenceId="surname" PartnerClaimType="family_name" />
          <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="linkedin.com" AlwaysUseDefaultValue="true" />
          <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" />
      </OutputClaims>
      <OutputClaimsTransformations>
          <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
          <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
          <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
          <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
      </OutputClaimsTransformations>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
      </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Замените значение client_id идентификатором клиента приложения LinkedIn, записанного ранее.
Сохраните файл.

Добавить пользовательский сценарий

На этом этапе поставщик удостоверений настроен, но он еще не доступен на любой из страниц входа. Если у вас нет собственного пользовательского пути, создайте дубликат существующего пути пользователя шаблона, в противном случае перейдите к следующему шагу.

Откройте файлTrustFrameworkBase.xml из начального пакета.
Найдите и скопируйте все содержимое элемента UserJourney , который включает в себя Id="SignUpOrSignIn".
Откройте TrustFrameworkExtensions.xml и найдите элемент UserJourneys . Если элемент не существует, добавьте его.
Вставьте все содержимое элемента UserJourney , скопированного в качестве дочернего элемента UserJourneys .
Переименуйте идентификатор пути пользователя. Например: Id="CustomSignUpSignIn".

Добавьте поставщика удостоверений в путь пользователя

Теперь, когда у вас есть путь пользователя, добавьте нового поставщика идентификации в этот путь. Сначала вы добавляете кнопку входа, а затем связываете кнопку с действием. Действие — это технический профиль, который вы создали ранее.

Найдите элемент шага оркестрации, который включает в себя Type="CombinedSignInAndSignUp" или Type="ClaimsProviderSelection" в процессе работы пользователя. Обычно это первый шаг оркестрации. Элемент ClaimsProviderSelections содержит список поставщиков удостоверений, с которыми пользователь может войти. Порядок элементов определяет порядок кнопок входа, представленных пользователю. Добавьте XML-элемент ClaimsProviderSelection . Задайте для параметра TargetClaimsExchangeId понятное имя.
На следующем шаге оркестрации добавьте элемент ClaimsExchange . Установите Id на значение идентификатора целевого обмена утверждениями. Обновите значение 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-OIDC" />
  </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.
В разделе "Политики" выберите Identity Experience Framework.
Выберите " Отправить настраиваемую политику", а затем отправьте два измененных файла политики в следующем порядке: политика расширения, например TrustFrameworkExtensions.xml, политика проверяющей стороны, например SignUpSignIn.xml.

Проверка настраиваемой политики

Выберите политику доверенной стороны, например B2C_1A_signup_signin.
Для приложения выберите веб-приложение, которое вы ранее зарегистрировали. В поле URL-адрес ответа должно содержаться значение https://jwt.ms.
Нажмите кнопку "Запустить сейчас ".
На странице регистрации или входа выберите LinkedIn-OIDC , чтобы войти с помощью учетной записи LinkedIn.

Миграция с версии 1.0 на версию 2.0

LinkedIn недавно обновил api с версии 1.0 до версии 2.0. Чтобы перенести существующую конфигурацию в новую конфигурацию, используйте сведения в следующих разделах, чтобы обновить элементы в техническом профиле.

Замена элементов в метаданных

В существующем элементе метаданныхTechnicalProfile обновите следующие элементы 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

В существующих элементах OutputClaimsTechnicalProfile обновите следующие элементы OutputClaim из:

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

Кому:

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

Добавьте новые элементы OutputClaimsTransformation

В OutputClaimsTransformationsTechnicalProfile добавьте следующие элементы 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 с версии 1.0 на версии 2.0 требуется дополнительный вызов к другому API для получения адреса электронной почты. Если во время регистрации необходимо получить адрес электронной почты, сделайте следующее:

Выполните описанные выше действия, чтобы настроить взаимодействие Azure AD B2C с LinkedIn, позволяющее пользователю войти в систему. В рамках федерации Azure AD B2C получает маркер доступа для LinkedIn.
Сохраните токен доступа LinkedIn в претензию. См. инструкции здесь.

Добавьте следующего поставщика утверждений, выполняющего запрос к API LinkedIn /emailAddress. Чтобы авторизовать этот запрос, требуется маркер доступа 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>

Добавьте следующий шаг оркестрации в путешествие пользователя, чтобы поставщик утверждений API активировался при входе пользователя с помощью LinkedIn. Обязательно обновите 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, см. в начальном пакете пользовательской политики.

Миграция с версии 1.0 на версию 2.0

LinkedIn недавно обновил api с версии 1.0 до версии 2.0. В рамках миграции Azure AD B2C может получить полное имя пользователя LinkedIn во время регистрации. Если адрес электронной почты является одним из атрибутов, собранных во время регистрации, пользователь должен вручную ввести адрес электронной почты и проверить его.

Поделиться через

Настройка регистрации и входа с помощью учетной записи LinkedIn с помощью Azure Active Directory B2C

Предпосылки

Создание приложения LinkedIn

Настройка LinkedIn в качестве поставщика удостоверений

Добавление поставщика удостоверений LinkedIn в поток пользователя

Создание ключа политики

Настройка LinkedIn в качестве поставщика удостоверений

Добавить пользовательский сценарий

Добавьте поставщика удостоверений в путь пользователя

Настройте политику доверяющей стороны

Отправка настраиваемой политики

Проверка настраиваемой политики

Миграция с версии 1.0 на версию 2.0

Замена элементов в метаданных

Добавление элементов в метаданные

Обновите OutputClaims

Добавьте новые элементы OutputClaimsTransformation

Определение новых преобразований утверждений и типа утверждений

Получение адреса электронной почты

Миграция с версии 1.0 на версию 2.0

Обратная связь

Дополнительные ресурсы