「Google でログイン」「Slack と連携」。この手の機能は、動作確認がとても簡単です。ボタンを押し、許可の画面が出て、自分のアカウントで入れる。5分で終わります。
問題は、OAuth の実装不備が正常系にはまったく現れないことです。自分のアカウントで自分がログインする限り、設定が甘くても正しくても、画面上の挙動は同じです。差が出るのは攻撃を受けたときだけで、そのときには「他人のアカウントに入れる」という形で出ます。
検収の場で発注側が確認できることは、実は多くありません。ただし、確認できる数点は絞れます。
動作確認では見つからない種類の不具合
OAuth の認可コードフローは、ブラウザのリダイレクトを何度か往復して、最後にアプリがアクセストークンを受け取る仕組みです。この往復の途中に攻撃者が割り込める余地をどれだけ残しているかが実装の質を決めます。
代表的なのが認可コードの横取りです。認可サーバーが発行した認可コードは、リダイレクト先のURLに乗って戻ってきます。そのリダイレクト先の検証が緩いと、攻撃者は自分が用意した場所へコードを送らせて、正規利用者になりすませます。 公開クライアント（スマホアプリやブラウザで動くアプリ）では、クライアントシークレットを秘密にできないため、シークレットだけでは防げません。
こうした脅威は RFC 6819 の脅威モデルとして整理され、対策は OAuth 2.0 Security Best Current Practice にまとまっています。つまり「実装者の工夫」ではなく、参照すべき文書がある領域です。ここが検収で使える足がかりになります。
検収で確認する5点
発注側がコードを読めなくても、次の5点は質問で確認できます。答えられない場合、それ自体が結果です。
| 確認する点 | 望ましい答え |
|---|---|
| リダイレクトURIの検証 | 事前登録したURIとの完全一致で検証している |
| PKCE | すべての認可コードフローで使用している |
| state パラメータ | 発行し、戻りで検証している |
| 要求するスコープ | 機能に必要な最小限。追加時は理由を記録 |
| トークンの保管場所 | サーバー側。クライアントに置く場合は保管方法を明示 |
1. リダイレクトURI の検証。 認可サーバー側では、登録済みのURIと完全に一致するものだけを許可すべきとされています。前方一致やワイルドカードでの登録は、攻撃者が自分の宛先を紛れ込ませる余地になります。「開発用に localhost を登録したままかどうか」も、あわせて確認する価値があります。
2. PKCE。 認可コード横取りへの防御です。OAuth 2.1 では、すべての認可コードフローで必須とされています。「公開クライアントではないから不要」という答えが返ってきた場合、それは古い前提です。
3. state パラメータ。 認可のリクエストとレスポンスを紐づけるための値で、CSRF への対策になります。発行しているかだけでなく、戻ってきたときに検証しているかまで聞いてください。発行だけして捨てている実装は珍しくありません。
4. スコープ。 「とりあえず広めに取っておく」が最も起きやすい箇所です。連携先のサービスで、そのアプリが何を読み書きできるのかは利用者にも表示されます。必要以上に広いスコープは、利用者の許可率をそのまま下げます。 権限を必要なときだけ渡す考え方は必要なときだけ権限を渡す運用にも通じます。
5. トークンの保管場所。 アクセストークンとリフレッシュトークンをどこに置いているか。ブラウザのローカルストレージに置いている場合、スクリプト経由で読み取られる経路が残ります。置き場所は設計判断なので、選んだ理由が説明できるかどうかが要点です。
「動いているから大丈夫」が通らない理由
上の5点のうち、満たしていなくても正常系のテストは全部通ります。
リダイレクトURI を前方一致で登録していても、自社のURLへ戻る限り正常に動きます。PKCE を使っていなくても、ログインはできます。state を検証していなくても、普通に使っている分には何も起きません。
だからこそ、受け入れテストの項目に「攻撃されたときの挙動」を書いておかないと、確認の機会がありません。 機能一覧のチェックだけで検収を終える流れになっていると、この層は構造的に見落とされます。
もう1つ、時間差で効いてくる問題があります。認証連携は、作った直後より運用に入ってからのほうが緩みます。 検証環境を追加したときにリダイレクトURIを1本足す、別のサブドメインからも使えるようにする、といった変更が、当初の設計とは無関係に積み上がっていきます。登録済みURIの一覧を年に一度見るだけで、使っていないエントリはかなり見つかります。設定は増える方向にしか動かないので、減らす機会を意図的に作らないと減りません。
AI が書いたコードを受け入れるときの基準を工程として決める話はAI生成コードを納品されたらに書きました。認証まわりは、生成されたコードが「動くが安全ではない」形になりやすい代表例でもあります。MCP サーバーを社内で立てる場合の認証設計はMCPサーバーのOAuth 2.1認証にまとめています。
仕様書に足しておく一行
実装後に指摘するより、実装前に決まっているほうが安く済みます。仕様書や見積依頼に次の一行を入れておくだけで、上の5点は実装前の論点になります。
外部サービスとの認証・認可連携は、OAuth 2.0 Security Best Current Practice に沿って実装し、リダイレクトURIの検証方式・PKCE の使用・state の検証・要求スコープ・トークンの保管場所を設計書に明記する。
この一行の効き方は明確で、「どう実装したか」を後から聞き出す作業が、最初から成果物の一部になります。 見積もりの段階で工数が少し増えることはありますが、後から作り直すより確実に安上がりです。
次にやること
すでに稼働しているサービスでソーシャルログインや外部連携を使っているなら、連携先の管理画面を開いて、登録されているリダイレクトURIの一覧を確認してください。 開発用のURLや、使っていないドメインが残っていることがあります。ここは発注側でも確認できる数少ない箇所です。
これから開発を依頼する場合は、上記の一行を仕様書に入れてください。 実装者が参照する文書が決まるだけで、判断のばらつきがかなり減ります。
外部サービス連携の設計レビュー、既存実装のセキュリティ確認、認証基盤の見直しについては、グリームハブの開発・AI・自動化のご相談で承っています。連携先と既存構成によって確認範囲が変わるため、個別にご相談ください。お問い合わせからどうぞ。
