重要
2025 年 5 月 1 日より、Azure AD B2C は新規のお客様向けに購入できなくなります。 詳細については、FAQ を参照してください。
開始する前にこのページの上部にある ポリシーの種類 セレクターを使用して、設定するポリシーの種類を選択します。 Azure Active Directory B2C には、ユーザーがアプリケーションを操作する方法を定義する 2 つの方法 (定義済みのユーザー フローを使用する、または完全に構成可能なカスタム ポリシーを使用する) があります。 この記事で必要な手順は、方法ごとに異なります。
注
この機能はパブリック プレビュー段階にあります。
重要
2021 年 5 月以降、GitHub は、Azure AD B2C カスタム ポリシー フェデレーションに影響を与える変更を発表しました。 変更により、 <Item Key="BearerTokenTransmissionMethod">AuthorizationHeader</Item>
メタデータを GitHub 技術プロファイルに追加します。 詳細については、 クエリ パラメーターを使用した API 認証の非推奨化を参照してください。
[前提条件]
- ユーザーが サインアップしてアプリケーションにサインインできるように、ユーザー フローを作成します。
- Web アプリケーションを登録します。
- 「Active Directory B2C でのカスタム ポリシーの概要」の手順を完了してください。 このチュートリアルでは、Azure AD B2C テナント構成を使用するようにカスタム ポリシー ファイルを更新する方法について説明します。
- Web アプリケーションを登録します。
GitHub OAuth アプリケーションを作成する
Azure Active Directory B2C (Azure AD B2C) で GitHub アカウントでのサインインを有効にするには、 GitHub 開発者 ポータルでアプリケーションを作成する必要があります。 詳細については、「 OAuth アプリの作成」を参照してください。 GitHub アカウントをまだお持ちでない場合は、 https://www.github.com/でサインアップできます。
- GitHub 資格情報を使用して GitHub 開発者 にサインインします。
- [ OAuth アプリ ] を選択し、[ 新しい OAuth アプリ] を選択します。
- アプリケーション名とホーム ページの URL を入力します。
-
[Authorization callback 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 で大文字で定義されている場合でも、テナント名を入力するときは、すべて小文字を使用します。 - [Register application](アプリケーションを登録する) をクリックします。
- クライアント ID とクライアント シークレットの値をコピーします。 ID プロバイダーをテナントに追加するには、両方が必要です。
ID プロバイダーとして GitHub を構成する
- 少なくとも外部 ID プロバイダー管理者特権を持つアカウントで Azure portal にサインインします。
- 複数のテナントにアクセスできる場合、上部のメニューの [設定] アイコンを選択し、[ディレクトリとサブスクリプション] メニューからお使いの Azure AD B2C テナントに切り替えます。
- Azure portal の左上隅にある [ すべてのサービス ] を選択し、 Azure AD B2C を検索して選択します。
- ID プロバイダーを選択し、GitHub (プレビュー) を選択します。
- 名前を入力します。 たとえば、 GitHub です。
- クライアント ID には、先ほど作成した GitHub アプリケーションのクライアント ID を入力します。
- クライアント シークレットの場合は、記録したクライアント シークレットを入力します。
- 保存 を選択します。
GitHub ID プロバイダーをユーザー フローに追加する
この時点で、GitHub ID プロバイダーは設定されていますが、どのサインイン ページでもまだ使用できません。 GitHub ID プロバイダーをユーザー フローに追加するには:
- Azure AD B2C テナントで、[ ユーザー フロー] を選択します。
- GitHub ID プロバイダーを追加するユーザー フローをクリックします。
- ソーシャル ID プロバイダーで、GitHub を選択します。
- 保存 を選択します。
- ポリシーをテストするには、[ ユーザー フローの実行] を選択します。
-
[アプリケーション] で、以前に登録した testapp1 という名前の Web アプリケーションを選択します。
応答 URL に
https://jwt.ms
が表示されます。 - [ ユーザー フローの実行 ] ボタンを選択します。
- サインアップまたはサインイン ページで、GitHub を選択して GitHub アカウントでサインインします。
サインイン プロセスが成功すると、ブラウザーは https://jwt.ms
にリダイレクトされ、Azure AD B2C によって返されるトークンの内容が表示されます。
ポリシー キーを作成する
以前に Azure AD B2C テナントに記録したクライアント シークレットを格納する必要があります。
- Azure portal にサインインします。
- 複数のテナントにアクセスできる場合、上部のメニューの [設定] アイコンを選択し、[ディレクトリとサブスクリプション] メニューからお使いの Azure AD B2C テナントに切り替えます。
- Azure portal の左上隅にある [すべてのサービス] を選択してから、[Azure AD B2C] を検索して選択します。
- [概要] ページで、[Identity Experience Framework] を選びます。
- [ポリシー キー] を選択し、[追加] を選びます。
-
[オプション] で、[
Manual
] を選択します。 - ポリシー キーの名前を入力します。 たとえば、
GitHubSecret
のようにします。 プレフィックスB2C_1A_
がキーの名前に自動的に追加されます。 - [ シークレット] に、前に記録したクライアント シークレットを入力します。
- [ キーの使用法] で、[
Signature
] を選択します。 - Create をクリックしてください。
ID プロバイダーとして GitHub を構成する
ユーザーが GitHub アカウントを使用してサインインできるようにするには、Azure AD B2C がエンドポイント経由で通信できるクレーム プロバイダーとしてアカウントを定義する必要があります。 エンドポイントは、特定のユーザーが認証されたことを確認するために Azure AD B2C によって使用されるクレームのセットを提供します。
GitHub アカウントをクレーム プロバイダーとして定義するには、それをポリシーの拡張ファイルの ClaimsProviders 要素に追加します。
TrustFrameworkExtensions.xmlを開きます。
ClaimsProviders 要素を検索します。 存在しない場合は、ルート要素の下に追加します。
次のように新しい ClaimsProvider を追加します。
<ClaimsProvider> <Domain>github.com</Domain> <DisplayName>GitHub</DisplayName> <TechnicalProfiles> <TechnicalProfile Id="GitHub-OAuth2"> <DisplayName>GitHub</DisplayName> <Protocol Name="OAuth2" /> <Metadata> <Item Key="ProviderName">github.com</Item> <Item Key="authorization_endpoint">https://github.com/login/oauth/authorize</Item> <Item Key="AccessTokenEndpoint">https://github.com/login/oauth/access_token</Item> <Item Key="ClaimsEndpoint">https://api.github.com/user</Item> <Item Key="HttpBinding">GET</Item> <Item Key="scope">read:user user:email</Item> <Item Key="UsePolicyInRedirectUri">0</Item> <Item Key="BearerTokenTransmissionMethod">AuthorizationHeader</Item> <Item Key="UserAgentForClaimsExchange">CPIM-Basic/{tenant}/{policy}</Item> <!-- Update the Client ID below to the Application ID --> <Item Key="client_id">Your GitHub application ID</Item> </Metadata> <CryptographicKeys> <Key Id="client_secret" StorageReferenceId="B2C_1A_GitHubSecret"/> </CryptographicKeys> <OutputClaims> <OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" /> <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email" /> <OutputClaim ClaimTypeReferenceId="numericUserId" PartnerClaimType="id" /> <OutputClaim ClaimTypeReferenceId="issuerUserId" /> <OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="github.com" AlwaysUseDefaultValue="true" /> <OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" AlwaysUseDefaultValue="true" /> </OutputClaims> <OutputClaimsTransformations> <OutputClaimsTransformation ReferenceId="CreateIssuerUserId" /> <OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName"/> <OutputClaimsTransformation ReferenceId="CreateUserPrincipalName"/> <OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId"/> <OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId"/> </OutputClaimsTransformations> <UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" /> </TechnicalProfile> </TechnicalProfiles> </ClaimsProvider>
client_idアプリケーション登録のアプリケーション ID に設定します。
ファイルを保存します。
要求変換の追加
GitHub 技術プロファイルでは、 CreateIssuerUserId 要求変換を ClaimsTransformations の一覧に追加する必要があります。 ファイルに ClaimsTransformations 要素が定義されていない場合は、次に示すように親 XML 要素を追加します。 要求変換には、 numericUserId という名前で定義された新しい要求の種類も必要です。
- BuildingBlocks 要素を検索します。 要素が存在しない場合は、追加します。
- ClaimsSchema 要素を見つけます。 要素が存在しない場合は、追加します。
- ClaimsSchema 要素に numericUserId 要求を追加します。
- ClaimsTransformations 要素を見つけます。 要素が存在しない場合は、追加します。
- CreateIssuerUserId 要求変換を ClaimsTransformations 要素に追加します。
<BuildingBlocks>
<ClaimsSchema>
<ClaimType Id="numericUserId">
<DisplayName>Numeric user Identifier</DisplayName>
<DataType>long</DataType>
</ClaimType>
</ClaimsSchema>
<ClaimsTransformations>
<ClaimsTransformation Id="CreateIssuerUserId" TransformationMethod="ConvertNumberToStringClaim">
<InputClaims>
<InputClaim ClaimTypeReferenceId="numericUserId" TransformationClaimType="inputClaim" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="issuerUserId" TransformationClaimType="outputClaim" />
</OutputClaims>
</ClaimsTransformation>
</ClaimsTransformations>
</BuildingBlocks>
ユーザー体験を追加する
この時点で、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="GitHubExchange" />
</ClaimsProviderSelections>
...
</OrchestrationStep>
<OrchestrationStep Order="2" Type="ClaimsExchange">
...
<ClaimsExchanges>
<ClaimsExchange Id="GitHubExchange" TechnicalProfileReferenceId="GitHub-OAuth2" />
</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
が表示されます。 - [ 今すぐ実行 ] ボタンを選択します。
- サインアップまたはサインイン ページで、GitHub を選択して GitHub アカウントでサインインします。
サインイン プロセスが成功すると、ブラウザーは https://jwt.ms
にリダイレクトされ、Azure AD B2C によって返されるトークンの内容が表示されます。
次のステップ
- GitHub トークンをアプリケーションに渡す方法について説明します。
- GitHub フェデレーション ライブ デモと、GitHub アクセス トークン Live デモを渡す方法を確認する