Entra External IDにカスタムOIDC IDプロバイダーを追加する方法と設定ミス対策

Microsoft Entra External IDの顧客テナントでは、カスタムOpenID Connect（OIDC）IDプロバイダーを登録し、顧客が外部サービスの既存アカウントを使ってアプリへサインアップ、サインインできるように構成できます。

設定で特に重要なのは、外部IDプロバイダー側とEntra External ID側で、Issuer URI、クライアントID、クライアントシークレット、認証方式、スコープ、レスポンスタイプ、クレーム名を一致させることです。また、IDプロバイダーを登録しただけではサインイン画面に表示されません。登録後に、対象のユーザーフローへ追加する必要があります。

この記事では、2026年7月29日更新のMicrosoft公式情報をもとに、カスタムOIDC IDプロバイダーの追加手順、設定項目の意味、クレームマッピング、よくある失敗と確認方法を実務向けに整理します。(Microsoft Learn)

Entra External IDでカスタムOIDCサインインを構成する方法

カスタムOIDCフェデレーションを構成すると、利用者はEntra External ID内で新しいパスワードを作成する代わりに、外部IDプロバイダーのアカウントを使ってアプリへアクセスできます。

認証処理は、おおむね次の流れで進みます。

利用者
  ↓
Entra External IDのサインイン画面
  ↓
外部OIDC IDプロバイダーへリダイレクト
  ↓
外部IDプロバイダーで認証
  ↓
認可コードをEntra External IDへ返却
  ↓
Entra External IDがトークンを取得
  ↓
IDトークン内のクレームをユーザー属性へマッピング
  ↓
アプリへサインイン

Entra External IDは、OpenID Connectに準拠した外部IDプロバイダーとフェデレーションできます。ただし、実際に接続できるかどうかは、外部IDプロバイダーが必要なエンドポイント、レスポンスタイプ、クライアント認証方式、クレームを提供できるかで決まります。(Microsoft Learn)

構成前に確認する前提条件

カスタムOIDC IDプロバイダーを追加するには、次の環境が必要です。

確認項目	必要な状態
テナント	Microsoft Entra External IDの外部テナントが作成済み
アプリ	外部テナントにアプリが登録済み
ユーザーフロー	サインアップとサインイン用のユーザーフローが作成済み
管理者権限	External Identity Provider Administrator以上の権限
外部IDプロバイダー	OpenID Connectによる認証に対応
認証方式	ブラウザー委任型の認証を利用

カスタムOIDCなどのフェデレーションIDプロバイダーは、ブラウザー委任型の認証で利用します。ネイティブ認証で利用できるのは、メールアドレスとパスワード、またはメールのワンタイムパスコードなどのローカルアカウント方式です。アプリで外部アカウントによるサインインを提供する場合は、認証方式の設計段階でこの違いを確認しておきましょう。(Microsoft Learn)

外部IDプロバイダー側を先に設定する

Entra管理センターでOIDCプロバイダーを登録する前に、外部IDプロバイダー側でEntra External IDをクライアントアプリとして登録します。

リダイレクトURIを登録する

外部IDプロバイダーのアプリ設定に、次のリダイレクトURIを登録します。

https://<tenant-subdomain>.ciamlogin.com/<tenant-ID>/federation/oauth2

https://<tenant-subdomain>.ciamlogin.com/<tenant-subdomain>.onmicrosoft.com/federation/oauth2

それぞれ、次の値へ置き換えます。

プレースホルダー	設定する値
`<tenant-subdomain>`	外部テナントの初期ドメインに含まれるサブドメイン
`<tenant-ID>`	外部テナントのテナントID

リダイレクトURIの不一致は、認証が外部IDプロバイダーまで進んだ後にEntra External IDへ戻れない原因になります。プロトコル、ホスト名、パス、末尾の文字まで含め、登録値をコピーして照合してください。Microsoft公式手順では、上記2種類のURIが案内されています。(Microsoft Learn)

接続に必要な情報を取得する

外部IDプロバイダー側でアプリを登録したら、次の情報を控えます。

