AWS 26：ログイン ― Cognito で認証を借りる

受付は、専門の会社に任せる

大きなオフィスビルを思い浮かべてください。入口の受付では、警備会社の人が身分証を確かめ、入館証を渡します。各部屋の人は、訪問者の身分証を自分で調べません。入館証が本物かどうかだけを見て、ドアを開けます。

Cognito は、この受付の役目を引き受けます。

この形にすると、パスワードはアプリの DB に一度も入りません。アプリが知っているのは、「Cognito が本人と確かめた、この ID の人」ということだけです。もしアプリの DB が漏れても、パスワードは漏れようがありません。

二段階認証、パスワードの再設定、総当たりの防止、Google などでのログインといった面倒な仕事は、受付側（Cognito）の機能として用意されています。アプリを作る人は、その設定を選ぶだけで済みます。

「誰か」は Cognito、「何をしてよいか」はアプリ

第3章で、認証（あなたは誰か）と認可（あなたは何をしてよいか）の違いを学びました。ここでもう一度、この2つを分けて考えます。

Cognito が教えてくれるのは、「この人は sub が a1b2-… の利用者です」という認証の結果までです。「その写真の持ち主は a1b2-… か」を DB で確かめて、消してよいかを決めるのは、アプリの仕事のままです。

ここを勘違いして、「ログインしている人なら何でもできる」作りにすると、他人の写真を消せてしまいます。認証を借りても、認可は自分で書くことを忘れないでください。

もう1つ、第3章の IAM との違いも整理しておきます。IAM は「AWS を操作する人やプログラム」（開発者やサーバー）の認証と認可です。Cognito は「あなたのサービスの利用者」の認証です。フォトログの利用者に IAM ユーザーを作ることはありません。

ユーザープール：利用者の名簿と、ログインの窓口

Cognito の中心はユーザープールです。ユーザープールは、利用者の名簿と、ログインのための機能をひとまとめにしたものです。ふつうは、1つのサービスに1つ作ります。

もう1つ大事なのがアプリクライアントです。これは「このユーザープールを、どのアプリが使うか」の登録です。フォトログの Web 版とスマホ版を、別々のクライアントとして登録できます。クライアントごとに、ログインが終わったあとに戻る先の URL（コールバック URL）や、トークンの有効期間を決めます。

Web のブラウザやスマホのように、中身を利用者に見られてしまうアプリでは、クライアントシークレット（合言葉）を使わない設定にします。ブラウザに合言葉を置いても、すぐに読まれてしまうからです。

ログインの流れ ①：Cognito の画面でログインする

ここから、ログインしてから写真の一覧を取るまでの流れを、図の舞台で追います。左がブラウザ、上が Cognito、下がフォトログの API です。

利用者が「ログイン」を押すと、ブラウザはCognito のログイン画面（マネージドログイン）へ移ります。利用者は、そこでメールアドレスとパスワードを入れます。二段階認証を有効にしていれば、続けて認証アプリのコードも入れます。「Google でログイン」を選んだ場合は、Google の画面で同意します。

図の小包が「パスワード」を運んでいる先は、Cognito です。フォトログの API には届きません。これが、この仕組みのいちばん大事な点です。

ログイン画面を自分で作り、そこから Cognito の API を呼んでログインさせることもできます。見た目を細かく作り込みたいときの方法です。ただしその場合、パスワードがいったんアプリの画面を通るので、扱いに注意が必要です。まずはマネージドログインから始めるのがおすすめです。

ログインの流れ ②：トークンを受け取る

本人確認が済むと、Cognito はブラウザを、決めておいたコールバック URL（フォトログのページ）へ戻します。このとき、ブラウザはトークンを受け取ります。

トークンは、「Cognito が、この人を本人と確かめました」ということを書いた、署名入りのデータです。入館証にあたります。

正確には、次の2段階で受け取ります。

この手順は OAuth 2.0 の認可コードフローと呼ばれる、世界共通の決まりです。ブラウザのように合言葉を持てないアプリでは、PKCE（ピクシー）という、引換券を横取りされても使えなくする工夫を合わせて使います。多くのライブラリは、これを自動でやってくれます。

受け取るトークンは3種類あります。ID トークン、アクセストークン、リフレッシュトークンです。それぞれの役目は、この後で説明します。

ログインの流れ ③：API にトークンを見せる

ログインが済んだブラウザは、フォトログの API を呼ぶたびに、アクセストークンを添えます。HTTP（ブラウザとサーバーのやり取りの決まり）の Authorization という欄（ヘッダー）に、Bearer（持参人）という言葉に続けて書くのが決まりです。

GET /api/photos
Authorization: Bearer eyJraWQiOiJ...

API は、受け取ったトークンについて次のことを確かめます。

