既存のWebアプリで「Amazon Cognito」認証を利用する（その１:処理フローの整理）

2019-05-222021-03-14Amazon,AWS

Contents

1. はじめに
2. 改めて OAuth2 または OpenID Connect の処理フローについて
3. ひとこと

はじめに

以前、「Amazon Cognito」を使ってログイン機能を作成する（SNS 認証あり） | ゲンゾウ用ポストイットで「Amazon Cognito」のユーザ認証機能を利用してログインページを構築しました。

しかし、やりたかったことは既存の Web アプリケーションのログイン機能を「Cognito」を利用した仕組みに置き直すということだったため、完全ではありませんでした。

「Cognito」のユーザ認証が完了した後、既存のアプリケーションでそれを引き継ぐための仕組みを構築すべく、追加で調査をしました。
（今回は整理にとどめて次回のエントリでサンプルコードの実装・公開をしたいと思います。）

改めて OAuth2 または OpenID Connect の処理フローについて

「Congito」を使ったユーザ認証は「OpenID Connect」という方式になります。「OAuth2」方式をベースとした後発の認証方式です。したがって「OAuth2」の理解を深めることが「OpenID Connect」の理解を深めることにつながると思いました。

僕が説明するより以下の記事を読むほうが圧倒的にわかりやすいです。

とはいえ、自分の頭の中を整理するため、自分なりにまとめてみます。

めっちゃ汚いですが、手書きの処理フローになります。（一部字が潰れたり上塗りされていたりしていますが（汗））

処理フローを箇条書きで文字起こし

登場人物は 3 つ、 "Browser" / "AppServer" / "Cognito" です。（"Browser"は人の形で表現しています。）

"Browser" は "AppServer" にアクセス
"AppServer" はログイン済みかを判定します。未ログイン状態の場合には "Cognito" に "redirect"（"redirect"の URL に対して事前に「Cognito」から払い出された「アプリケーション ID」などを付与）
"Cognito" は "login page" を返却
"Browser" は "login" を行う
"Cognito" は受け取った認証情報が正しければ "redirect" 。 "redirect" の URL の後方にはクエリ文字列形式で Authentication code と呼ばれるものを付与（ex: https://hoge.com/callback.html&code=xxxx ）
"AppServer" は受け取った Authentication code を使って Cognito にリクエスト
ID Token を取得
JavaScript では、ページの URL からフラグメントを切り出し、(5)で受け取った ID Token を抜き出すロジックが書かれている。
"AppServer" は HTML/JavaScript/ ID Token を返却。

取得できた 「ID Token」 ですが、「SPA」の場合は "Broser" の 「LocalStorage」 機能を使って保存しておき、以降の通信時に「HTTP Header」に付与して "AppServer" と通信を行うことで認証済みであることを証明します。

次回は実際にサンプルプログラムを作って動作を確認していこうと思います。

「ID Token」ってなんだろう？

認証済みとなったタイミングで "Cognito" に発行された 「ID Token」 とはなんでしょうか？
特徴を挙げてみます。

「JSON Web Token (JWT)」（ジョットと読む）というデータフォーマットで構成
URL-safe（URL として利用出来る文字だけ構成される）な文字列で構成されているため、URL にクエリ文字列(?〜)やフラグメント(#〜)として付与することができる
「ID Token」は以下の情報を ドット( . )区切り で連結したものとなっていまる
1. 電子署名メタ情報
2. 認証されたユーザーの情報
  - name
  - email
  - phone_number など
3. 電子署名

JWT authentication concept - Stack Overflow から、JWT のサンプルを拝借してきました。

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VybmFtZSI6IjEiLCJpZCI6MywiaWF0IjoxNDY1MDMyNjIyLCJleHAiOjE0NjUwNTA2MjJ9.0K8TL1YS0XKnEIfI3lYs-bu2vbWHSNZsVJkN1mXtgWg

ドット( . ) で分割してみます。

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
eyJ1c2VybmFtZSI6IjEiLCJpZCI6MywiaWF0IjoxNDY1MDMyNjIyLCJleHAiOjE0NjUwNTA2MjJ9
0K8TL1YS0XKnEIfI3lYs-bu2vbWHSNZsVJkN1mXtgWg

１つ目の文字列が先に上げた「電子署名メタ情報」、
２つ目の文字列が「認証されたユーザーの情報」、
３つ目の文字列が「電子署名」です。

１つ目と２つ目は Base64 でエンコードされているため、デコードできます。デコードすると以下のような情報が取り出せます。

$ echo `eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9` | base64 -d
{"typ":"JWT","alg":"HS256"}

$ echo 'eyJ1c2VybmFtZSI6IjEiLCJpZCI6MywiaWF0IjoxNDY1MDMyNjIyLCJleHAiOjE0NjUwNTA2MjJ9' | base64 -d
{"username":"1","id":3,"iat":1465032622,"exp":1465050622}