項目	確認する内容
Well-known endpoint	OIDC構成情報を返すディスカバリーURI
Issuer URI	IDトークンの発行者を表すURI
Client ID	外部IDプロバイダーが発行したクライアント識別子
Client Secret	クライアント認証に使用するシークレット
Client Authentication	トークンエンドポイントで使用する認証方式
Scope	要求するOIDCスコープ
Response Type	認可エンドポイントから受け取る応答形式
Claims	IDトークンに含まれるユーザー属性の名前

この段階で、外部IDプロバイダーが実際に返すディスカバリードキュメントとIDトークンの仕様を確認しておくことが重要です。管理画面の表示名だけを見て設定すると、Issuerやクレーム名の相違を見落としやすくなります。

Entra管理センターにカスタムOIDCプロバイダーを追加する

外部IDプロバイダー側の準備が完了したら、Microsoft Entra管理センターで登録します。

管理画面を開く

外部テナントへ切り替えた状態でMicrosoft Entra管理センターへサインインします。
「Entra ID」を開きます。
「External Identities」を選択します。
「All identity providers」を開きます。
「Custom」タブを選択します。
「Add new」から「Open ID Connect」を選択します。

操作には、少なくともExternal Identity Provider Administratorロールが必要です。別のテナントを開いていると、目的のユーザーフローやIDプロバイダー設定が表示されないため、画面右上などから現在のテナントを確認してください。(Microsoft Learn)

基本設定を入力する

登録画面で、次の情報を入力します。

Display name

サインアップ、サインイン画面で利用者に表示する名称です。

たとえば、外部サービス名が「Contoso ID」であれば、次のように設定できます。

Contoso IDでサインイン

社内の接続名や環境名ではなく、利用者がどのアカウントを使うのか判断できる名称にします。

Well-known endpoint

外部IDプロバイダーのOIDCディスカバリーURIを設定します。

このエンドポイントが返すJSONには、少なくとも次の情報が必要です。

issuer
authorization_endpoint
token_endpoint
token_endpoint_auth_methods_supported
response_types_supported
subject_types_supported
jwks_uri

Well-known endpointが正しくても、ディスカバリードキュメント内の情報が不足している場合は構成できません。ブラウザーやAPIクライアントでJSONを取得し、必要なプロパティが含まれているか事前に確認すると切り分けが早くなります。(Microsoft Learn)

OpenID Issuer URI

IDトークンを発行する主体を識別するURIです。

Issuer URIには、次の条件があります。

HTTPSを使用する
大文字と小文字を区別する
スキームとホストを含む
必要に応じてポート番号やパスを含める
クエリ文字列を含めない
フラグメントを含めない

最も安全な設定方法は、外部IDプロバイダーのディスカバリードキュメントにあるissuerの値を、そのままコピーすることです。

たとえば、末尾のスラッシュの有無やパスの大文字・小文字が異なるだけでも、発行者の検証に失敗する可能性があります。管理者が見た目で同じと判断せず、文字列として一致しているか確認してください。(Microsoft Learn)

Client IDとClient Secret

外部IDプロバイダー側で登録したアプリのクライアントIDとクライアントシークレットを入力します。

次のような取り違えに注意してください。

Entra External ID側のアプリケーションIDを入力している
外部IDプロバイダーのテナントIDを入力している
シークレットの名前や識別子を入力している
シークレットの値ではなく管理画面上のIDを入力している
開発環境用と本番環境用の値を混在させている

特にクライアントシークレットは、作成直後にだけ値を表示するIDプロバイダーがあります。登録時に安全な保管場所へ保存し、有効期限も運用台帳へ記録しておきましょう。

Client Authentication

Microsoft公式情報では、次のクライアント認証方式がサポートされています。

認証方式	対応状況
`client_secret_post`	サポート
`client_secret_jwt`	サポート
`client_secret_basic`	非サポート
`private_key_jwt`	現時点では非サポート

管理画面にprivate_key_jwtが表示される場合でも、Microsoft公式ドキュメントでは選択しないよう案内されています。また、client_secret_basicはセキュリティ上の理由からサポートされていません。(Microsoft Learn)

