Cognito＋Microsoft EntraID認証でのSSOを実装してみた。

musaka.k

目次

  • はじめに
  • ゴール
  • 構成図
  • 本記事で詳細な解説をしない概念
  • Amazon Cognito
  • 認証・認可フローの解説
  • 終わりに
  • 参考にしたサイト

はじめに

表題の要件を、慣れないサービスに四苦八苦しながら実装してみました。もともと認証・認可は好きな分野でもあったので、アウトプットがてら、記事にできればと思います。
また、極力前提知識がない方でも読めるように例え話が多く、かつ詳細な説明は省いています。
そのあたりはご容赦ください。

ゴール

本実装例を通じて、以下についてざっくりと理解する

  • Amazon Cognitoとは何か
  • 本構成における認証・認可フローの裏でどのようなことが起こっているのか

構成図

今回実装した構成図は以下のようになります。

file
1.ユーザーがドメイン名でALBにアクセス
2.ユーザーはMicrosoftのログイン画面にリダイレクト
3.認証完了後、EC2上で稼働しているWEBサーバにアクセス

本記事で詳細な解説をしない概念

本記事で以下の概念は詳細に解説しません。
あくまでざっくりとした解説にとどめます。

  • 認証・認可
  • SAML(Security Assertion Markup Language)
  • OIDC（OpenID Connect）
  • Microsoft EntraID(旧AzureAD)

認証：（Authentication）

「私はこの人です」という主張を何からの根拠で証明するプロセス

認可：（Authorization）

「認証された人に何をさせるか」を決めるプロセス

SAML(Security Assertion Markup Language)

認証と認可に関する情報をXML形式でやり取りするためのプロトコル
登場人物

  • SP（本記事だとCognito）
  • IdP（本記事だとMicrosoft EntraID）

本構成だと、Cognito⇔Microsoft EntraIDのユーザー認証で使用されます。
こちらの記事がわかりやすいので、ご確認を推奨します。

OIDC（OpenID Connect）

SAMLと同様に認証と認可のプロトコルの一つ
登場人物

  • クライアント（本記事だとALB）
  • OpenIDプロバイダー（本記事だとCognito）

本構成だと、SAMLで認証が完了し、ALB⇔Cognito間で、認証情報の受け渡しと認可を行います。
この記事がわかりやすいので、こちらの記事のご確認を推奨します。

Microsoft EntraID(旧AzureAD)

Microsoft 365やMicrosoft Azureといったサービスを利用する場合、ユーザの管理はどちらもMicrosoft EntraIDというIDで管理されます。
「会社でMicrosoft 365を契約しているけど、Azureは使っていない・・・」のような場合（もちろん逆も可）でも、本構成は可能となります。

詳しくはこちらの記事をご確認ください。

Amazon Cognito

Amazon Cognito はウェブアプリとモバイルアプリ用の認証・認可機能を提供してくれるAWSマネージドサービスです。
身近な例で例えるとホテルのチェックインプロセスです。
　予約確認（フロント受付やアプリ経由であなたが誰か確認する：認証）
　キーカードの発行（認証されたあなたに権限を与える：認可）
これから登場するCognitoに関する用語説明も、ホテルのチェックインに例えていければと思います。

ユーザープール

「お客様名簿」のようなものです。
ユーザーの登録・ログイン（どのようにログインするのかなど）・プロフィール管理などを担当します。
本構成ではMicrosoft EntraIDやALBと連携し、認証・認可情報の受け渡しを行います。

IDプール

「キーカード発行所」のようなものです。
AWS のリソースにアクセスするための一時的な権限を発行します。
ただ、本構成では使わないので別の機会に深堀できればと思います。

アプリケーションクライアント

「ユーザプール：お客様名簿」を使用するための窓口のようなものです。
例えばホテルをチェックインするにしても
①フロント受付の人に対応してもらう
②モバイルアプリで行う
③フロントの自動受付機で行う
など様々かと思います。
本構成ではユーザーからのリクエストを受けたALBが、Cognitoへリダイレクトの際にこのアプリケーションクライアントIDを指定します。
→これは、一つのユーザープールに対して、様々なアプリケーションクライアントが紐づきうるためです。

認証・認可フローの解説

では本記事のメインである認証フローの解説に移ります。

登場人物整理をすると、以下のようになります。

OpenID Connect (OIDC)

  • Cognito:OpenIDプロバイダー
  • ALB:クライアント

SMAL(Security Assertion Markup Language)

  • Cognito:Service Provider
  • Microsoft Entra ID:Identity Provider

①ALBがリクエストをCognito認証エンドポイントにリダイレクト。使用プロトコルはOpenID Connectで同時にアプリケーションクライアントIDを指定する
意訳：WEBサーバにアクセスしたかったら、まずはCoginitoさんに許可してもらってください。
file

②Cognito認証エンドポイントが、Microsoft Entra IDにSAML 2.0プロトコルによる認証要求メッセージを送る。
意訳：Microsoftさん、認証は僕やってないんで、代わりに認証お願いします。
file

③Microsoft Entra IDがSAML認証を開始する。
意訳：はーい、ではアクセスしてきたリクエストの身分確認を行います。ユーザー名とパスワードを入力してください。
file

④ユーザーがSAMLでEntra IDで認証を完了する。
意訳：怪しいものではありません。
file

⑤認証に成功した場合、Microsoft Entra IDはSAMLレスポンスとSAMLアサーションという形で認証結果をCognito認証エンドポイントに送る
SAMLレスポンスにはDestinationや識別子、SAMLのバージョン、発行者が含まれており、SAMLアサーションには認証されたユーザー情報などが含まれる
※SMAL認証としては以上で、移行はOIDCプロトコルで認証・認可プロセスを進めます。
意訳：はい、このユーザーの成功しました。Cognitoさん・・・後は、頼みます。
file

⑥Cognitoが認証情報を検証し、OAuth認証コード（code=f0782532-4428-45f6-9c85-…）を生成し、ALBに送信する。
※ここで使用プロトコルがSAMLからOIDCに切り替わります。
意訳：はい、認証されたことを確認しました。認証されたことを示す証明書を渡しますね。
file

⑦ALBが認証コードを取得し、このコードをCognitoのトークンエンドポイントに送信し、コードと引き換えにJWTトークン（id_token、access_token、refresh_token）を受け取る。
意訳：この証明書があれば制限期間付きの入館証がもらえると聞いたので・・・
file

⑧ALBはJWTトークンを検証し、有効なトークンであれば、ユーザーのリクエストをバックエンドアプリケーションに転送する。このとき、ALBはHTTPヘッダーにユーザー情報（X-Amzn-Oidc-*ヘッダー）を追加する。
意訳：入館証が本物であることを確認したので、中に入れますよ。また、あなたの情報をバックエンドに伝えておきますね。
file

以上、認証・認可フローでした！

終わりに

本記事ではAmazon Cognitoを使用したSSOの認証フローの流れについて深堀しました。
今後はSMALや（OIDC）OpenID connectにおける署名検証のプロセスについても、深堀していきたいです。

参考にしたサイト

公式ドキュメント
https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/what-is-amazon-cognito.html

SMALについて
https://www.hitachi-solutions.co.jp/iam/saml.html

OIDC（OpenID connect）について
https://qiita.com/TakahikoKawasaki/items/498ca08bbfcc341691fe

Microsoft EntraIDについて
https://www.lanscope.jp/blogs/cloud_security_pfs_blog/20240205_19102/

Last modified: 2025-04-13

Author