Power Pagesでサイト認証を有効にすると自動生成される「Website Authentication Key」の拇印（サムプリント）。同時にEntra ID側にもアプリ登録が作られます。本記事では拇印の正体、証明書との1対1対応、トークン要求への影響、確認・更新手順と運用の落とし穴まで整理します。
結論：Website Authentication Keyの拇印＝Entra IDアプリ登録に登録された証明書の拇印
最初に結論から整理します。Power Pagesの管理画面で表示されるWebsite Authentication Keyの拇印（Thumbprint）は、Microsoft Entra ID（旧Azure AD）で自動作成される該当アプリ登録の「証明書（Certificates）」に表示される拇印と一致します。
拇印は「秘密」そのものではなく、どの証明書を使っているかを一意に識別するための指紋です。Power Pages側は秘密鍵を保持し、その秘密鍵で署名した情報（クライアントアサーションなど）をEntra IDへ提示します。Entra ID側はアプリ登録に紐づく公開鍵（証明書）を探し当て、署名を検証して信頼できるクライアントかを判断します。
| Power Pages側で見えるもの | Entra ID側で対応するもの | 意味 | 運用上のポイント |
|---|---|---|---|
| Website Authentication Keyの拇印 | アプリ登録「証明書とシークレット」内の証明書拇印 | 証明書を識別するフィンガープリント | 期限管理とローテーションの起点になる |
| Update security key（更新） | 新しい証明書がアプリ登録に追加（または置換）される | 鍵（証明書）ローテーション | 基本はPower Pages側から実行する |
まず押さえる：Website Authentication Keyは「ユーザー認証」だけの話ではない
Power Pagesで「Website Authentication（サイト認証）」を有効にすると、表面的には「サイトにログイン機能が付く」ように見えます。しかし裏側では、Power PagesサービスがEntra IDと安全に通信するための“サーバー側の認証基盤”が用意されます。
このとき作成される証明書（Website Authentication Key）は、主に次のような用途で活用されます。
- Power Pages（サービス）→ Entra ID：トークン発行要求の際のクライアント認証（証明書ベース）
- Entra ID → Power Pages：どの証明書を信頼するか（拇印で識別）
- 結果として、サイト認証やサイトが必要とするバックエンドアクセス（例：Dataverse等）を成立させる
ポイントは、拇印が直接「ユーザーのIDトークンの中身」を変えるのではなく、“Power Pagesというクライアントが正当かどうか”を判断する材料として効いている点です。
拇印（サムプリント）の正体：証明書フィンガープリントを正しく理解する
拇印は、X.509証明書の内容から計算されるハッシュ値（多くのUIではSHA-1）で、証明書を一意に識別するために使われます。重要なのは次の違いです。
| 用語 | ざっくり説明 | 漏えいリスク | よくある誤解 |
|---|---|---|---|
| 拇印（Thumbprint） | 証明書の指紋（識別子） | 低い（基本的に秘密情報ではない） | 「拇印が漏れたらなりすまされる」→拇印単体では不可 |
| 公開鍵（証明書） | 検証側が持つ鍵。署名検証に使用 | 低い（公開してよい） | 「公開鍵＝秘密」→公開して成立する仕組み |
| 秘密鍵 | 署名側が持つ鍵。署名生成に使用 | 高い（漏えいでなりすましが可能） | 「Entra IDポータルで見える」→通常は見えない/管理しない |
| クライアントシークレット | パスワード型の資格情報 | 高い（漏えいでなりすましが可能） | 「証明書と同じ」→運用・更新の考え方が異なる |
Power PagesのWebsite Authentication Keyは、概念的には「アプリ登録に対して証明書（公開鍵）を登録し、Power Pagesサービス側が秘密鍵で署名して自分を証明する」方式です。拇印はその証明書を特定するラベルのようなもの、と理解するとブレません。
技術的にどう紐づくのか：拇印で証明書を特定し、公開鍵で署名を検証する
「拇印が技術的にどうアプリ登録と紐づくのか？」を、できるだけ実務に落ちる粒度で説明します。
紐づきの中心は“アプリ登録の証明書（Certificates）”
Entra IDのアプリ登録では、アプリを認証するための資格情報として証明書を複数登録できます。各証明書には拇印が付き、Entra IDは次のように利用します。
- トークン要求に含まれる情報（例：署名付きJWT）のヘッダーにあるx5t（拇印）やkidなどを手掛かりに、どの証明書で署名されたかを推定する
- アプリ登録に登録されている証明書の公開鍵を取り出し、署名を検証する
- 検証が通れば「このアプリ（クライアント）は正当」と判断し、トークンを発行する
なぜ拇印が必要なのか
アプリ登録に証明書が1枚だけなら「それで検証すれば良い」ように見えますが、実務ではローテーションや複数キーの共存が起こり得ます。拇印があることで、検証側は「どの証明書で署名したのか」を迅速に選べます。
イメージしやすい通信の流れ
実際のパラメーター名や内部実装はサービスごとに差がありますが、考え方はほぼ共通です。
- Power PagesがEntra IDのトークンエンドポイントへ「トークンが欲しい」と要求する
- その要求には、秘密鍵で署名したクライアントアサーション（JWT）が含まれる
- JWTヘッダーには証明書の識別子として拇印（例：x5t）が含まれ、Entra IDが該当証明書を探す
- 見つけた公開鍵で署名検証し、OKならトークンを返す
参考として、JWTヘッダーがどう見えるかの雰囲気だけ載せます（値はダミーです）。
{
"alg": "RS256",
"typ": "JWT",
"x5t": "（証明書の拇印を表す値）",
"kid": "（鍵ID）"
}ここで重要なのは、拇印が一致しない＝Entra IDが正しい公開鍵を取り出せないということです。結果、署名検証ができず、トークン発行が失敗します。
トークン検証やIDフェデレーションにどう影響するか
よくある混乱が「拇印が変わると、ユーザーのトークン検証（IDトークンの検証）も変わるのか？」という点です。整理すると影響は次の通りです。
| 影響対象 | 拇印（証明書）変更の影響 | 主な症状 | 切り分けのヒント |
|---|---|---|---|
| Power Pages → Entra IDのトークン要求（クライアント認証） | 影響が大きい（一致しないと失敗） | サイト側で認証関連のエラー、バックエンド接続不良 | アプリ登録の証明書一覧と拇印を突合する |
| ユーザーのIDトークン/アクセストークンの署名検証 | 通常は直接の影響は小さい | 一般的には別のキー（Entra ID側の署名キー）で検証 | ユーザー向けトークンの署名鍵はIDプロバイダー側で管理される |
| フェデレーション全体の成否（結果としてログインできるか） | 間接的に影響（トークン取得失敗が波及） | 「ログインボタンが進まない」「サインイン後に戻ってこない」 | まずクライアント認証の成否（アプリ側）を疑う |
まとめると、拇印は「ユーザーのトークンの署名鍵そのもの」ではなく、Power PagesがEntra IDからトークンをもらうための“クライアント本人確認”に効きます。よって、運用上は「証明書が期限切れ」「拇印が一致しない」「証明書を消した」などが直接の障害要因になりやすいです。
Entra IDで拇印を確認・管理する場所
拇印の確認場所は、Entra IDのアプリの登録内です。管理者が現場で迷うのは「どのアプリ登録を見ればいいのか」です。先に“探し方”から押さえるとスムーズです。
対象アプリ登録の探し方（迷ったときの実務手順）
- アプリ登録一覧で、Power Pages / Portal / サイト名などのキーワードで検索する
- 候補が複数ある場合は、リダイレクトURI（Web）や、作成日時、所有者の情報で絞り込む
- 「アプリの登録」に見当たらない場合は「エンタープライズ アプリケーション」に同名のサービスプリンシパルが存在することもあるため、両方を見る
Power Pagesは環境や設定により表示名が揺れることがあります。運用上は「このサイト用のアプリ登録はこれ」と特定できるよう、アプリ（クライアント）IDや表示名を台帳化しておくと、更新時の事故を減らせます。
拇印の確認手順（Entra IDポータル）
- Microsoft Entra 管理センターを開く
- 「アプリの登録」→ 対象アプリを選択
- 左メニュー「証明書とシークレット」を開く
- 「証明書（Certificates）」の一覧で、拇印・有効期限を確認する
ここで確認できるのは基本的に公開証明書の情報です。秘密鍵はPower Pages側（サービス側）が保持している前提のため、Entra IDポータルから“秘密鍵をダウンロードして差し替える”といった運用には向きません。
Power Pages側で拇印を確認・更新する場所
実務では、拇印・証明書の更新はEntra ID側で直接触るより、Power Apps 管理センター（Power Pagesの管理）から実施するのが安全です。Power Pages側から更新すれば、必要な同期が自動で行われやすく、整合性崩れを起こしにくいからです。
確認手順（Power Apps管理センター）
- Power Apps 管理センターにアクセス
- 対象環境・対象サイト（Power Pagesサイト）を選択
- 「Website Authentication Key」タブを開く
- 拇印と有効期限（表示される場合）を確認する
更新手順（ローテーション）
- 同じ画面で「Update security key（セキュリティキーの更新）」を実行する
- 更新後、Power Pages側の拇印が新しい値に変わったことを確認する
- Entra ID側（アプリ登録→証明書）にも新しい証明書が反映されていることを確認する
更新は“ボタン一発”に見えますが、実務では更新後の確認までを手順に含めるのが重要です。特に複数環境（開発/検証/本番）を運用している場合、誤って別環境のサイトを更新すると「本番だけ障害」「検証だけ直らない」といった混乱が起きがちです。
有効期限とローテーション運用：事故を防ぐチェックリスト
Website Authentication Keyで自動生成される証明書は、運用上有効期限が最重要ポイントです。一般にこの種の自動生成証明書は1年程度の有効期限で設定されることが多く、放置すると期限切れで突然トークン取得に失敗し、サイトに影響が出る可能性があります。
| タイミング（目安） | やること | 確認場所 | 判断基準 |
|---|---|---|---|
| 日常運用（月次など） | 拇印と有効期限の棚卸し | Power Pages / Entra ID | 期限が近いものをリスト化 |
| 期限の60〜30日前 | 更新の予定化、関係者へ周知 | 運用台帳 | 本番作業枠・ロールバック方針を確保 |
| 期限の30〜7日前 | Update security keyを実行 | Power Apps管理センター | 更新後に新拇印へ切替わる |
| 更新直後 | Entra ID側の証明書反映と動作確認 | アプリ登録 / サインインログ | 認証フローが正常に完走する |
ローテーションの“コツ”は、期限ギリギリでやらないことです。更新作業はシンプルでも、周辺要因（条件付きアクセス、権限変更、同時期の別変更など）で認証が失敗することがあります。余裕を持って更新し、問題があれば切り戻しや調査の時間を確保しましょう。
ここを触ると危ない：Entra ID側での手動操作が招きやすいトラブル
Entra IDポータルは強力ですが、Power PagesのWebsite Authentication Keyに関しては手動で証明書を消す/差し替える運用はおすすめしません。Power Pagesサービスが保持している秘密鍵と整合が取れなくなると、復旧が難しくなるためです。
| 操作 | 推奨度 | 理由 | 代替案 |
|---|---|---|---|
| Entra ID側で証明書を削除 | 避ける | Power Pages側の秘密鍵と不整合になりやすい | Power Pages側で更新し、不要キーは手順に沿って整理 |
| Entra ID側で新しい証明書を手動追加 | 慎重に | 秘密鍵をPower Pagesが持たないため意味がない/逆に混乱しやすい | Update security keyでサービスに管理させる |
| Power Pages側でUpdate security key | 推奨 | サービス側とアプリ登録側の同期が期待できる | 更新後にEntra IDで反映確認する |
トラブルシューティング：拇印・証明書が原因の典型パターン
「急にログインできなくなった」「サイト認証が落ちた」というとき、原因はアプリ登録やIDプロバイダー設定など多岐にわたります。その中で、Website Authentication Keyの拇印に紐づく証明書が原因のケースは、切り分けが比較的パターン化できます。
| 症状 | 起こりやすい原因 | 確認ポイント | 優先アクション |
|---|---|---|---|
| サインイン処理で「invalid_client」系のエラー | 証明書の不一致、期限切れ、アプリ登録の資格情報変更 | Power Pagesの拇印と、アプリ登録の証明書拇印が一致しているか | まず拇印の突合。必要ならPower Pages側で更新 |
| 昨日まで動いていたのに突然失敗 | 証明書の期限切れ、運用担当が誤って削除 | 証明書の有効期限、最近の変更履歴 | 期限切れなら更新。削除なら復旧手順を検討 |
| 特定環境（本番だけ/検証だけ）で失敗 | 環境ごとに別のアプリ登録・別証明書を使っている | 対象環境のサイトを見ているか、アプリ登録が一致するか | 台帳と照合し、対象を取り違えていないか確認 |
| 更新後にだけ失敗 | 更新直後の反映待ち、条件付きアクセス、権限変更が同時発生 | Entra IDサインインログで失敗理由を確認 | 時間を置いた再確認、ポリシー影響の切り分け |
切り分けの“最短ルート”は、Power Pages側に表示される拇印とEntra IDアプリ登録に登録された証明書拇印の突合です。ここが一致していない場合、どれだけユーザー側の設定を見直しても直りません。
拇印が一致しないように見えるときの落とし穴
Power Pages側とEntra ID側で拇印を突合したはずなのに「一致しない」「別の値に見える」という相談は少なくありません。実際には同じ証明書でも、表示形式や参照している値が違うだけで、見た目が変わっているケースがあります。
| よくある状況 | 原因 | 現場での確認ポイント |
|---|---|---|
| 大文字/小文字が違う | UIの表記ゆれ（値自体は同一） | 英数字を大文字に統一して比較する |
| 空白や区切り記号（: やスペース）が混ざる | コピー時に整形が入る | 空白・記号を除去して40桁の16進数として比較する |
| 16進数とBase64が混在している | ポータルは16進、GraphやJWTはBase64/Base64Urlになることがある | 同じ値を別表現で見ていないか確認する（次の表を参照） |
| アプリ登録に証明書が複数ある | ローテーションや過去の残骸で複数枚が共存 | 拇印だけでなく有効期限・開始日も見て“現在使われている”証明書を特定する |
拇印は一般に40桁の16進数で表示されます（SHA-1の結果）。ただし、APIやトークンの内部表現ではBase64（またはBase64Url）に変換されていることがあります。
| 表現 | 例（ダミー） | 出てきやすい場所 | 見方 |
|---|---|---|---|
| 16進（Hex） | 9F3A…（40桁） | Power Apps管理センター、Entra IDポータルの「Thumbprint」 | 人が突合しやすい |
| Base64 | nzp…== | Microsoft GraphのkeyCredentials.customKeyIdentifierなど | 末尾に=が付くことがある |
| Base64Url | nzp…（=なし、-や_） | JWTヘッダーのx5tなど | URL安全文字に置換される |
もし「Graphで見た値」と「ポータルで見た拇印」を照合したい場合は、表現変換が必要です。参考として、16進の拇印をBase64Urlへ変換するイメージを載せます（環境により実行可否は異なります）。
# 例：16進の拇印（40桁）→ Base64Url へ変換するイメージ
$thumbHex = "9F3A...（40桁の16進）"
$thumbHex = ($thumbHex -replace "[:\s]", "").ToUpper()
$bytes = for ($i=0; $i -lt $thumbHex.Length; $i += 2) {
[Convert]::ToByte($thumbHex.Substring($i,2), 16)
}
$base64 = [Convert]::ToBase64String($bytes)
$base64Url = $base64.TrimEnd("=") -replace "+", "-" -replace "/", "_"
$base64Url「一致しない」ときほど、焦って証明書を削除するのは禁物です。まずは表示形式の違いと複数証明書の存在を疑い、落ち着いて突合しましょう。
監査・運用で差がつくポイント：台帳化と自動チェック
Power Pagesは「自動で作ってくれる」反面、構成要素が見えにくく、担当者が変わると追えなくなりがちです。おすすめは、最低限次の項目を台帳化することです。
- サイト名（環境名含む）
- 対応するEntra IDアプリ登録の表示名
- アプリ（クライアント）ID
- 証明書の拇印
- 有効期限
- 更新担当・更新日
可能なら、Microsoft GraphやPowerShellでアプリ登録の証明書期限を定期点検する仕組みも有効です。例として雰囲気だけ示します（実行には権限やモジュールが必要です）。
# 例：アプリ登録の証明書（keyCredentials）を確認するイメージ
# 実環境ではMicrosoft Graph PowerShell等を利用し、対象アプリIDで絞り込みます。
Get-MgApplication -Filter "appId eq '（クライアントID）'" |
Select-Object DisplayName, AppId, KeyCredentials自動化までしなくても、期限管理を“誰かの記憶”に依存させないだけで、認証切れによる障害は大きく減らせます。
よくある質問
拇印が分かれば、どのアプリ登録か必ず特定できますか？
拇印は証明書の識別子なので、Entra ID側で「証明書拇印」を軸に探す発想は有効です。ただし管理画面の検索性や権限によっては探しにくいことがあります。実務ではアプリ（クライアント）IDや表示名もセットで管理すると確実です。
拇印（証明書）を変えると、ユーザーのサインイン設定も作り直しになりますか？
多くの場合、ユーザー向けの設定（リダイレクトURI、IDプロバイダー設定など）自体を全部作り直す必要はありません。ただし、拇印が一致しない状態ではバックエンドのトークン取得が失敗し、結果としてログインフローが崩れたように見えることがあります。まずはクライアント認証の健全性（証明書/拇印）を確認してください。
Entra ID側で証明書を直接更新してはいけませんか？
「絶対にダメ」というより、Power Pagesが秘密鍵を保持している前提のため、Entra ID側だけで更新してもPower Pagesがその秘密鍵で署名できず、意味がなくなったり混乱を招きやすい、というのが実務上の問題です。原則はPower Pages側の「Update security key」でローテーションし、Entra ID側では反映確認に留めるのが安全です。
更新すると即時に切り替わりますか？ downtimeはありますか？
多くの管理系変更は即時反映に見えても、内部的には反映に時間差が出ることがあります。更新後は、拇印が変わったことだけで満足せず、実際にサインインが完走するか、Entra IDのサインインログで失敗が出ていないかまで確認してください。運用上は、業務影響が少ない時間帯に実施し、手順化しておくのが堅実です。
証明書の期限はどこで見ればいいですか？
Power Pages側の画面に期限が表示される場合はそこで確認できます。加えて、Entra ID側の「アプリ登録 → 証明書とシークレット → 証明書」では、証明書ごとの有効期限が一覧で確認できるため、台帳化・棚卸しに向いています。
まとめ：拇印の意味を理解すると、更新・障害対応が一気に楽になる
- Website Authentication Keyの拇印は、Entra IDのアプリ登録に登録された証明書の拇印と一致する
- 拇印は“秘密”ではなく、どの証明書で署名したかを識別するキーとして使われる
- 拇印（証明書）が不一致・期限切れになると、トークン取得が失敗し、結果としてサイト認証に影響が出る
- 更新は原則Power Pages（Power Apps管理センター）側でローテーションし、Entra ID側は確認・監査に使う
- 台帳化と期限管理を徹底すると、認証トラブルの大半は未然に防げる
コメント