外部IDプロバイダーがclient_secret_basicのみに対応している場合、画面上の値を変更するだけでは接続できません。外部IDプロバイダー側で、対応する別のクライアント認証方式を有効にできるか確認する必要があります。

Scope

OIDCリクエストには、openidスコープが必要です。

一般的な設定例は次のとおりです。

openid profile email

スコープは半角スペースで区切ります。

スコープ	主な用途
`openid`	IDトークンを受け取るために必須
`profile`	氏名などのプロフィール情報
`email`	メールアドレス関連の情報

外部IDプロバイダーによっては、profileやemailを指定しても、アプリ側に許可されたクレームしか返さない場合があります。スコープだけでなく、外部IDプロバイダー側の同意設定やクレーム設定も確認してください。(Microsoft Learn)

Response Type

現在サポートされているレスポンスタイプは、codeのみです。

code

id_tokenやtokenはサポートされていません。Implicit Grant FlowやROPC Flowも、カスタムOIDC IDプロバイダーの構成ではサポートされません。

シングルページアプリでは、Authorization Code FlowとPKCEを利用する構成が推奨されています。(Microsoft Learn)

OIDCクレームをユーザー属性へマッピングする

基本設定を入力したら、「Next: Claims mapping」を選択し、外部IDプロバイダーから受け取るクレームをEntra External IDの標準クレームへ対応付けます。

代表的なマッピングは次のとおりです。

OIDC標準クレーム	Entra External IDの属性	用途
`sub`	直接対応する入力属性なし	発行者内でユーザーを識別
`name`	Display Name	表示名
`given_name`	First Name	名
`family_name`	Last Name	姓
`email`	Email	メールアドレス
`email_verified`	直接対応する入力属性なし	メール確認済み状態
`phone_number`	Phone number	電話番号
`phone_number_verified`	直接対応する入力属性なし	電話番号確認済み状態
`street_address`	Street Address	住所
`locality`	City	市区町村
`region`	State or Province	都道府県や地域
`postal_code`	ZIP or Postal Code	郵便番号
`country`	Country or Region	国または地域

ここで入力するのは、外部IDプロバイダーが実際のIDトークンで返すクレーム名です。

たとえば、外部IDプロバイダーが姓をlast_nameという名前で返す場合、family_name側のマッピング先としてlast_nameを指定します。外部IDプロバイダーが返していないfamily_nameをそのまま入力しても、姓は保存されません。

クレームマッピングは、推測ではなく実際のIDトークンを確認して設定するのが確実です。(Microsoft Learn)

subはユーザーを安定して識別できる値にする

subは、Issuer内でエンドユーザーを識別するSubject Identifierです。

外部IDプロバイダー側では、同じ利用者に対して継続的に同じsubを返せる設計が重要です。メールアドレスは変更される可能性があるため、メールアドレスをユーザー識別子として扱う設計とは分けて考えます。

検証環境のユーザーデータを削除して作り直した場合などにsubが変化すると、Entra External IDでは以前とは異なる外部IDとして扱われる可能性があります。移行や再構築を予定している場合は、外部IDプロバイダー側のSubject Identifierの生成ルールも確認してください。

属性を保存するにはユーザーフロー側にも追加する

クレームマッピングを設定しただけでは、すべての属性が自動的にユーザーオブジェクトへ保存されるわけではありません。

保存したい属性は、IDプロバイダーを関連付けるユーザーフロー側にも含める必要があります。

たとえば、次の設定が必要です。

外部IDプロバイダーのgiven_nameをFirst Nameへマッピングする
ユーザーフローの収集属性にFirst Nameを追加する
必要に応じて、利用者には入力欄を表示せず非表示にする

ユーザーに属性を入力させたくない場合でも、ユーザーフロー内へ属性を残したまま非表示にすることで、IDトークンから受け取った値を保存できます。(Microsoft Learn)

メールアドレスを返さないIDプロバイダーへの対応

外部IDプロバイダーを使ったサインアップでは、メールアドレスが初期状態で必須です。

