採用トップ

テンファイブロゴ
テックブログ

OAuth2.0とは？入門ガイド

はじめに

インターネット上でユーザー認証やアクセス制御がますます複雑化する中、複数のサービス間でユーザーのパスワード情報を共有せずに限定的に権限を委譲する仕組みが強く求められています。
例えば、SNSアカウントを使った「Googleログイン」や「Facebookログイン」のように、ユーザー体験を阻害せずに外部アプリが安全にリソースへアクセスするユースケースは数多く存在します。
こうした課題を体系化して解決したのが、標準的な認可フレームワークOAuth 2.0です。
OAuth 2.0は、ユーザー（Resource Owner：データの所有者）の資格情報をクライアントアプリケーションに直接渡すことなく、代わりにアクセストークン（API等へアクセスするための一時的な鍵）を取得してリソースサーバーへリクエストを行うモデルを採用しています。
この仕組みによってリスクを最小限に抑えつつ、最小権限の原則（Principle of Least Privilege：必要最低限の権限のみを付与する考え方）を徹底し、万一アクセストークンが漏洩した場合の被害範囲も限定可能です。
本記事では、OAuth 2.0の全体像を初心者にも理解しやすいよう分解し、背景から実践までを詳細に解説します。
まずは主要コンポーネントの役割を理解し、その後代表的な認可フローやトークン運用、セキュリティ対策、実装例に至るまでを順に学んでいきましょう。

1. OAuth 2.0の概要と歴史的背景

OAuthはもともと2006年にOAuth 1.0として策定されましたが、署名や暗号化の実装が複雑でコストが高く、採用が広がりにくいという課題がありました。
そこで2012年にRFC 6749として正式標準化されたのがOAuth 2.0で、シンプルさと拡張性を重視した設計が特徴です。
OAuth 2.0では、以下の4つの役割を明確に分離することでセキュリティとスケーラビリティ（拡張性）の両立を図っています。

  • Resource Owner（リソースオーナー：データ所有者）
    保護されたリソース（データ）の所有者、通常はエンドユーザー。
  • Client（クライアント）
    リソースオーナーに代わり認可を要求し、アクセストークンを用いてリソースサーバーへアクセスするアプリケーション。
  • Authorization Server（認可サーバー）
    クライアントの認可要求を検証し、アクセストークンや認可コードを発行するサーバー。
  • Resource Server（リソースサーバー）
    アクセストークンの提示を受けて保護されたリソースを提供するサーバー。

この4者間の分離により、認可サーバーとリソースサーバーを個別にスケールアウトやセキュリティ対策でき、監査ログ（操作履歴記録）の集中管理も可能になります。
また、OAuth 2.0は拡張可能なフレームワークとして設計されており、OpenID Connect（認証拡張）やJWT（JSON Web Token：自己完結型トークン）対応など、多くの派生仕様が生まれています。

2. 主な認可フロー（Grant Type）

OAuth 2.0では、利用シーンやクライアントの特性に応じた複数の認可フロー（Grant Type）を定義しています。
代表的な4種類のフローを、手順・メリット・デメリットとともに解説します。

2.1 Authorization Code Grant（認可コード付与方式）

サーバーサイドアプリケーション（機密クライアント）向けの最もセキュアなフローです。
手順概要：

  1. クライアントがユーザーを認可エンドポイントにリダイレクトし、ログイン・同意を依頼。
  2. ユーザーが認可サーバーで認証し、認可コード（Authorization Code）をクライアントに返却。
  3. クライアントは認可コードとクライアントシークレットを認可サーバーへ送信し、アクセストークンを取得。
  4. 認可サーバーは検証後、アクセストークン（およびリフレッシュトークン）を発行。
    メリット： トークン漏洩リスクが低く、安全性が高い。
    デメリット： リダイレクトやサーバー間通信の実装が必要で、SPA（Single Page Application）には不向き。

2.2 Authorization Code Grant + PKCE（Proof Key for Code Exchange）

モバイルアプリやSPAなどクライアントシークレットを安全に保持できない環境向けの拡張フローです。
認可コード取得時に「Code Verifier／Code Challenge」を用い、中間者攻撃（MitM）や認可コード横取りを防止します。
現在はImplicit Grantの代替として推奨され、多くのプラットフォームで標準対応しています。

2.3 Implicit Grant（暗黙的認可方式）

SPA向けに設計されたフローで、アクセストークンを直接クライアントに返却します。
認可コードフェーズを省略するため即時性がありますが、トークンがURLに含まれるリスクが高く、現在は非推奨となっています。

2.4 Resource Owner Password Credentials Grant（リソースオーナー・パスワード認証方式）

