はじめに
現代のWebサービスでは、GoogleログインやGitHubログインなど、
「パスワードを相手アプリに渡さずに認証・認可する仕組み」 が当たり前になってきました。
その中心にある技術が OAuth（オーオース） です。
この記事では、OAuth の歴史から、主要概念、基本フローまでを
コーヒー片手に“するっと理解できる”ように解説します。
1. OAuthとは？
OAuthとは、
ユーザーのパスワードを第三者アプリに渡さず、限定されたアクセス権だけを委譲する仕組み（認可フレームワーク）
です。
- パスワードは出さない
- 必要な権限だけ発行
- トークンはいつでも無効化できる
- もう昔の “パスワード預け文化” には戻れません。
2. OAuth が必要とされた理由（歴史）
■ 1990〜2005年：ID/Password 時代の“危険な常識”
インターネット黎明期から 2000 年代半ばまでは、
「サービス連携＝パスワードを相手アプリに渡す」 が普通でした。
- ブログの投稿連携
- メールクライアントの同期
- 写真サービスの自動アップロード
便利ではあるけれど、
外部アプリがユーザーのパスワードをそのまま握る
という、現代から見れば恐ろしい時代。
もし悪意あるアプリにパスワードを渡してしまったら…
- メール全部読まれる
- 勝手に投稿される
- パスワード使い回しなら他サービスも乗っ取られる
というリスクが常にありました。
■ 2006〜2007年：API 連携ブームと危機感
2006 年ごろから、Twitter や Flickr が API を公開し始め、
世界が「サービス同士をつなぐ」方向へ大きく動き出します。
ところが API 連携が盛り上がるほど、開発者の間では
「このままパスワード渡す文化は無理じゃない？」
という危機感が一気に高まりました。
そこで Twitter / Flickr / OpenID の技術者たち が
メーリングリストで議論を開始し、「パスワードを共有しない仕組み」を模索します。
■ 2007年：OAuth 草案（Draft）誕生
2007年、ついに OAuth の最初の草案が公開されました。
中心となった人物は：
- Blaine Cook（Twitter）
- Chris Messina（“#ハッシュタグ”の提案者）
- Larry Halff（Flickr）
- Dick Hardt（OpenID）
彼らは「ベンダーがバラバラに独自認証を作るより、業界標準にした方が良い」と判断し、
“ユーザーのパスワードを一度も渡さずに連携できる仕組み”
をデザインします。
■ 2007〜2010年：OAuth 1.0 正式化
OAuth 1.0 は 2010 年に RFC 5849 として標準化されました。
しかし当時の OAuth 1.0 は…
- 署名方式（HMAC-SHA1）が複雑
- パラメータが多く、ミスが多発
- モバイルアプリとの相性が悪い
という欠点があり、実装難易度が高すぎる という問題がありました。
■ 2010〜2012年：OAuth 2.0 の再設計
ここから、OAuth の進化が加速します。
背景には、世界の技術トレンドの急変がありました。
- iPhone（2007）、Android（2008）が普及
- スマホアプリが急増
- JavaScript SPA が台頭（Backbone.js → later Angular/React へ）
- IoT が始まり、デバイスが多様化
- API 経済という言葉が生まれ始める
OAuth 1.0 の複雑な署名方式では、これらを全部安全に扱うのは困難でした。
そこで IETF WG（標準化委員会）は 「OAuth 2.0 の全面再設計」 を開始。
■ 2012年：OAuth 2.0 誕生（RFC 6749）
とうとう 2012 年、OAuth 2.0 がリリースされます。
OAuth 2.0 は、OAuth 1.0 のような複雑な署名計算を廃止し、
「HTTPS 前提でシンプルかつ拡張性の高いフレームワーク」 として再構築されました。
その結果：
- Googleログイン
- GitHubログイン
- Facebookログイン
- Apple Sign-in
- LINEログイン
など、現代すべての “ログイン with 〇〇” が OAuth 2.0 ベースになりました。
■ 2014〜2020年：OIDC（OpenID Connect）の普及
OAuth はそもそも「認可」フレームワークであり、
「認証（ログイン）」にはそのままでは使えません。
そこで登場したのが OpenID Connect（OIDC）。
- OAuth 2.0 の上に “ID Token” を追加
- JWT による自己完結型 ID
- シングルサインオンの普及
- モバイルアプリ、SPA と完璧にマッチ
実質、OAuth 2.0 は OIDC とセットで世界標準になりました。
■ 2020〜2024年：PKCE が必須へ（モバイルの安全性確保）
OAuth 2.0 が広く使われる中で、モバイルアプリにおける
認可コード強奪（Auth Code Interception）攻撃 が問題化します。
その対策として登場したのが PKCE（ピクシー）。
2020年代以降は：
- Apple
- LINE
- GitHub
など、事実上 PKCE は必須 になりました。
■ 2021〜現在：OAuth 2.1（ドラフト）
OAuth 2.1 は、OAuth 2.0 のベストプラクティスをまとめ直した改訂版。
重要な変更：
- PKCE が完全必須
- Implicit Flow 廃止
- Password Grant 廃止
- ベストプラクティス仕様（Security BCP）反映
現代では 「認可コード + PKCE」一択 に近い状態です。
■ 現代：Zero Trust / FAPI への進化
OAuth の役割は「連携」だけではなく、
今は Zero Trust や 金融 API (FAPI) の中心技術にまで進化しました。
- 多要素認証との連携（MFA）
- 金融機関レベルの API 保護
- 業務基盤システムの認証
- IoT / 車載デバイス / 産業システム
OAuth はすでに「ログイン技術」ではなく、
“インターネットの信頼の基盤” へと成長しています。
3. OAuth 2.0 の主要概念
■ Resource Owner（リソースオーナー）
データの持ち主（＝ユーザー）
■ Client（クライアント）
アクセスを要求するアプリ
例：スタバ注文アプリ
■ Authorization Server（認可サーバー）
同意画面を出し、トークンを発行するサーバー
■ Resource Server（リソースサーバー）
ユーザーのデータが保存されているサーバー
例：Google Calendar API
■ Access Token
ユーザーに代わって操作するための “一時的な鍵”
寿命は短め（例：30分）
■ Refresh Token
Access Token の更新に利用する長寿命トークン
※厳重に管理すべし
■ Scope（スコープ）
アプリが要求する「アクセス範囲」
例：
-
profile（プロフィール閲覧） -
email（メールアドレス取得） calendar.readonly
「必要な権限だけ」を要求するのがポイント。
4. OAuth の動きが最も理解できる例：コーヒーショップ
あなたがスタバアプリで「決済」をするとき…
-
スタバアプリ：
「決済情報にアクセスしてもいい？」 -
決済会社：
「このアプリを信用しますか？」（同意画面） -
あなた：
「OK」 - 決済会社 → アプリ：Access Tokenを発行
鍵（パスワード）はどこにも渡っていません。
これこそ OAuth の本質です。
5. OAuth 2.0 の基本フロー（認可コードフロー）
もっとも利用されている標準フローです（Web/モバイルで必須）。
OAuthは「パスワードを守るために、トークンという仕組みを使う」技術なのです。
6. OAuth がもたらしたメリット
| メリット | 内容 |
|---|---|
| パスワードを共有しない | セキュリティ上の大革新 |
| 権限を細かく制御できる | scope により最小権限で利用可能 |
| 権限の取り消しが簡単 | トークン単位で revoke |
| マルチプラットフォーム対応 | Web / モバイル / IoT なんでもOK |
7. まとめ
- OAuthは「パスワードを渡さずに第三者に権限を委譲する仕組み」
- 2012年の OAuth 2.0 が現在の世界標準
- Access Token / Refresh Token / Scope がキーワード
- 代表的フローは「認可コード + PKCE」（特にモバイルで必須）
- Google / Apple / GitHub / LINE / Facebook など全てこれを利用
“ユーザーが安心してデータを渡せる世界” を作ったのが OAuth です。