サイトアイコン 協栄情報ブログ

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

musaka.k

目次

はじめに

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

ゴール

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

構成図

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


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

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

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

認証：（Authentication）

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

認可：（Authorization）

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

SAML(Security Assertion Markup Language)

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

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

OIDC（OpenID Connect）

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

本構成だと、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)

SMAL(Security Assertion Markup Language)

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

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

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

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

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

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

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

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

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

終わりに

本記事では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/

モバイルバージョンを終了