「Googleでログイン」というボタンを、何も考えずに押していませんか。
便利だから使う。それ自体は悪いことではありません。ただ、自分が作る側にまわる日はいつか来ます。そのとき何に気をつければよいか、いま説明できるでしょうか。
この記事では、いま技術者のあいだで話題になっているOAuthのセキュリティについて、仕組みと代表的な攻撃、そして新社会人エンジニアが押さえるべき点まで解説します。
結論を先に言います。OAuthとはパスワードを渡さずに権限だけを預ける仕組みで、事故の多くは「預けた先をきちんと確かめなかった」ことから起きます。
OAuthとは?パスワードを渡さずに権限だけを預ける仕組み
OAuthとは、自分のパスワードを教えることなく、別のサービスに一部の操作だけを許可するための取り決めです。
なぜこんな仕組みが必要なのでしょうか。理由は、パスワードを渡してしまうと「全部できる」からです。カレンダーの予定を読みたいだけのアプリに、メールの削除まで許すわけにはいきません。
身近なたとえで言えば、ホテルの入口で車を預けるときの鍵に似ています。渡すのは、エンジンはかかるけれどトランクは開かない専用の鍵です。できることをあらかじめ絞ってから渡す、という発想は同じです。
OAuthには登場人物が4つあります。整理しておきましょう。
- リソースオーナー: あなた自身。データの持ち主
- クライアント: 連携したいアプリ。カレンダーを読みたい側
- 認可サーバー: 許可を出す係。Googleのログイン画面がこれにあたる
- リソースサーバー: 実際のデータを持つ係。カレンダーのAPIなど
流れはこうです。アプリがあなたを認可サーバーへ送り、そこで同意すると「認可コード」という引換券が戻ります。アプリは裏側でその引換券を「アクセストークン」に交換し、はじめてデータを取りにいけます。
つまりOAuthとは、鍵そのものではなく、期限と範囲がついた通行証を受け渡す仕組みだといえます。
OAuthのセキュリティがなぜ今あらためて話題なのか
OAuthは10年以上前からある技術です。それがいま話題になっているのは、使われ方が大きく変わってきたからです。
きっかけの一つは、2026年8月17日にZennで公開された無料の技術書「攻撃手法から学ぶ OAuth セキュリティベストプラクティス」です。著者は認可サーバー製品を手がけるAuthleteの共同創設者で、全12章にわたり代表的な攻撃を整理しています。公開直後からZennとはてなブックマークの両方で上位に入りました。
もう一つの流れが、AIエージェントの普及です。AWS Japanが公開した記事では「認可疲れ」という言葉が使われていました。エージェントにGitHubやSlackの作業を任せたのに、サービスごとに許可を求められて止まってしまう状態を指します。
ここで起きているのは、トークンを持ち歩く主体が人からプログラムへ移りつつある、という変化です。人なら不審な画面に気づけますが、エージェントは黙って処理を進めます。だからこそ、渡す範囲をどう絞るかが以前より重い問題になりました。
加えて2025年1月には、OAuthの安全な使い方をまとめたRFC 9700が正式に発行されています。土台となる指針が更新され、そこへAI活用の波が重なった。この2つが、いま議論が活発になっている理由です。
OAuthで狙われる代表的な3つの隙
攻撃はどれも「通行証をどこかで横取りする」ことを狙っています。よく挙げられるものを3つ紹介します。
- リダイレクトURIの検証不足: 認可コードの戻り先の確認がゆるいと、攻撃者のサイトへ引換券が届いてしまう
- 認可コードの差し込み: 攻撃者が自分の取得したコードを、被害者の画面にすべりこませる。気づかないうちに相手のアカウントとつながってしまう
- トークンの盗み出しと使い回し: アクセストークンは持っている人が使える「持参人払い」の性質を持つため、一度漏れると誰でも使えてしまう
3つに共通しているのは、どれも暗号を破っているわけではない点です。設定の甘さや確認の抜けを突いています。つまり実装する側の注意で、かなりの部分は防げます。
OAuthを守るPKCEとDPoPという2つの工夫
対策の考え方は明快です。引換券を横取りされても使えないようにし、通行証を持ち主に縛りつけます。
前者を担うのがPKCE(ピクシー)です。アプリは最初に合言葉を決め、そのハッシュだけを認可サーバーへ預けます。あとでコードを交換するとき、元の合言葉を見せられなければ交換は成立しません。コードだけ盗んでも意味がなくなる、という仕組みです。RFC 9700では、スマホアプリなど秘密を持てないクライアントに対して必須とされました。
後者を担うのがDPoP(ディーポップ)です。トークンをクライアントの鍵とひもづけ、使うたびに署名を求めます。持参人払いの切符を、記名式の切符に変えるイメージだと考えてください。
そのほか、RFC 9700が示す基本方針も押さえておきましょう。
- リダイレクトURIは完全一致で比較する。ワイルドカードなどのあいまいな照合は使わない
- implicit grantは使わない。トークンがURLに現れて漏れやすいため
- パスワードをそのまま送るresource owner password credentials grantも使わない
- アクセストークンのスコープと有効期限は、必要な範囲まで絞る
どれも派手さはありませんが、事故の多くはこの基本を外したところで起きています。
新社会人エンジニアがOAuthで最初に押さえるべきこと
新社会人エンジニアがまず身につけたいのは、認証と認可を言葉として区別することです。
認証は「あなたが誰か」を確かめること、認可は「何をしてよいか」を決めることです。OAuthは名前のとおり認可の仕組みであり、ログインそのものを担うのは上に乗るOpenID Connectのほうです。ここを混ぜたまま設計すると、後から直しにくい穴ができます。
そのうえで、明日から意識できることを3つ挙げます。
- OAuthの処理は自作せず、実績のあるライブラリや認可サーバー製品に任せる
- 連携で要求するスコープは、いま必要な最小限にとどめる
- トークンをログに出さない。URLのクエリにも載せない
2つめは、自分がユーザーとして外部連携を許可するときにも効きます。同意画面に並ぶ権限を読む習慣がつくと、設計する側にまわったときの感覚が変わります。
まとめ:OAuthで押さえる3つのポイント
- OAuthとは、パスワードを渡さずに範囲と期限つきの通行証を預ける仕組み
- 狙われるのは暗号ではなく、リダイレクト先の確認不足やトークンの持ち回りといった運用の隙
- PKCEとDPoP、そしてリダイレクトURIの完全一致が、いまの標準的な守り方
まずは自分が普段使っているサービスで、外部連携の同意画面をひらいてみてください。どんな権限を渡しているかを読むところから理解が始まります。
コメント