すべて通れば、トークンの中にある sub（利用者の ID）を取り出し、「この人の写真の一覧」を DB から読んで返します。

ここで大事なのは、API は Cognito に毎回問い合わせなくてよいことです。トークンには署名があるので、API は手元で本物か確かめられます。何万回呼ばれても、Cognito との往復は増えません。これは、第12章の「ステートレス」とも相性がよい形です。どのサーバーが受けても、同じ確かめ方で済みます。

3つのトークンと、それぞれの役目

Cognito が返す3つのトークンを整理します。

有効期間には、次のような既定値があります。アプリクライアントごとに変えられます。

なぜ、わざわざ3つに分けるのでしょうか。アクセストークンは短く、リフレッシュトークンは長くすることで、安全と便利を両立するためです。

API に何度も送るアクセストークンは、どこかで盗まれる可能性が相対的に高くなります。でも1時間で切れるので、盗まれても使える時間は短くて済みます。切れたら、ブラウザはリフレッシュトークンを Cognito に渡して、新しいアクセストークンを受け取ります。利用者はログインし直す必要がありません。

リフレッシュトークンは長く有効なので、いちばん大事に扱います。ログアウトのときには、Cognito にリフレッシュトークンを無効にするよう頼むこともできます。

トークンの中身：JWT は「署名入りの手紙」

Cognito のトークン（ID とアクセス）は、JWT（JSON Web Token、ジョットとも読む）という形式です。JWT は、3つの部分を .（ドット）でつないだ1本の文字列です。

署名の仕組みを、手紙にたとえます。Cognito は、手紙（1と2）に、自分にしか押せない印鑑（秘密鍵での署名）を押します。印鑑の見本（公開鍵）は誰にでも配られています。受け取った人は、見本と照らせば「本当に Cognito が押したか」「押した後で書き換えられていないか」がわかります。1文字でも書き換えれば、印影と合わなくなります。

注意点が2つあります。

中身は暗号化されていません。 誰でも読めます。だから、パスワードや秘密の情報を入れてはいけません。

人を見分けるには `sub` を使います。 メールアドレスは利用者が変えられるので、DB のキーにすると、変えた瞬間に別人扱いになります。sub は利用者ごとに決まり、変わりません。

API での確かめ方：署名・期限・宛先の3つ

API がトークンを確かめるときは、図の4点をすべて見ます。

公開鍵は、Cognito がユーザープールごとに決まった URL で公開しています。この鍵の一覧を JWKS（JSON Web Key Set）と呼びます。API は一度取ってきて手元に置いておき、トークンのヘッダーにある kid に合う鍵で確かめます。

これらを自分で1つずつ書くのは、間違いのもとです。AWS が公開している aws-jwt-verify のような、専用のライブラリに任せましょう。4点をまとめて確かめ、公開鍵の取得と手元での保管もやってくれます（作り方のところでコードを見ます）。

後で見るように、API Gateway や ALB に、この確認そのものを任せることもできます。

「Google でログイン」も、ユーザープールがまとめる

利用者の多くは、新しいパスワードを作るより、「Google でログイン」「Apple でサインイン」のほうを好みます。ユーザープールは、こうした外部の ID とつなぐことができます。

大事なのは、どこからログインしても、アプリが受け取るトークンは同じ形だということです。Google でログインした人も、パスワードでログインした人も、ユーザープールの中では1人の利用者として sub を持ち、同じ形の JWT が発行されます。

アプリは「この人がどの方法でログインしたか」を気にせず、いつもと同じように sub で人を見分ければよいのです。ログインの方法を後から増やしても、アプリのコードはほとんど変わりません。

Google などとつなぐには、それぞれの開発者向けの画面でフォトログを登録し、発行された ID と合言葉を Cognito に設定します。

ID プール：ログインした人に、AWS の一時的な鍵を渡す

Cognito には、ユーザープールとは別に ID プール（アイデンティティプール）という機能があります。名前が似ていますが、役目はまったく違います。

図の流れでは、スマホアプリが①ユーザープールでログインし、②そのトークンを ID プールに渡して、IAM ロールの一時的な鍵を受け取ります。③その鍵で、S3 の「自分のフォルダだけ」に写真を直接置きます。鍵は数時間で切れ、ロールの権限の範囲でしか使えません。

では、フォトログでも ID プールを使うべきでしょうか。答えは「使わない」です。第15章で、写真のアップロードには署名付き URLを使いました。API が「この1枚だけ、15分だけ置いてよい」という URL を発行する形です。こちらのほうが、何をどこに置けるかを API がきめ細かく決められます。

ID プールは、スマホアプリから AWS の複数のサービスを直接たくさん使うような場合に検討します。ログインしていないゲストにも、ごく限られた権限の鍵を渡すことができます。