外部IDプロバイダーがemailクレームを返さない場合、次のエラーが発生します。

AADSTS901011: No email address was obtained from the external oidc identity provider

対応方法は主に2つあります。

外部IDプロバイダーからemailとemail_verifiedを返す
ユーザーフローでメール属性を任意にする

emailクレームが存在する場合、アカウント作成にはemail_verifiedがtrueであることが必要です。一方、メール属性を任意にしたユーザーフローでは、emailクレーム自体がなくてもアカウント作成を進められます。(Microsoft Learn)

メール属性を任意にする際の注意点

メールの必須・任意は、アプリ単位ではなくユーザーフロー単位の設定です。

同じユーザーフローを複数のアプリで共有している場合、メールを任意に変更すると、そのユーザーフローに関連付けられたすべてのアプリへ影響します。

メール属性を任意にする変更は、Microsoft Graph APIを使ってユーザーフローのonAttributeCollectionを更新します。その際は、メール属性だけを含む新しい構成で上書きするのではなく、既存の入力属性をすべて保持したうえで、メールのrequiredだけをfalseへ変更する必要があります。(Microsoft Learn)

メールを収集しない場合、アカウント選択画面では通常、メールアドレスの代わりに表示名が使われます。利用者がアカウントを区別できるように、nameをマッピングするか、サインアップ時にDisplay Nameを収集するとよいでしょう。

IDプロバイダーをユーザーフローへ追加する

カスタムOIDC IDプロバイダーを作成しただけでは、アプリのサインイン画面には表示されません。

続けて、対象のユーザーフローへIDプロバイダーを追加します。

外部テナントで「Entra ID」を開きます。
「External Identities」を選択します。
「User flows」を開きます。
対象のサインアップ・サインイン用ユーザーフローを選択します。
「Settings」から「Identity providers」を開きます。
「Other Identity Providers」で作成したOIDC IDプロバイダーを選択します。
「Save」を選択します。

この設定を忘れると、IDプロバイダーの登録内容が正しくてもサインインボタンは表示されません。トラブル調査では、まず「All identity providersに登録されているか」と「ユーザーフローで有効になっているか」を分けて確認してください。(Microsoft Learn)

動作確認でテストすべき項目

構成後は、管理者アカウントで1回ログインできたことだけをもって完了としないことが重要です。少なくとも次のパターンを確認します。

テスト項目	確認する内容
新規サインアップ	初回利用者のユーザーオブジェクトが作成されるか
既存ユーザーのサインイン	2回目以降に同じアカウントとして認識されるか
サインインボタン	対象ユーザーフローの画面に表示されるか
リダイレクト	外部IDプロバイダーから正常に戻れるか
メール	`email`と`email_verified`が想定どおりか
氏名	`name`、`given_name`、`family_name`が保存されるか
属性非表示	非表示属性がIDトークンから取得、保存されるか
同意画面	要求したスコープが利用者に正しく提示されるか
キャンセル操作	外部IDプロバイダー側でキャンセルした場合に安全に戻るか
シークレット	本番用シークレットが設定され、有効期限を管理できているか

検証時は、既存のブラウザーセッションに影響されないよう、プライベートブラウズや別のテストユーザーを利用します。外部IDプロバイダーから返される値を確認する場合は、外部IDプロバイダーの監査ログやテスト用のトークン確認機能も併用します。

よくある失敗と確認ポイント

サインイン画面にOIDCプロバイダーが表示されない

主な原因は次のとおりです。

IDプロバイダーをユーザーフローへ追加していない
別のユーザーフローをアプリで使用している
設定した外部テナントと、アプリが利用している外部テナントが異なる
Issuer URI変更後の設定がユーザーフローへ反映されていない

Issuer URIを変更した場合、更新内容が既存のユーザーフローへ自動反映されず、サインイン画面からIDプロバイダーが消えることがあります。

この場合は、次の順番で再設定します。

ユーザーフローでIDプロバイダーを無効にする
ユーザーフローを保存する
IDプロバイダーを再度有効にする
もう一度保存する

