.NETやAzure・Microsoft製品で学んだことや気づいたことを共有しよう

@takumiida1(Takumi Ida)Team Coffee

AWSを経験してからAzureを触り始めて感じたこと〜CIAM編〜

Posted at 2026-06-29

Summary

2025年前半時点ではAmazon Cognitoに慣れた開発者がEntra External IDのExternalテナントを触ったときに躓くポイントが多数存在したが、2025年後半〜2026年にかけて外部OIDC連携のGAやPasskeyサポートなど改善が相次いでいる
domain_hint（Issuer acceleration）・カスタム認証拡張機能・Passkey等、Cognitoにはない制約や設計上の差異は依然として存在しており、事前の仕様把握が設計品質に直結する
条件付きアクセスとの統合というEntraならではの強みは健在であり、エンタープライズ用途での発展に引き続き期待できる

やらないこと

AWSとAzureの優劣比較（どちらが優れている・劣っているではない）
特定サービスの網羅的な仕様説明
料金の詳細比較

本記事のねらい

筆者はAWSのCIAMサービスであるAmazon Cognitoを業務で使用してきた後、Azure側のCIAMサービスであるMicrosoft Entra External IDを触り始めた。前回の記事ではネットワーク・PaaS・DB周辺の設計思想の違いを述べたが、本稿ではCIAM（Customer Identity and Access Management）領域に絞り、Cognitoとの比較で気づいたことを時系列の変化も交えて述べる。

まず前提として、Entra External IDにはテナント種別が2つある。

Workforceテナント：社員や内部ユーザー向け。従来のAzure AD（現Entra ID）の延長線上にある
Externalテナント：外部ユーザー向けのCIAM用途。本記事で主に扱うのはこちら

Cognitoに相当する「CIAM向けの外部公開サービス」として使うには、Externalテナントが該当する。以下で実際にハマった点・気づいた点と、その後の改善状況を述べる。

AWS・Azureで感じた違い

`domain_hint`の挙動

結論としては、2026年時点、この挙動についてCognitoとEntra External ID on Externalテナントで大きな差は無い。

Cognitoでは、アプリ側のログインURLにidentity_providerパラメータを付与することで、Hosted UIのIdP選択画面を完全にスキップし、指定したIdPのログインページへ直接リダイレクトさせることができる。複数の外部IdPを束ねたハブ的なアプリ構成において、ユーザーの属性に応じて透過的にIdPを切り替えるといった設計が自然に実現できる。

現在はEntra External IDのExternalテナントでもIdPへのヒントをdomain_hintパラメータで渡す仕組みは存在し、公式ドキュメントでは「Issuer acceleration（発行者アクセラレーション）」と呼んでいる。Google、Apple、カスタムOIDC等のIdPに対して以下のような形式で渡すことができる。

domain_hint=google
domain_hint=apple
domain_hint=<Issuer URIのドメイン部分>  # カスタムOIDCの場合

Cognitoや前身のAzure AD B2Cではdomain_hintが動作していた経験があったのだが、2025年前半時点ではExternalテナントにおいて動作せず、サポートに問い合わせると当時は「実装されていない」という回答を得たため当時は戸惑った。

なお、入力されたメールアドレスのドメイン部分を元にIDプロバイダーを特定することは、2026年6月時点ではAmazon Cognito/Entra External IDのどちらにもできない認識である。

ログインをトリガーにした任意処理の実行方法

CognitoにはLambdaトリガーという強力な仕組みがあり、認証フローの各ステージに任意のLambda関数を差し込むことができる。代表的なものを挙げると以下の通りだ。

トリガー	タイミング
Pre Authentication	認証試行前
Post Authentication	認証成功後
Pre Token Generation	トークン生成前
Post Confirmation	ユーザー登録確認後
Custom Message	メッセージ送信前

各LambdaはCognitoから直接呼び出されるため、開発者がAPIを公開する必要がなく、Lambdaコンソールに関数を用意するだけでよい。Post Authenticationであれば、ログイン成功の瞬間に外部システムへの書き込みや通知の送信、最終ログイン時刻の更新といった副作用処理を自然に差し込める。

Entra External IDには**Custom Authentication Extensions（カスタム認証拡張機能）**が用意されており、認証フローの特定ポイントでREST APIを呼び出すことができる。サポートされているイベントは以下の通りだ。

イベント	タイミング
`OnAttributeCollectionStart`	サインアップ時の属性収集画面レンダリング前
`OnAttributeCollectionSubmit`	サインアップ時の属性収集フォーム送信後
`OnTokenIssuanceStart`	トークン発行直前

Cognitoとの大きな違いが2点ある。まずアーキテクチャの違いとして、Entraの場合は開発者がAzure FunctionsやApp Serviceなどを使って公開APIエンドポイントを自前で構築・ホストする必要がある。Cognitoのようにクラウドサービスが直接Lambda関数を呼び出す形とは異なり、インフラ管理の責務が開発者側に移る。

次にイベントの粒度の違いとして、「ログイン（サインイン）そのもの」をトリガーにするイベントが存在しない。OnTokenIssuanceStartはトークン発行直前に発火するため、外部DBからクレームを付与する用途には使える。ただし、このイベントはサインインだけでなくトークンのリフレッシュ時にも発火する点に注意が必要で、純粋に「ログインした瞬間」を捕まえたい用途には向かない。ログイン記録等の用途に流用することも不可能ではないが、リフレッシュとの区別にひと工夫が必要になる。

旧世代のAzure AD B2Cではカスタムポリシー（Identity Experience Framework）によってより細かいフロー制御が宣言的に記述できたが、Entra External IDはよりシンプルなUser Flowを軸に据えており、その分カスタマイズの粒度は絞られている。

