重要
2025 年 5 月 1 日より、Azure AD B2C は新規のお客様向けに購入できなくなります。 詳細については、FAQ を参照してください。
開始する前にこのページの上部にある ポリシーの種類 セレクターを使用して、設定するポリシーの種類を選択します。 Azure Active Directory B2C には、ユーザーがアプリケーションを操作する方法を定義する 2 つの方法 (定義済みのユーザー フローを使用する、または完全に構成可能なカスタム ポリシーを使用する) があります。 この記事で必要な手順は、方法ごとに異なります。
注
Azure Active Directory B2C で、カスタム ポリシーは、主に、複雑なシナリオに取り組む用途向けに設計されています。 ほとんどのシナリオで、組み込みユーザー フローを使用することをお勧めします。 まだ行っていない場合は、Active Directory B2C でのカスタム ポリシーの概要に関する記事で、カスタム ポリシー スターター パックの詳細を確認してください。
[前提条件]
- ユーザーが サインアップしてアプリケーションにサインインできるように、ユーザー フローを作成します。
- Web アプリケーションを登録します。
- 「Active Directory B2C でのカスタム ポリシーの概要」の手順を完了してください。 このチュートリアルでは、Azure AD B2C テナント構成を使用するようにカスタム ポリシー ファイルを更新する方法について説明します。
- Web アプリケーションを登録します。
LinkedIn アプリケーションを作成する
Azure Active Directory B2C (Azure AD B2C) で LinkedIn アカウントを持つユーザーのサインインを有効にするには、 LinkedIn Developers Web サイトでアプリケーションを作成する必要があります。 LinkedIn アカウントをまだお持ちでない場合は、 https://www.linkedin.com/でサインアップできます。
- LinkedIn アカウントの資格情報を使用して LinkedIn 開発者 Web サイト にサインインします。
- [ マイ アプリ] を選択し、[ アプリの作成] をクリックします。
- アプリ名、LinkedIn ページ、プライバシー ポリシー URL、アプリ ロゴを入力します。
- LinkedIn API 使用条件 に同意し、[アプリの 作成] をクリックします。
- [ 認証 ] タブを選択します。[ 認証キー] で、[ クライアント ID ] と [ クライアント シークレット] の値をコピーします。 テナントで ID プロバイダーとして 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 アプリはサインインに関連するスコープに対して承認されていません。 レビューを要求するには、[ 製品 ] タブを選択し、[ OpenID Connect を使用して LinkedIn でサインイン] を選択します。 レビューが完了すると、必要なスコープがアプリケーションに追加されます。
注
OAuth 2.0 スコープ セクションの [認証] タブで、アプリで現在許可されているスコープを表示できます。
LinkedIn を ID プロバイダーとして構成する
- 少なくとも外部 ID プロバイダー管理者特権を持つアカウントで Azure portal にサインインします。
- 複数のテナントにアクセスできる場合、上部のメニューの [設定] アイコンを選択し、[ディレクトリとサブスクリプション] メニューからお使いの Azure AD B2C テナントに切り替えます。
- [ポータルの設定] | [Directories + subscriptions](ディレクトリ + サブスクリプション) ページの [ディレクトリ名] の一覧で自分の Azure AD B2C ディレクトリを見つけて、 [切り替え] を選択します。
- Azure portal の左上隅にある [ すべてのサービス ] を選択し、 Azure AD B2C を検索して選択します。
- [ ID プロバイダー] を選択し、[ 新しい OpenID Connect プロバイダー] を選択します。
- 名前を入力します。 たとえば、 LinkedIn-OIDC です。
- メタデータ URL に「https://www.linkedin.com/oauth/.well-known/openid-configuration」と入力します。
- クライアント ID には、先ほど作成した LinkedIn アプリケーションのクライアント ID を入力します。
- クライアント シークレットの場合は、記録したクライアント シークレットを入力します。
- [スコープ] に、openid プロファイルの電子メールを入力します。
- 応答の 種類として、 コードを入力します。
- ユーザー ID には、電子メールを入力します。
- [表示名] に「name」と入力します。
- [ 指定した名前] に「 given_name」と入力します。
- 姓に「family_name」と入力します。
- [電子メール] に「Email」と入力します。
- 保存 を選択します。
LinkedIn ID プロバイダーをユーザー フローに追加する
この時点で、LinkedIn ID プロバイダーは設定されていますが、どのサインイン ページでもまだ使用できません。 LinkedIn ID プロバイダーをユーザー フローに追加するには:
- Azure AD B2C テナントで、[ ユーザー フロー] を選択します。
- LinkedIn ID プロバイダーを追加するユーザー フローをクリックします。
- [カスタム ID プロバイダー] で、[LinkedIn-OIDC] を選択します。
- 保存 を選択します。
- ポリシーをテストするには、[ ユーザー フローの実行] を選択します。
-
[アプリケーション] で、以前に登録した testapp1 という名前の Web アプリケーションを選択します。
応答 URL に
https://jwt.ms
が表示されます。 - [ ユーザー フローの実行 ] ボタンを選択します。
- サインアップまたはサインイン ページで、 LinkedIn-OIDC を選択して LinkedIn アカウントでサインインします。
サインイン プロセスが成功すると、ブラウザーは https://jwt.ms
にリダイレクトされ、Azure AD B2C によって返されるトークンの内容が表示されます。
ポリシー キーを作成する
以前に Azure AD B2C テナントに記録したクライアント シークレットを格納する必要があります。
- Azure portal にサインインします。
- 複数のテナントにアクセスできる場合、上部のメニューの [設定] アイコンを選択し、[ディレクトリとサブスクリプション] メニューからお使いの Azure AD B2C テナントに切り替えます。
- [ポータルの設定] | [Directories + subscriptions](ディレクトリ + サブスクリプション) ページの [ディレクトリ名] の一覧で自分の Azure AD B2C ディレクトリを見つけて、 [切り替え] を選択します。
- Azure portal の左上隅にある [すべてのサービス] を選択してから、[Azure AD B2C] を検索して選択します。
- [概要] ページで、[Identity Experience Framework] を選びます。
- [ ポリシー キー ] を選択し、[追加] を選択 します。
-
[オプション] で、[
Manual
] を選択します。 - ポリシー キーの名前を入力します。 たとえば、
LinkedInSecret
のようにします。 プレフィックス B2C_1A_ は、キーの名前に自動的に追加されます。 - [ シークレット] に、前に記録したクライアント シークレットを入力します。
- [ キーの使用法] で、[
Signature
] を選択します。 - Create をクリックしてください。
LinkedIn を ID プロバイダーとして構成する
ユーザーが LinkedIn アカウントを使用してサインインできるようにするには、Azure AD B2C がエンドポイント経由で通信できるクレーム プロバイダーとしてアカウントを定義する必要があります。 エンドポイントは、特定のユーザーが認証されたことを確認するために Azure AD B2C によって使用されるクレームのセットを提供します。
LinkedIn アカウントをクレーム プロバイダーとして定義するには、それをポリシーの拡張ファイルの ClaimsProviders 要素に追加します。
エディターで SocialAndLocalAccounts/TrustFrameworkExtensions.xml ファイルを開きます。 このファイルは、前提条件の 1 つとしてダウンロードした カスタム ポリシー スターター パック に含まれています。
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 アプリケーションのクライアント ID に置き換えます。
ファイルを保存します。
ユーザー体験を追加する
この時点で、ID プロバイダーは設定されていますが、どのサインイン ページでもまだ使用できません。 独自のカスタム ユーザー体験がない場合は、既存のテンプレート ユーザー体験の複製を作成します。それ以外の場合は、次の手順に進みます。
- スターター パックから TrustFrameworkBase.xml ファイルを開きます。
-
を含む
Id="SignUpOrSignIn"
要素の内容全体を検索してコピーします。 - TrustFrameworkExtensions.xml を開き、UserJourneys 要素を見つけます。 要素が存在しない場合は、要素を追加します。
- UserJourneys 要素の子としてコピーした UserJourney 要素の内容全体を貼り付けます。
- ユーザージャーニーの ID を変更します。 たとえば、
Id="CustomSignUpSignIn"
のようにします。
ID プロバイダーをユーザー体験に追加する
これでユーザー体験が作成されたので、新しい ID プロバイダーをユーザー体験に追加します。 最初にサインイン ボタンを追加し、そのボタンをアクションにリンクします。 あなたが以前に作成した技術プロファイルがこのアクションです。
ユーザー体験に
Type="CombinedSignInAndSignUp"
またはType="ClaimsProviderSelection"
を含むオーケストレーション ステップ要素を見つけます。 通常は、オーケストレーションの最初の手順です。 ClaimsProviderSelections 要素には、ユーザーがサインインできる ID プロバイダーの一覧が含まれています。 要素の順序は、ユーザーに表示されるサインイン ボタンの順序を制御します。 ClaimsProviderSelection XML 要素を追加します。 TargetClaimsExchangeId の値をフレンドリ名に設定します。次のオーケストレーション手順で、 ClaimsExchange 要素を追加します。 Id をターゲット要求交換 ID の値に設定します。TechnicalProfileReferenceId の値を、先ほど作成した技術プロファイルの ID に更新します。
次の XML は、ID プロバイダーを使用したユーザー体験の最初の 2 つのオーケストレーション手順を示しています。
<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 要素を検索します。 追加した ID プロバイダーのユーザージャーニー ID と一致するように ReferenceId を更新します。
次の例では、 CustomSignUpSignIn
ユーザー体験の ReferenceId が CustomSignUpSignIn
に設定されています。
<RelyingParty>
<DefaultUserJourney ReferenceId="CustomSignUpSignIn" />
...
</RelyingParty>
カスタム ポリシーをアップロードする
- Azure portal にサインインします。
- ポータル のツール バーで [ディレクトリ + サブスクリプション ] アイコンを選択し、Azure AD B2C テナントが含まれているディレクトリを選択します。
- Azure portal で、 [Azure AD B2C] を検索して選択します。
- [ ポリシー] で、[ Identity Experience Framework] を選択します。
- [ カスタム ポリシーのアップロード] を選択し、変更した 2 つのポリシー ファイルを次の順序でアップロードします。拡張機能ポリシー (
TrustFrameworkExtensions.xml
など)、証明書利用者ポリシー (SignUpSignIn.xml
など)。
カスタム ポリシーをテストする
- 関連パーティポリシー(例:
B2C_1A_signup_signin
)を選択してください。 - [ アプリケーション] で、 以前に登録した Web アプリケーションを選択します。
応答 URL に
https://jwt.ms
が表示されます。 - [ 今すぐ実行 ] ボタンを選択します。
- サインアップまたはサインイン ページで、 LinkedIn-OIDC を選択して 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>
メール アドレスを取得する
v1.0 から v2.0 への LinkedIn 移行の一環として、電子メール アドレスを取得するには、別の 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&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 ID プロバイダーを使用するポリシーの完全なサンプルについては、 カスタム ポリシー スターター パックを参照してください。
v1.0 から v2.0 への移行
LinkedIn は最近、API を v1.0 から v2.0 に更新しました。 移行の一環として、Azure AD B2C はサインアップ時にのみ LinkedIn ユーザーの完全な名前を取得できます。 電子メール アドレスがサインアップ時に収集される属性の 1 つである場合、ユーザーは電子メール アドレスを手動で入力して検証する必要があります。