ALB + Cognito認証で付与されるユーザー情報をEC2サイドから眺めてみる

ALBはCognitoと組み合わせることで、簡単にWebサーバーの認証機能を実現できます。超便利。

ALBとCognitoを組み合わせた認証については、弊社ブログで解説しているのでこちらを御覧ください。

• インフラエンジニアが一切コードを書かずにWebサーバーに認証機能を実装した話 ｜ DevelopersIO

本ブログでは、ここからもう一歩踏み込んで、ALBが認証後EC2に何を渡しているのか？（EC2はユーザー情報をどう受けとっているのか？）を眺めてみます。

構成図

こんな感じのシンプルな構成を作ります。ALBへのアクセス時に、Cognitoと連携して認証を行います。CognitoでログインできたユーザーだけがEC2上のコンテンツにアクセスできます。

ALB + Cognito認証のおさらい

ALB + Cognitoの認証がどういったフローで動いているか、ここで一度おさらいしましょう。 OIDC認証がわかっていると、似たような動作をしているので理解しやすいです。 だいたい、ALBがリライング・パーティ、CognitoがIDプロバイダの動きをしています。

フローを図にするとこんな感じです。

• 認証のフロー | Application Load Balancer を使用してユーザーを認証する - Elastic Load Balancing

まずは、ALBに対してアクセスすると、Cognitoのログイン画面にリダイレクトされます。（フロー図の１〜４）

• ログインエンドポイント - Amazon Cognito

ログイン画面でID,パスワードを入力してログインすると、認証レスポンスがALBのコールバックURLにリダイレクトされます。（フロー図の５〜７）

• Amazon Cognito を使用する準備を整える | Application Load Balancer を使用してユーザーを認証する - Elastic Load Balancing

その後、ALBとCognito間の裏側でトークンリクエストやIDトークンの検証をして（フロー図の８〜１０）、ユーザークレームをCognitoから取得して（フロー図の１１、１２）、認証が完了したらもともとアクセスをしていたURLへリダイレクトして（フロー図の１３〜１４）、ユーザー情報をヘッダーに付与してEC2へ転送してログイン後の画面が表示される（フロー図の１５〜１７）といったフローになっています。

このフローを経て、ユーザーの認証に成功すると、ロードバランサは次のHTTPヘッダを追加してEC2に渡します。（フロー図の１５）

x-amzn-oidc-accesstoken トークンエンドポイントからのアクセストークン (プレーンテキスト)。

x-amzn-oidc-identity ユーザー情報エンドポイントからの件名フィールド (sub) (プレーンテキスト)。

x-amzn-oidc-data ユーザークレーム (JSON ウェブトークン (JWT) 形式)

参考：ユーザークレームのエンコードと署名の検証 | Application Load Balancer を使用してユーザーを認証する - Elastic Load Balancing

この追加されたHTTPヘッダ（ユーザー情報）をEC2サイドから覗いてみます。

DockerでPHPを動かす

EC2が受け取るHTTPリクエストヘッダを覗きたいので、phpinfoを使って、HTTPリクエストヘッダをべろっと出してみます。

• PHP: phpinfo - Manual

PHPの環境をまともに作るのは面倒くさいので、Dockerを使ってさくっと作ります。

EC2インスタンスにSSHログインして、Dockerをインストールしていきます。

$ sudo yum install docker -y
$ sudo service docker start
$ sudo usermod -a -G docker ec2-user
$ sudo systemctl enable docker

phpinfoを表示するためのphpファイルを作ります。

$ mkdir /home/ec2-user/www
$ chmod 755 /home/ec2-user/www
$ echo "<?php phpinfo();" > /home/ec2-user/www/info.php

Dockerでphpを動かします。

$ docker run -d -p 8080:80 --name php -v /home/ec2-user/www:/var/www/html php:7.2-apache

ブラウザからALB経由でEC2へアクセスしてみると、べろっとHTTPリクエストヘッダをだすことができました。

EC2サイドからユーザー情報を眺めてみる

ALBに追加された次の３つのヘッダ情報が、どういう情報なのか実際に確認してみます。

• x-amzn-oidc-accesstoken：アクセストークン
• x-amzn-oidc-identity：ユーザーの一意の識別子 (UUID)
• x-amzn-oidc-data：ユーザークレーム (JWT)

• ユーザークレームのエンコードと署名の検証 | Application Load Balancer を使用してユーザーを認証する - Elastic Load Balancing

x-amzn-oidc-accesstoken

x-amzn-oidc-accesstokenはアクセストークンです。

アクセストークンを利用すると、Cognitoからユーザー情報を取得できます。 CogintoのUSERINFOエンドポイントは、アクセストークンを利用して認証されたユーザーに関する情報を返します。

• USERINFO エンドポイント - Amazon Cognito

よって、次のようにヘッダを利用してアクセストークンを渡すことで、認証されたユーザーのユーザー情報を受け取ることができます。

$ ACCESS_TOKEN=<<x-amzn-oidc-accesstokenをコピー&ペースト>>
$ COGNITO_URL=<<Cognitoドメインをコピー&ペースト>>
$ curl -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  ${COGNITO_URL}/oauth2/userInfo
{
   "sub": "248289761001",
   "name": "Jane Doe",
   "given_name": "Jane",
   "family_name": "Doe",
   "preferred_username": "j.doe",
   "email": "[email protected]"
}

ちなみにCognitoドメインは、Cognitoユーザープールの画面で参照できます。

x-amzn-oidc-identity

x-amzn-oidc-identityはユーザーの一意の識別子 (UUID)で、Cognitoのsubクレームです。

Cognitoでログインしたユーザーのユーザー画面と比較してみると、確かに一致していることがわかります。

x-amzn-oidc-data

x-amzn-oidc-dataはユーザークレーム（ユーザー情報）です。

ユーザークレームがJWT形式で保持されています。JWT形式ではありますが、IDトークンではありません。 JWT形式のため、ペイロード部分を切り出してbase64デコードすると、ユーザー情報の内容を確認することができます。

$ OIDC_DATA=<<x-amzn-oidc-dataをコピー&ペースト>>
$ echo $OIDC_DATA | cut -d'.' -f 2 | base64 -D
{
   "sub": "1234567890",
   "name": "name",
   "email": "[email protected]",
   ...
}

終わりに

ALBとCognitoの認証をEC2サイドから見てみました。

ALBとCognitoの認証の動きを知ることで、アプリケーションのあるEC2側でユーザー情報がどうやって渡されるのかが理解できると思います。

本ブログがその際の理解の助けになれば幸いです。