OIDCによる外部IdPとの連携

以前はPreviewだった外部OIDCプロバイダーとのIdP連携は、2025年3月に正式GA（一般提供）となった。Microsoftのアイデンティティチームが公式ブログでアナウンスしており、Amazon、Auth0、Okta、Azure AD B2CなどOIDCプロトコルに準拠したさまざまなIdPとの連携が本番環境で利用可能となっている。

CIAM領域でOIDCを採用するIdPが増えている現状を踏まえると、GAになったことで選択肢が大きく広がった点は素直に歓迎できる。SAMLも引き続き対応しており、B2Cからの移行パスも整備されつつある。

なお、Entra IDテナント（Workforceテナント）をカスタムOIDC IdPとして使う構成については別途ドキュメントが整備されているが、制限事項が別途存在するため、要件によっては事前確認が必要。

ExternalテナントのMFAオプションの現状

Cognitoでは、MFAの第二要素としてSMS・メールOTP・TOTP（Google AuthenticatorやMicrosoft Authenticator等）・Passkeyが利用でき、アプリ要件に応じて選択できる。

ExternalテナントでサポートされているMFA第二要素は、公式ドキュメントによれば以下の通りだ。

第一要素	利用可能な第二要素
メール＋パスワード、ユーザー名＋パスワード	メールOTP、SMS（アドオン）、Passkey（FIDO2）
外部IdP（Google、Facebook等）	メールOTP、SMS（アドオン）
メール＋OTP（パスワードレス）	SMSのみ

Microsoft AuthenticatorによるTOTP・プッシュ通知はExternalテナントでは非対応である。これはCognitoと比べたときの依然として残る制約の一つだ。

なお、こうした第二要素やPasskeyによるパスワードレス認証を利用できるのは、CognitoもEntra External IDもローカルアカウントのユーザーに限定されており、Google等のソーシャルIdPでサインインしているユーザーにはPasskeyを登録させることができない。また、Passkeyの利用にはカスタムURLドメインの設定が必須という要件もある。

条件付きアクセスとエンタープライズへの親和性

Entra External IDには条件付きアクセス（Conditional Access）との統合という、Cognitoにはない強みがある。

Cognitoでは、MFAの要否をアプリ側のコードで制御する、ユーザープールのポリシーで一律に設定する、またはリスクベースで自動的に制御する形である。

Entra External IDでは、条件付きアクセスを使えば、ユーザーの所属テナント・グループ・サインインリスク・デバイスコンプライアンス状態・アクセス元の場所といった複数の条件を組み合わせて、MFAを含むアクセス制御をコードなしに宣言的に設定できる。

テナントやグループ単位で一括コントロールできるのは、複数の取引先・顧客企業を扱うシナリオで特に有効だ。また、認証コンテキスト（Authentication Context）を使えば、センシティブな操作のときだけMFAを要求するステップアップ認証もアプリ側から制御できる。Zero Trustの「最小権限アクセス」の思想に合致したアプローチであり、エンタープライズ用途では重宝する機能だ。

なお、条件付きアクセスポリシーの管理にはMicrosoft Entra ID P1ライセンスが、サインインリスク・ユーザーリスクに基づくリスクベースポリシーにはP2ライセンスが必要となる。

まとめ・所感

CognitoとEntra External IDのExternalテナントを比較して気づいた点を、現時点（2026年6月）の状況を加味してまとめる。

観点	2026年6月時点での違い	Amazon Cognito	Entra External ID（Externalテナント）
IdPへの自動遷移	ほぼ無し	`identity_provider`パラメータで透過的に実現可能	`domain_hint`（Issuer acceleration）でIdP直接遷移が可能。
フック実装の仕組み	CognitoはFaaSと直接連携可能	LambdaをCognitoから直接呼び出し、API公開不要	Azure Functionsなど公開APIエンドポイントの構築が必要
サインインイベントへのフック	Cognitoの方がバリエーション多め	`PostAuthentication`等で任意処理が実行可能	サインインに特化したイベントは存在しない。`OnTokenIssuanceStart`で代替可能だが、リフレッシュ時にも発火する点に注意
外部OIDCIdP連携	ほぼ無し	GA	2025年3月にGA済み
MFA第二要素	ほぼ無し	メールOTP、TOTP（Authenticatorアプリ）、SMS、Passkey等	メールOTP、SMS（アドオン）、Passkey（FIDO2）。Authenticator TOTPは非対応
Passkey	ほぼ無し	対応	対応
MFAポリシー制御	Entra External IDの方が制御が充実	コードまたはユーザープール設定	条件付きアクセスで宣言的に管理可能（P1/P2ライセンスが必要）

2025年前半に実装を進めた時点では、OIDCによる外部IDプロバイダー連携がPreviewであったり、Passkeyの扱いが不明瞭であったりと、Cognitoとの差を強く感じる場面が多かった。またPreview状態の機能には、Cognitoのみならず、前身のAzure AD B2Cで搭載されていた機能もあった。しかしその後の約1年で、OIDC連携のGAやPasskeyサポートなど着実に機能が拡充されてきており、当初の「荒削り感」はかなり薄れてきた印象である。

依然としてカスタマイズの粒度やLambdaトリガー相当の柔軟性という観点ではCognitoに軍配が上がる場面はある。一方で、条件付きアクセスとの統合やMicrosoftのエコシステム全体との親和性はEntraならではの強みであり、特にマルチテナント構成やステップアップ認証を要件とするシナリオにおいて効果を発揮すると考える。

セキュリティに直結する認証周りのサービスは両者とも着実に進化している。今後の機能拡充を引き続きウォッチしていきたい。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

AWSを経験してからAzureを触り始めて感じたこと 〜CIAM編〜