API Gateway・ALB に、トークンの確認を任せる

トークンの確認は、アプリの手前にある入口にも任せられます。

API Gateway（第22章） では、オーソライザーという「門番」を設定できます。HTTP API では JWT オーソライザー、REST API では Cognito 用のオーソライザーを使います。トークンが偽物や期限切れなら、API Gateway が 401（認証されていません、という応答）で断り、Lambda は起動すらしません。本物なら、トークンの中身（sub など）が Lambda に渡されます。無駄な起動が減るので、お金の面でも得です。

ALB（第11章） では、HTTPS のリスナーに「Cognito で認証する」という動作を足せます。ログインしていない人がやってくると、ALB が Cognito のログイン画面へ送り、ログインが済んでからサーバーへ転送します。ログインした人の情報は、x-amzn-oidc-data などのヘッダーでサーバーに届きます。

どちらを使っても、認可はアプリの仕事のままです。入口が教えてくれるのは「誰か」だけです。

作り方：ユーザープールを作り、API で確かめる

コンソールで作る流れは次のとおりです。

API 側（Node.js）では、AWS が公開しているライブラリ aws-jwt-verify を使うと、図の右のように短く書けます。

import { CognitoJwtVerifier } from "aws-jwt-verify";

const verifier = CognitoJwtVerifier.create({
  userPoolId: "ap-northeast-1_xxxx",
  tokenUse: "access",
  clientId: "xxxx",
});

// 偽物・期限切れ・別アプリ宛てなら例外になる
const payload = await verifier.verify(token);
const userId = payload.sub; // 利用者の変わらない ID

tokenUse と clientId を指定することで、先に見た「種類」と「宛先」も確かめられます。ユーザープールの ID やクライアント ID は秘密ではありませんが、環境ごとに違うので、設定として外から渡します。IaC（第18章）で作る場合も、作るものは「ユーザープール・アプリクライアント・ドメイン」の3つです。

フォトログでは：パスワードを DB から消す

フォトログを Cognito に移すと、users 表は図のように変わります。

写真やいいねの表は、users の sub とつなぎます。

すでに登録している利用者はどうするのでしょうか。全員に「パスワードを作り直してください」と頼むのは乱暴です。Cognito には、ログインのときに独自の処理を差し込む Lambda トリガーという仕組みがあり、その1つにユーザー移行のトリガーがあります。

こうして、ログインした人から順に移っていきます。十分な期間がたったら、古いパスワードの列を消します。これで、フォトログの DB が漏れてもパスワードは漏れません。

お金：月に何人がログインしたか

Cognito のユーザープールの料金は、主に MAU（Monthly Active Users、その月にログインなどをした利用者の数）で決まります。登録しているだけで、その月に一度も来なかった人は数えません。

ユーザープールには3つのプランがあり、使える機能と単価が違います。

プランはあとから切り替えられます。Lite と Essentials には、毎月一定の MAU まで無料で使える枠があります（Plus にはありません）。単価と無料枠の大きさは、料金ページで確かめてください。

MAU とは別にかかるものもあります。

よくある落とし穴

Cognito に任せても、使い方を間違えれば事故は起きます。

特に「後で変えられない設定」は、作り直すと利用者全員が登録し直しになります。本番用のユーザープールは、IaC（第18章）で設定を確かめてから作りましょう。

いつ Cognito を選ぶか

Cognito は、「AWS の上で、自分のサービスの利用者を持つ」ときの第一候補です。

AWS の外にも、Auth0 や Firebase Authentication のような、ログインを借りるサービスがあります。どれを選んでも構いません。大事なのは、パスワードの保管や本人確認を自作しないことです。

判断の問いは、「このログインの利用者は、誰か」です。サービスの利用者なら Cognito（またはそれに類するサービス）、AWS を操作する社員なら IAM Identity Center、プログラムなら IAM ロールです。この3つを混ぜないことが、守りの基本になります。

片付け：ドメイン → 削除保護 → プール

練習で作ったユーザープールを消すときは、順番があります。

CLI では次のようになります（ID とドメインは自分のものに置き換えます）。

aws cognito-idp delete-user-pool-domain --domain photolog-xxxx --user-pool-id ap-northeast-1_xxxx
aws cognito-idp delete-user-pool --user-pool-id ap-northeast-1_xxxx

削除保護を無効にするのは、コンソールのユーザープールの設定から行えます。

ユーザー移行のために作った Lambda や、Google などの外部サービスに登録したアプリの設定も、練習用なら一緒に消しておきます。

本番のユーザープールを消すと、利用者は全員ログインできなくなり、元に戻す方法はありません。 削除保護は、本番では必ず有効にしておきましょう。