// シス担のミカタ
シングルサインオン・ID連携

OAuth 2.0 おーおーす つーてんぜろ

認可アクセストークン認証フローサードパーティ連携OpenID Connectスコープ
OAuth 2.0について教えて

簡単に言うとこんな感じ！

「Googleでログイン」ボタンを押したとき、Googleがそのアプリに「この人のメールアドレスだけ見ていいよ」って許可証を渡す仕組みだよ。パスワードそのものは渡さずに、必要な権限だけ安全に委ねられるってこと！

OAuth 2.0とは

OAuth 2.0（オーオース）は、あるサービスが別のサービスの機能やデータに「パスワードなしで」アクセスするための認可（authorization）の標準プロトコルです。たとえば「Twitterで予約投稿ツールにツイートしてもらう」「Googleカレンダーの予定を別のアプリに読み込ませる」といった連携を安全に実現します。

ポイントは「認証（ログイン）ではなく認可（アクセス許可）」の仕組みだという点です。ユーザーのIDとパスワードをサードパーティアプリに預けるのではなく、「何をどこまで許可するか」を表すアクセストークン（一時的な通行証）だけを渡す設計になっています。

2012年にRFC 6749として標準化され、現在ほぼすべてのクラウドサービス・SNS・ビジネスSaaSで採用されている、ID連携の事実上のデファクトスタンダードです。

OAuth 2.0の登場人物と仕組み

OAuth 2.0には4つの役割が登場します。

役割英語名具体例
リソースオーナーResource Ownerユーザー本人（あなた）
クライアントClient連携したいアプリ（予約投稿ツールなど）
認可サーバーAuthorization ServerGoogle・Microsoftなどの認証基盤
リソースサーバーResource Serverデータを持つAPI（Googleカレンダー等）

認可フローのざっくりイメージ

あなた ──①許可リクエスト──▶ 認可サーバー（Google等）
            ◀──②認可コード────
クライアント ──③コード交換──▶ 認可サーバー
             ◀──④アクセストークン──
クライアント ──⑤トークン提示──▶ リソースサーバー
             ◀──⑥データ取得────

最もよく使われる「認可コードフロー」では、ユーザーが直接認可サーバーにログインし、アプリにはパスワードではなく一時的な「コード」だけが渡ります。そのコードをサーバー間でトークンに交換するため、パスワードが外部に漏れません。

主なフローの種類と使いどころ

フロー名用途セキュリティ強度
認可コードフローWebアプリ・モバイルアプリ（推奨）★★★
認可コード＋PKCESPAやネイティブアプリ★★★
クライアントクレデンシャルサーバー間のAPI連携（人が介在しない）★★
インプリシットフロー現在は非推奨★

スコープで「どこまで許可するか」を制御する

スコープ（scope） は許可範囲を絞るための仕組みです。たとえば calendar.readonly なら「カレンダーの読み取りだけ」、email なら「メールアドレスの取得のみ」と細かく指定できます。業務システム導入時に「このアプリは何のスコープを要求しているか」を確認することがセキュリティ上の重要チェックポイントです。

歴史と背景

  • 2006年 — TwitterとMa.gnoliaのAPI連携で「パスワードを共有せずに認可したい」という課題が浮上、OAuthの議論が始まる
  • 2010年 — OAuth 1.0a が RFC 5849 として標準化。ただし署名処理が複雑で開発者の負担が大きかった
  • 2012年 — 大幅に簡略化・再設計した OAuth 2.0 が RFC 6749/6750 として策定。HTTPSを前提にした設計でシンプルになった
  • 2014年 — OAuth 2.0を土台に「ログインにも使える」拡張仕様として OpenID Connect 1.0 が登場。「Googleでログイン」の技術的基盤になる
  • 2019年 — セキュリティ強化のため PKCE（Proof Key for Code Exchange） が標準化。モバイルアプリ・SPA向けの必須対策に
  • 2023年現在 — OAuth 2.1 の策定が進行中。非推奨フローの整理・PKCEの必須化などを統合する見込み

OAuth 2.0 と OpenID Connect の違い

混同されやすい2つの仕様を整理しましょう。

OAuth 2.0 「認可」の仕様 アクセストークン発行 スコープで権限を絞る 「何ができるか」を委任 例: カレンダーに書き込みOK OpenID Connect 「認証」の拡張仕様（OAuth 2.0の上位） IDトークン（JWT）発行 ユーザー情報エンドポイント 「誰であるか」を証明 例: Googleアカウントでログイン 拡張

覚え方： OAuth = 「お前に何をさせるか（認可）」、OpenID Connect = 「お前が誰か（認証）」

比較項目OAuth 2.0OpenID Connect
目的認可（リソースへのアクセス許可）認証（ユーザーが誰かの確認）
トークンアクセストークンIDトークン（JWT）＋アクセストークン
主な使い道API連携・サービス間データ共有「〜でログイン」ボタン
仕様の関係独立した仕様OAuth 2.0を拡張した上位仕様

実務でのチェックポイント

業務システムを発注・選定するとき、OAuth 2.0が関係する場面でよく問われるポイントをまとめます。

確認事項なぜ重要か
要求スコープの確認「なぜこのアプリがメール送信権限を要求するのか」など不要な権限がないか確認
トークンの有効期限アクセストークンは短命（数時間〜1日）、リフレッシュトークンは長期。漏洩リスクに差がある
PKCEの実装有無モバイルアプリ・SPA系サービスはPKCE必須。未対応は脆弱性リスク
トークン失効の仕組み退職者や退会時にトークンを速やかに無効化できるか
ログ・監査証跡誰がいつどのスコープを認可したか記録されているか

関連する規格・RFC

規格・RFC番号内容
RFC 6749OAuth 2.0 認可フレームワーク本体
RFC 6750Bearerトークンの使い方
RFC 7636PKCE（認可コードフロー強化）
RFC 8693トークン交換（Token Exchange）
OpenID Connect 1.0OAuth 2.0上の認証レイヤー（OpenID Foundation策定）
RFC 9700 (OAuth 2.1草案)OAuth 2.0の整理・統合版（策定中）

関連用語