【入門編】OAuth 2.0の認可コードフローにおけるImplicitフローの廃止推奨理由 – アプリケーションセキュリティ & 安全な開発防御ガイド

鍵を「窓から投げ込む」のはやめよう：OAuth 2.0におけるImplicitフローが引退した理由

こんにちは。セキュリティの現場で日々、泥臭いインシデント対応や設計レビューを行っているエンジニアです。

今日は、OAuth 2.0の世界で「昔は便利だったけれど、今はもう使ってはいけない」と言われているImplicit（インプリシット）フローについてお話しします。

セキュリティの世界では、便利さと安全はしばしばトレードオフの関係にあります。なぜ今まで使われてきた仕組みが「危険」とされ、認可コードフロー＋PKCEという新しい標準へ移行すべきなのか。家の防犯に例えながら、一緒に紐解いていきましょう。

—

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

まず、OAuth 2.0の役割を整理しましょう。これは「あなたの家の鍵を直接渡さずに、特定の部屋（API）だけに入っていいよという『一時的な通行証（アクセストークン）』を発行する仕組み」です。

本来なら、玄関の鍵（パスワード）を渡すのが一番危険ですよね。だからこそ、認可サーバーという「受付」を通すことで、安全に通行証を受け渡そうとしているわけです。

—

1. なぜ「Implicitフロー」は窓から鍵を投げるのか？

Implicitフローは、かつてWebブラウザだけで動くアプリ（SPAなど）で重宝されていました。仕組みを簡単に言うと、「受付（認可サーバー）で認証したら、その場で通行証をURLの末尾（フラグメント）にくっつけてブラウザに送り返す」というものです。

ここが盲点！泥棒の視点

このやり方の最大の問題は、「通行証がブラウザのURLという、誰でも覗ける場所にさらされる」ことです。

ブラウザの履歴： 履歴を見れば、通行証が丸見えです。
Refererヘッダー： 別のページに移動した瞬間、そのWebサイト側に「どの通行証でアクセスしていたか」が筒抜けになります。
悪意のあるスクリプト： ページ内に紛れ込んだ怪しい広告やライブラリが、URLを盗み見るのは造作もないことです。

例えるなら、「大切な鍵を、家の窓から外へ向かって投げ渡している」ようなもの。たまたま通りかかった泥棒が、その鍵を空中でキャッチできてしまうのです。これがImplicitフローが廃止推奨となった最大の理由です。

—

2. 解決策：認可コードフロー＋ PKCE（ピクシー）

では、どうすれば安全に鍵を受け取れるのでしょうか。ここで登場するのが「認可コードフロー＋ PKCE」です。

鍵の受け渡しを「厳重な手続き」に変える

この方式では、いきなり鍵を渡すことはしません。

1. 合言葉（Code Verifier）を決める： アプリ側でランダムな文字列（合言葉）を自分で作ります。
2. 証拠（Code Challenge）を送る： 合言葉をハッシュ化したものだけを、受付（認可サーバー）に先に伝えておきます。
3. 引換券（認可コード）を受け取る： 受付は「わかった、じゃあこの引換券を持ってきて」と、通行証そのものではなく「引換券」だけをブラウザに返します。
4. 鍵と引き換える（PKCEの真骨頂）： アプリは、引換券と「最初に作った合言葉」をサーバー間で直接送信します。

こうすることで、途中で泥棒が引換券を盗んだとしても、「合言葉」を知らないので、引換券を本物の通行証と交換することができないのです。

—

3. 実装のヒント：何を変えればいいの？

もしあなたが今、フロントエンドの開発でOAuthを使っているなら、ライブラリの選定を見直してください。例えば、oidc-client-ts や msal.js などの最新版では、設定一つでPKCEを有効にできます。

設定例（概念コード）

// ライブラリの設定サンプル
const oidcConfig = {
authority: “https://auth.example.com”,
client_id: “your-client-id”,
redirect_uri: “https://your-app.com/callback”,

// Implicitフローではなく、PKCEを利用した認可コードフローを指定
response_type: “code”,

// PKCEを強制的に有効化（最近のライブラリはデフォルトでONなことが多いです）
automaticSilentRenew: true,
loadUserInfo: true,
};

// これにより、ブラウザのURLにトークンが露出せず、
// サーバー間での安全な引換プロセスが実行されます。

—

まとめ：セキュリティの「当たり前」をアップデートしよう

「昔からこれで動いていたから大丈夫」という考え方は、セキュリティの世界では一番の脆弱性です。

Implicitフロー： URLにトークンが漏れる。窓から鍵を投げるようなもの。
認可コードフロー＋PKCE： サーバー間での引き換えにより、通行証が第三者に渡るリスクを徹底的に排除する。

最初は少し難しく感じるかもしれませんが、「なぜダメなのか？」「どうなれば安全なのか？」という仕組みさえ分かれば、怖がる必要はありません。

一歩ずつ、安全な開発の階段を登っていきましょう。それが、あなたの作ったサービスを守り、ユーザーからの信頼を勝ち取る一番の近道ですよ！