【入門編】 OAuth 2.0の認可コードフロー(Authorization Code Flow)のシーケンスとセキュリティ – Web APIアーキテクチャ・データ連携実践ガイド

OAuth 2.0の「認可コードフロー」を完全攻略！郵便配達で理解するセキュリティの極意

こんにちは！ネットワークの世界にどっぷりと浸かり、日々パケットの行方を追いかけているインフラエンジニアです。

皆さんは「OAuth 2.0」という言葉を聞いたとき、どんなイメージを持ちますか？「なんだか難しそうな認証の仕組みだな……」と身構えてしまうかもしれません。でも大丈夫。実はこの仕組み、私たちが普段利用している「郵便の配達」や「ホテルのチェックイン」と驚くほど似ているんです。

今回は、OAuth 2.0の中でも最も標準的で安全性が高い「認可コードフロー」について、専門用語の壁を乗り越えて一緒に紐解いていきましょう！

—

1. そもそもOAuth 2.0は何のためにあるの？

私たちがWebアプリを作る際、「Googleの連絡先を使いたい」「Twitterに投稿したい」というケースは非常に多いですよね。このとき、ユーザーのパスワードをアプリ側に教えるのは非常に危険です。

そこで登場するのがOAuth 2.0です。「パスワードを渡さずに、特定の機能を使う権利（アクセストークン）だけを貸し出す」ための仕組み。これこそがOAuth 2.0の正体です。

—

2. 郵便配達で例える「認可コードフロー」の全貌

認可コードフローには、主に3つの登場人物がいます。

1. ユーザー（あなた）：サービスを利用したい人。
2. クライアント（アプリ）：あなたの代わりにデータにアクセスしたいWebサービス。
3. 認可サーバー（郵便局）：誰にどの権限を与えるか管理し、チケット（トークン）を発行する場所。

シーケンスの流れを追ってみよう

1. 認可リクエスト（手紙を出す）
アプリが「このユーザーのデータにアクセスしたいです！」と認可サーバーにリクエストを送ります。
2. 認可コードの発行（引換券をもらう）
ユーザーがログインして許可すると、認可サーバーから「認可コード」という「引換券」が返ってきます。
3. アクセストークンの交換（引換券と本物のチケットを交換）
アプリは、この「引換券」を認可サーバーに持っていき、「本物のアクセストークン」と交換します。

なぜ「引換券（認可コード）」を一度挟むのか？それは、ブラウザという「誰でも覗き見できる場所」に、直接アクセストークンを流さないためです。これもセキュリティのための賢い工夫ですね。

—

3. 「絶対忘れてはいけない」セキュリティ対策：ステート(state)とリダイレクトURI

現場で最も怖いのが、悪意のある第三者があなたの認可コードを盗み見ようとする「CSRF攻撃」です。これを防ぐのが state パラメータです。

郵便配達の「合言葉」

state パラメータは、いわば「合言葉」です。
アプリから認可リクエストを出すときに、適当なランダムな文字列（例：abc123xyz）を添えて送ります。認可サーバーは、戻ってきたときにその合言葉が一致しているかを確認します。もし一致していなければ、「おや、これは途中で誰かが介入した偽物だな！」と判断できるわけです。

リダイレクトURIの固定

redirect_uri も極めて重要です。これは「チケットをどこに届けるか」という住所です。これを事前に認可サーバーに登録しておかないと、攻撃者のサーバーにチケットを横取りされてしまう可能性があります。「信頼できる住所」以外には絶対に送らない。これが鉄則です。

—

4. 実践：認可リクエストを送る際のイメージ

実際にアプリが認可サーバーへ送るURLは、以下のような形になります。

# ユーザーを認可サーバーへ誘導するURLの例
GET https://auth.example.com/authorize?
  response_type=code&                # 認可コードフローを使いますという宣言
  client_id=YOUR_CLIENT_ID&          # アプリのID（身分証）
  redirect_uri=https://app.com/callback& # チケットを届ける住所
  scope=read_contacts&               # 何をしたいかの権限
  state=RANDOM_STRING_FOR_SECURITY   # CSRF対策の合言葉

このURLをブラウザで開くと、認可サーバーのログイン画面に飛びます。許可が終わると、https://app.com/callback?code=AUTH_CODE_HERE&state=RANDOM_STRING_FOR_SECURITY のように認可コードが返ってきます。

—

5. 最後に：インフラエンジニアからのアドバイス

OAuth 2.0を実装する際、一番の落とし穴は「リダイレクトURIの不備」や「stateの検証漏れ」です。

本番環境では必ずHTTPSを使うこと：パケットを盗聴されたら意味がありません。
クライアントシークレットを隠す：client_secret はパスワードと同じです。サーバーサイドの環境変数に隠し、絶対にフロントエンドのコードに書かないでくださいね。

ネットワークを流れるパケットは、時に冷徹で容赦ありません。しかし、こうしたプロトコルの仕組みを理解すれば、あなたのサービスはより強固で美しいものになります。

一歩ずつ、確実に理解していきましょう。次のステップとして、実際に curl コマンドでトークンを取得する実験をしてみるのもおすすめですよ。何か詰まったら、いつでもまた聞きに来てくださいね！