これはMicrosoft公式情報で案内されている既知の制限です。(Microsoft Learn)

外部IDプロバイダーで認証後、Entra External IDへ戻れない

次の項目を確認します。

外部IDプロバイダーに登録したリダイレクトURI
テナントサブドメイン
テナントID
HTTPSとパス
開発環境と本番環境の取り違え

外部IDプロバイダーのログに「redirect URI mismatch」などの記録がある場合は、Entra External ID側ではなく外部IDプロバイダー側のアプリ登録を確認します。

Issuer検証で失敗する

次の3つを文字列として比較します。

Entra External IDに入力したIssuer URI
Well-known endpointが返すissuer
実際のIDトークンに含まれるiss

大文字・小文字、末尾のスラッシュ、テナントやポリシーを表すパスまで含め、一致している必要があります。

トークンエンドポイントで認証に失敗する

Client IDとClient Secretが正しい場合は、Client Authenticationを確認します。

外部IDプロバイダーがclient_secret_basicを要求している一方、Entra External IDでclient_secret_postを選択しても、同じシークレットを使っているだけでは認証できません。クライアント認証方式は、外部IDプロバイダー側の登録内容と一致させる必要があります。

IDトークンが取得できない

Scopeにopenidが含まれているか確認します。

openid profile email

profile emailだけではOpenID ConnectのIDトークンを要求する設定になりません。

また、Response Typeにはcodeを指定します。id_tokenやtokenを指定する構成はサポートされていません。(Microsoft Learn)

ユーザー属性が空になる

次の順番で確認します。

外部IDプロバイダーがIDトークンにクレームを含めているか
Entra External IDのクレームマッピング先が正しいか
クレーム名の大文字・小文字や階層が一致しているか
対応する属性がユーザーフローに追加されているか
外部IDプロバイダー側で必要なスコープや同意が許可されているか

「スコープを指定したから必ず属性が返る」とは限りません。最終的には、外部IDプロバイダーが発行したIDトークンの内容を確認する必要があります。

本番運用で押さえるべき注意点

クライアントシークレットの期限を管理する

クライアントシークレットに有効期限が設定されている場合、期限切れになると外部IDプロバイダーへのサインインが一斉に失敗します。

運用台帳には、少なくとも次の項目を記録します。

IDプロバイダー名
対象テナント
Client ID
シークレットの有効期限
更新担当者
更新予定日
利用しているユーザーフロー
影響を受けるアプリ

シークレットの値そのものは、一般的な台帳やチケットへ直接記録せず、組織で承認されたシークレット管理方法を使用します。

検証環境と本番環境を分ける

外部IDプロバイダー側のアプリ登録を環境ごとに分けると、リダイレクトURI、シークレット、同意設定の取り違えを防ぎやすくなります。

特に本番移行時は、次の値を一覧で比較してください。

比較項目	検証環境	本番環境
テナントサブドメイン	検証用	本番用
テナントID	検証用	本番用
Client ID	検証用	本番用
Client Secret	検証用	本番用
Issuer URI	検証用または共通	本番用または共通
リダイレクトURI	検証用	本番用
ユーザーフロー	検証用	本番用

ユーザーフローを共有する範囲を確認する

メール属性の必須・任意や収集属性は、ユーザーフローに関連付けられたアプリへ影響します。

アプリごとに必要な属性や本人確認要件が異なる場合は、同じユーザーフローを安易に共有せず、要件ごとに分けることも検討します。

対応していない機能との組み合わせに注意する

Microsoft公式情報では、カスタムOIDCフェデレーションは「Invite external user」のプレビュー機能とは互換性がないとされています。

また、Microsoft Entra IDテナントを外部IDプロバイダーとして接続する場合は、一般的なカスタムOIDC設定だけで判断せず、Entra IDテナント向けの専用手順も確認してください。(Microsoft Learn)

設定完了前のチェックリスト

本番公開前に、次の項目を確認します。

