SSOの設定作業は、Entra IDの画面とアプリの画面を行き来しながら、値をコピーして貼るという形になります。迷うのは「どこで何を作って、どこに登録するのか」です。
SAMLの署名証明書もOIDCのクライアントシークレットも、どちらもEntraで作ってアプリに登録します。手順は似ています。ところが証明している対象が逆なので、ここを取り違えると設定の意味が分からなくなります。
この記事では、Entra側でやることとアプリ側でやることを、SAMLとOIDCそれぞれについて順に並べます。
内容はMicrosoftの公式ドキュメントに基づいています。 画面の文言やナビゲーションは更新されることがあるため、実際の作業時は画面表示を優先してください。トークンの中身やプロトコルの違いはEntra IDのSSOをトークンの中身から理解するにまとめています。
1. 結論：作る場所は同じ、証明する対象が逆
先に全体像です。
| SAML | OIDC | |
|---|---|---|
| 登録場所 | エンタープライズ アプリケーション | アプリの登録 |
| アプリに渡すもの | 署名証明書（Entraが自動生成・3年） | クライアントシークレット（Entraが生成） |
| 作る場所 | Entra | Entra |
| 何を証明するか | Entraの署名が本物か（アプリがEntraを信じる） | アプリが本物か（Entraがアプリを信じる） |
| 期限 | 既定3年 | 最長2年（24か月） |
どちらもEntraで作ってアプリに登録する点は同じです。違うのは向きではなく用途です。
SAMLの証明書は「Entraの署名を検証するための公開鍵」です。アプリに渡して、届いたアサーションが本物か確かめさせます。アプリがEntraを信じるための材料です。
OIDCのシークレットは「アプリが自分を名乗るための合言葉」です。アプリがトークンを要求するときに提示し、Entraがアプリを信じるための材料になります。
1.1 OIDCで証明書を使う場合だけ、向きが逆になる
OIDCのクライアント認証には、シークレットのほかに証明書も選べます。こちらは自分で用意した証明書の公開鍵をEntraにアップロードする形で、唯一この場合だけ渡す向きが逆になります。
公式ドキュメントは本番環境ではシークレットではなく証明書を使うべきとしているので、将来的にはこちらが主流になります。
1.2 署名検証用の鍵をアプリに入れる作業は、OIDCには無い
SAMLでは「Entraの署名を検証するための証明書」をアプリに登録しますが、OIDCに同じ作業はありません。
署名の検証に使う公開鍵は、アプリがディスカバリ文書の jwks_uri から自動で取得します。鍵が入れ替わっても追随します。「SAMLと同じように署名検証用の証明書をもらう画面」を探しても存在しないので、ここだけ覚えておけば迷いません。
2. SAML：Entra側でやること
設定画面は4つのセクションに分かれています。どのセクションが「アプリから受け取って入れる」側で、どれが「Entraから持ち出す」側かを先に押さえておくと、往復の回数が減ります。
2.1 エンタープライズ アプリケーションを作る
Entra ID > エンタープライズ アプリ > すべてのアプリケーションから新規作成します。ギャラリーに該当製品があればそれを選び、無ければ「ギャラリー以外のアプリケーション」で作ります。
作成後、管理 > シングル サインオンを開き、方式として SAML を選びます。
2.2 基本のSAML構成を埋める
アプリ側のドキュメントを見ながら、次の値を入れます。ここはアプリから受け取る情報です。
| 項目 | 中身 | アプリ側での呼び名 |
|---|---|---|
| 識別子（エンティティID） | アプリを一意に表すURI | Entity ID、Audience |
| 応答URL（ACS URL） | アサーションのPOST先 | ACS URL、Consumer URL |
| サインオンURL | 利用者が最初に開くURL | ログインURL |
| ログアウトURL | サインアウト先 | SLO URL |
識別子と応答URLは必須です。この2つが合っていないと、アサーションを投げても受け取ってもらえません。
2.3 証明書をダウンロードする
SAML証明書の見出しから、証明書をダウンロードします。SAML方式を設定した時点で、Entraが自己署名証明書を自動生成します。有効期間は既定で3年です。
ダウンロード形式は複数あります。アプリが要求する形式を確認してから選んでください。
| 形式 | 中身 |
|---|---|
| 証明書（Base64） | テキスト形式。これを要求するアプリが多い |
| 証明書（Raw） | バイナリ形式 |
| フェデレーション メタデータ XML | 証明書とエンドポイントをまとめたXML |
| PEM | Base64と同じ。拡張子が .pem |
メタデータXMLを受け付けるアプリなら、それが一番確実です。 証明書だけでなくエンドポイントも入っているので、貼り間違いが起きません。
あわせて、同じ画面に出ているログインURLとMicrosoft Entra 識別子を控えます。これはアプリ側に登録する値です。
2.4 属性とクレームを調整する
属性とクレームの欄で、アサーションに載せる情報を決めます。既定では一意ID（NameID）にUPNなどが入ります。
前回の記事で触れたとおり、UPNやメールアドレスは変わり得るので、一意IDには objectid を指定するほうが安全です。アプリがそれを受け付けるなら、こちらを選びます。
グループを渡す設定もここにありますが、SAMLでは150グループを超えると groups が入らなくなります。グループ数が多い組織では、グループではなくアプリロールで判定する設計にしてください。
2.5 期限切れの通知先を設定する
証明書の有効期限が切れるとSSOが止まります。Entraは60日前・30日前・7日前に通知メールを送ります。
送信元は azure-noreply の Microsoft ドメインです。通知先は既定でアプリを追加した管理者1人だけなので、5件まで追加できる枠を使って、担当が変わっても届くようにしておきます。個人宛てだけにしておくと、異動時に誰も気づかなくなります。
3. SAML：アプリ側でやること
アプリの管理画面で、Entraから持ってきた3点を登録します。
| 登録するもの | Entra側のどこから |
|---|---|
| IdPのエンティティID | Microsoft Entra 識別子 |
| IdPのログインURL | ログインURL |
| 署名検証用の証明書 | SAML証明書（Base64など） |
メタデータXMLを受け付けるアプリなら、XMLを1つアップロードすれば3点ともまとめて入ります。
逆に、アプリ側で生成した識別子と応答URLをEntraに戻して登録します。この往復が1回で終わらないのが普通なので、両方の画面を開いたまま作業するのが早いです。
4. OIDC：Entra側でやること
SAMLと違い、左メニューのページを行き来して設定します。使うのは上から4つです。
4.1 アプリを登録する
Entra ID > アプリの登録から新規登録します。エンタープライズ アプリケーションではありません。
登録すると、アプリケーション（クライアント）ID と ディレクトリ（テナント）ID が発行されます。どちらもアプリ側に設定する値なので控えます。
4.2 リダイレクトURIを登録する
アプリが認可コードを受け取るURLです。完全一致で照合されるため、末尾のスラッシュひとつでも違うと弾かれます。
https://kintai.example.jp/signin-oidcプラットフォーム（Web、SPA、モバイル）の選択も要ります。サーバー側でクライアントシークレットを保持できるならWeb、ブラウザだけで動くSPAなら「シングルページ アプリケーション」を選びます。
4.3 クライアントシークレットか証明書を作る
証明書とシークレットの画面で作ります。選択肢は3つです。
| 種類 | 中身 | 誰が作り、どちらへ渡すか |
|---|---|---|
| クライアント シークレット | 文字列（最長2年） | Entraが生成 → アプリに登録（SAMLと同じ向き） |
| 証明書 | 証明書の公開鍵 | 自分で用意 → Entraにアップロード（向きが逆） |
| フェデレーション資格情報 | 外部IDを信頼させる設定 | 資格情報そのものを持たない |
既定でよく使われるのはクライアントシークレットで、この場合は「Entraで作ってアプリに登録する」というSAMLと同じ流れになります。証明書を選んだときだけ、自分で作ってEntraにアップロードする向きに変わります。
クライアントシークレットの有効期限は最長2年（24か月）です。公式ドキュメントは「2年（24か月）以下に制限され、24か月を超えるカスタム期間は指定できない」としたうえで、12か月未満を推奨しています。さらに本番環境ではシークレットではなく証明書を使うべきとも書かれています。
シークレットの値は、画面を離れると二度と表示されません。 作成直後にコピーして、安全な場所に保管してください。後から確認する方法はなく、分からなくなったら作り直しになります。
証明書を使う場合は、自分で作った証明書の公開鍵（.cer / .pem / .crt）をアップロードします。秘密鍵はアプリ側に置いたままです。登録後に表示される拇印（Thumbprint）をアプリの設定に使います。
4.4 アクセス許可とアプリロール
APIのアクセス許可で、アプリが呼ぶAPIと範囲（スコープ）を指定します。サインインだけなら openid profile 程度で足ります。
権限をトークンに載せたい場合は、アプリ ロールを定義して利用者やグループに割り当てます。前回触れたとおり、グループ数が多い環境ではグループよりアプリロールのほうが安全です。アプリロールはそのアプリに割り当てた分しか入らないので、数が膨らみません。
5. OIDC：アプリ側でやること
アプリの設定に入れるのは、おおむね次の4点です。
| 設定項目 | 値 |
|---|---|
| Authority（発行者） | https://login.microsoftonline.com/{テナントID}/v2.0 |
| クライアントID | アプリケーション（クライアント）ID |
| クライアントシークレット／証明書 | 4.3で作ったもの |
| リダイレクトURI | 4.2で登録したものと完全一致 |
エンドポイントを個別に入力する必要は、たいていありません。 Authority を設定すれば、アプリがディスカバリ文書を読んで認可エンドポイント・トークンエンドポイント・公開鍵の場所を自動で揃えます。
https://login.microsoftonline.com/{テナントID}/v2.0/.well-known/openid-configuration署名検証用の証明書をアプリに入れる作業はありません。 ディスカバリ文書の jwks_uri が公開鍵の置き場所を示しており、アプリはそこから鍵を取得します。鍵が入れ替わっても自動で追随します。これがSAMLとの大きな運用上の差です。
6. 期限管理をどう回すか
SSOが止まる原因の多くは期限切れです。
| 期限 | 切れると | |
|---|---|---|
| SAML署名証明書 | 既定3年 | アサーションの検証に失敗しサインインできない |
| クライアントシークレット | 最長2年（24か月） | トークン取得に失敗しサインインできない |
クライアントシークレットには通知がありません。 SAML証明書は60/30/7日前にメールが来ますが、シークレットは自分で期限を管理する必要があります。台帳に載せるか、カレンダーに入れるか、Graph APIで棚卸しするかを決めておいてください。
6.1 SAML証明書の入れ替えは順序がある
公式ドキュメントが示している手順です。
赤くした③と④の順序を逆にすると、その間サインインできません。 アプリが複数の証明書を保持できるなら無停止で入れ替えられますが、1つしか持てないアプリでは停止時間を取る必要があります。
公式には注意書きもあります。アプリが証明書の有効期限を検証していない場合、期限切れの証明書でも通ってしまうことがあり、そこに新しい証明書が加わると予期しない動作になります。アプリ側が期限を見ているかは確認しておくべき点です。
7. つまずきやすいところ
「OIDCの証明書はどこからダウンロードするのか」 ダウンロードしません。署名検証用の鍵をアプリに入れる作業自体が無いからです。探しているものは存在せず、jwks_uri から自動取得される仕組みだと理解すれば解決します。なお、アプリが自分を名乗るための資格情報としてなら証明書を使えますが、そちらは自分で用意してEntraにアップロードするものです。
「エンタープライズ アプリケーション」と「アプリの登録」を間違える SAMLは前者、OIDCは後者です。アプリの登録で作ったものもエンタープライズ アプリケーション側に現れるため、どちらで設定すべきか混乱しがちです。SAMLのSSO設定画面は前者にしかありません。
リダイレクトURIが完全一致しない 末尾のスラッシュ、http と https、ポート番号の有無。すべて区別されます。アプリが出すエラーに実際のリダイレクトURIが載ることが多いので、そこと見比べるのが早いです。
シークレットの値を控え忘れる 画面を離れると二度と表示されません。作り直すしかありません。
応答URLと識別子を取り違える 応答URL（ACS）はアサーションのPOST先、識別子（Entity ID）はアプリの名前のようなものです。両方URLの形をしているので貼り違えやすく、しかもエラーメッセージが分かりにくい箇所です。
8. まとめ
Entra IDでSSOを設定するとき、どちらで何を作るかを整理しました。
- SAMLはEntraが証明書を作り、アプリに渡す。 既定3年、Base64かメタデータXMLでダウンロード
- OIDCのシークレットもEntraで作ってアプリに登録する。 手順はSAMLと同じだが、証明している対象が逆（アプリが自分を名乗るためのもの）
- OIDCに「署名検証用の証明書をアプリへ入れる」作業は無い。 鍵は
jwks_uriから自動取得される - SAMLはエンタープライズ アプリケーション、OIDCはアプリの登録。画面が違う
- クライアントシークレットは最長2年（24か月）で、期限通知が無い。 本番は証明書が推奨
- シークレットの値は画面を離れると二度と見られない
- 証明書の入れ替えは「アプリに登録してからアクティブ化」の順序を守る
- 一意IDはUPNではなくオブジェクトIDを使う
設定値そのものは、アプリ側のドキュメントとEntraの画面に全部書いてあります。つまずくのはたいてい「その資格情報が何を証明しているのか」と「どちらの画面か」の勘違いなので、そこだけ先に押さえておけば作業は進みます。
プロトコルの中身とトークンのクレームについてはEntra IDのSSOをトークンの中身から理解するを参照してください。
コメント