ユーザーがクライアントにID/PWを直接入力する方式です。信頼できる内部アプリ向けに限定使用されますが、セキュリティの観点から現在はほとんど利用されていません。

2.5 Client Credentials Grant（クライアント認証方式）

サーバー間通信（マシン・トゥー・マシン）向けで、ユーザーコンテキストを必要としません。
クライアントID／シークレットだけでアクセストークンを取得し、APIを呼び出します。社内システム連携やバックエンドバッチ等で多用されます。

3. アクセストークンとリフレッシュトークンの運用

アクセストークン（Bearerトークン）は、有効期限を短く設定（数分～数時間）し、漏洩リスクを低減します。
JWT形式を用い、以下のクレーム（ペイロード内情報）を含めることが一般的です。

  • iss：発行者（issuer）
  • sub：主体（subject: ユーザーIDなど）
  • aud：受信者（audience: リソースサーバー識別子）
  • exp：有効期限（expiration: Unixタイムスタンプ）
  • scope：スコープ（付与権限範囲）

リフレッシュトークン（長期有効トークン）は、有効期限切れのアクセストークンを更新するために使用します。 リフレッシュ時にローテーション（古いトークンの失効）を行い、盗用検知やセッション管理を強化しましょう。
また、トークン失効（revocation）エンドポイントを実装し、ユーザーのログアウト時や不正検知時に即座にトークンを無効化できる仕組みが重要です。

4. セキュリティのベストプラクティス

  • HTTPS全通信（TLS）：トークン盗聴を防止するため、認可・リソースサーバー間を含め全通信を暗号化。
  • PKCE導入：Proof Key for Code Exchangeを用い、クライアントシークレットを持たない環境でも安全に認可コードフローを実装。
  • スコープ最小化：必要最低限の権限のみをリクエストし、リスクを抑制。
  • CSRF対策：認可リクエストのstateパラメータ利用やSameSite属性付きCookieで攻撃を防止。
  • トークン保管：アクセストークンはメモリ内に保持し、LocalStorageやSessionStorageでの永続化は避ける。
  • リフレッシュトークンローテーション：継続的に新旧トークンを入れ替え、不正利用を検知・防止。
  • 監視とログ：認可リクエスト、トークン発行、アクセス履歴を監視して不正アクセスを早期検知。

5. 実装例：cURLとNode.jsによるトークン取得と検証

以下のcURLコマンドは、Client Credentials Grantでアクセストークンを取得し、Introspectionエンドポイントでトークン情報を検証する例です。

curl -X POST \
  -d "grant_type=client_credentials&client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET&scope=read" \
  https://auth.example.com/oauth/token

トークン検証（Introspection）：

curl -X POST \
  -u "YOUR_CLIENT_ID:YOUR_CLIENT_SECRET" \
  -d "token=YOUR_ACCESS_TOKEN" \
  https://auth.example.com/oauth/introspect

Node.js (Express) でのミドルウェア例：

const express = require('express');
const axios = require('axios');
const app = express();

async function validateToken(req, res, next) {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.status(401).json({ error: 'No token provided' });

  try {
    const resp = await axios.post(
      'https://auth.example.com/oauth/introspect',
      `token=${token}`,
      {
        auth: { username: 'YOUR_CLIENT_ID', password: 'YOUR_CLIENT_SECRET' },
        headers: { 'Content-Type': 'application/x-www-form-urlencoded' }
      }
    );
    if (resp.data.active) {
      req.user = resp.data;
      next();
    } else {
      res.status(401).json({ error: 'Invalid token' });
    }
  } catch (err) {
    res.status(500).json({ error: 'Introspection failed' });
  }
}

app.use(validateToken);
app.get('/protected', (req, res) => {
  res.json({ message: 'Protected data', user: req.user });
});

app.listen(3000, () => console.log('Server running on http://localhost:3000'));

まとめと今後のステップ

本記事では、OAuth 2.0の歴史的背景から基本モデル、主要認可フロー、トークン運用、セキュリティ対策、実装例までを一貫して解説しました。
OAuth 2.0はそのシンプルかつ拡張可能な設計により、分散システムやマイクロサービス環境での認可基盤として必須技術です。
まずはサンプルコードを動かし、認可コードフローやPKCE、トークンイントロスペクションを自分の手で体験してみましょう。
次のステップとして、OpenID Connect（認証フレームワーク拡張）やToken Binding（トークン結び付け技術）など、より高度な機能にも挑戦してみてください。
OAuth 2.0の深い理解は、セキュアかつスケーラブルなサービス運営に直結し、エンジニアとしての市場価値向上にも大きく寄与します。

参考URL

採用情報 長谷川 横バージョン
SHARE

blog 関連記事

すべて見る
PHP Code Snippets Powered By : XYZScripts.com