外部テナントに対象アプリが登録されている
サインアップとサインイン用ユーザーフローが作成されている
外部IDプロバイダーへ2種類のリダイレクトURIを登録した
Well-known endpointから構成情報を取得できる
Issuer URIがディスカバリードキュメントのissuerと一致している
Client IDとClient Secretが外部IDプロバイダー側の値と一致している
Client Authenticationがサポート対象である
Scopeにopenidが含まれている
Response Typeがcodeになっている
subを正しくマッピングしている
必要な氏名、メール、住所などのクレームをマッピングしている
保存したい属性をユーザーフローにも追加している
作成したOIDCプロバイダーをユーザーフローで有効にした
新規サインアップと既存ユーザーの再サインインをテストした
シークレットの期限と更新担当者を記録した

Entra External IDへのカスタムOIDC IDプロバイダー追加では、外部IDプロバイダーの登録、Entra External IDへの登録、クレームマッピング、ユーザーフローへの追加という4段階を分けて確認することが重要です。

接続に失敗した場合は設定を一度に変更せず、まずIssuer、リダイレクトURI、クライアント認証方式、openidスコープ、codeレスポンスタイプを順番に照合してください。その後、実際のIDトークンとクレームマッピングを比較すると、認証処理の問題と属性保存の問題を切り分けやすくなります。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Entra External IDにカスタムOIDC IDプロバイダーを追加する方法と設定ミス対策

Entra External IDでカスタムOIDCサインインを構成する方法

構成前に確認する前提条件

外部IDプロバイダー側を先に設定する

リダイレクトURIを登録する

接続に必要な情報を取得する

Entra管理センターにカスタムOIDCプロバイダーを追加する

管理画面を開く

基本設定を入力する

Display name

Well-known endpoint

OpenID Issuer URI

Client IDとClient Secret

Client Authentication

Scope

Response Type

OIDCクレームをユーザー属性へマッピングする

subはユーザーを安定して識別できる値にする

属性を保存するにはユーザーフロー側にも追加する

メールアドレスを返さないIDプロバイダーへの対応

メール属性を任意にする際の注意点

IDプロバイダーをユーザーフローへ追加する

動作確認でテストすべき項目

よくある失敗と確認ポイント

サインイン画面にOIDCプロバイダーが表示されない

外部IDプロバイダーで認証後、Entra External IDへ戻れない

Issuer検証で失敗する

トークンエンドポイントで認証に失敗する

IDトークンが取得できない

ユーザー属性が空になる

本番運用で押さえるべき注意点

クライアントシークレットの期限を管理する

検証環境と本番環境を分ける

ユーザーフローを共有する範囲を確認する

対応していない機能との組み合わせに注意する

設定完了前のチェックリスト

この記事を書いた人

コメント

コメントするコメントをキャンセル

Entra External IDにカスタムOIDC IDプロバイダーを追加する方法と設定ミス対策

Entra External IDでカスタムOIDCサインインを構成する方法

構成前に確認する前提条件

外部IDプロバイダー側を先に設定する

リダイレクトURIを登録する

接続に必要な情報を取得する

Entra管理センターにカスタムOIDCプロバイダーを追加する

管理画面を開く

基本設定を入力する

Display name

Well-known endpoint

OpenID Issuer URI

Client IDとClient Secret

Client Authentication

Scope

Response Type

OIDCクレームをユーザー属性へマッピングする

subはユーザーを安定して識別できる値にする

属性を保存するにはユーザーフロー側にも追加する

メールアドレスを返さないIDプロバイダーへの対応

メール属性を任意にする際の注意点

IDプロバイダーをユーザーフローへ追加する

動作確認でテストすべき項目

よくある失敗と確認ポイント

サインイン画面にOIDCプロバイダーが表示されない

外部IDプロバイダーで認証後、Entra External IDへ戻れない

Issuer検証で失敗する

トークンエンドポイントで認証に失敗する

IDトークンが取得できない

ユーザー属性が空になる

本番運用で押さえるべき注意点

クライアントシークレットの期限を管理する

検証環境と本番環境を分ける

ユーザーフローを共有する範囲を確認する

対応していない機能との組み合わせに注意する

設定完了前のチェックリスト

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル