OAuth2.0とは？基本概念から最新のOAuth2.1まで徹底解説！

「OAuth2.0とは何か？」と疑問に思ったことはありませんか？

Webサービスやアプリ開発に関わる中で、OAuth 2.0は避けて通れない重要な技術です。

しかし、「認証と認可の違いがわからない」「どの認可フローを使えばいいのか迷う」「アクセストークンの管理が不安」と悩む人も多いでしょう。

本記事では、OAuth 2.0の基本概念から実際の活用方法、最新のOAuth 2.1の動向までをわかりやすく解説します。

初心者でも理解しやすいよう、具体例や図解を交えて説明するので、この記事を読めばOAuth 2.0の仕組みがしっかりと理解できます。

ぜひ最後までご覧ください！

外資系エンジニア

この記事は以下のような人におすすめ！

OAuth 2.0とは何か知りたい人

認証と認可の違いがよくわからない

OAuth 2.0の認可フローはどれを選べばいいのかわからない

1 OAuth 2.0とは何か
- 1.1 1-1. 認証と認可の違い
- 1.2 1-2. OAuth 1.0からの進化
2 OAuth 2.0の基本概念
3 OAuth 2.0の主要な認可フロー
4 OAuth 2.0の実際の利用例
- 4.1 4-1. ソーシャルログインの実装方法
- 4.2 4-2. API連携における認可の活用
5 OAuth 2.0のセキュリティ上の注意点
6 OAuth 2.0の最新動向と今後の展望
- 6.1 6-1. OAuth 2.1の提案と変更点

OAuth 2.0とは何か

OAuth 2.0とは、インターネット上で安全に認可（アクセス許可）を行うための標準的なプロトコルです。

特に、外部のアプリケーションやサービスがユーザーのパスワードを直接扱うことなく、特定のリソースにアクセスできるようにする仕組みとして広く利用されています。

例えば、Googleアカウントを使って他のWebサービス（例：FacebookやTwitter）にログインする「ソーシャルログイン」は、OAuth 2.0を活用した代表的な機能です。

OAuth 2.0の基本概念を理解するためには、まず「認証」と「認可」の違いを知ることが重要です。

1-1. 認証と認可の違い

OAuth 2.0を理解するうえで、「認証」と「認可」という2つの概念の違いを押さえておく必要があります。

用語	説明	例
認証（Authentication）	ユーザーが「本人である」ことを確認するプロセス	Webサイトにログインするときに、ユーザー名とパスワードを入力する
認可（Authorization）	あるユーザーやアプリが「特定のデータや機能にアクセスできる」ことを許可するプロセス	Googleアカウントを使って外部アプリにカレンダーの予定を読み取る権限を与える

1-1-1. なぜ「認可」が重要なのか？

従来のログインシステムでは、外部のアプリがユーザーのパスワードを直接扱う必要がありました。しかし、それではセキュリティリスクが高まります。

例えば、あるアプリがユーザーのパスワードを保存していた場合、そのアプリが悪意を持っていたり、ハッキングされたりすると、ユーザーのパスワードが漏洩する可能性があります。

OAuth 2.0では、ユーザーのパスワードを直接入力せずに「認可」する仕組みを提供することで、このようなリスクを回避します。

この仕組みにより、以下のようなメリットがあります。

セキュリティ向上：パスワードを外部サービスに渡さなくても、認可された範囲内でアクセスを許可できる。
ユーザー体験の向上：一度認可すれば、パスワードを入力することなくスムーズにアクセスできる。

1-2. OAuth 1.0からの進化

OAuth 2.0は、OAuth 1.0の課題を解決し、より柔軟で安全なプロトコルへと進化しました。

1-2-1. OAuth 1.0の問題点

OAuth 1.0は2007年に登場し、外部サービスが安全に認可を受けるための仕組みを提供しました。

しかし、以下のような課題がありました。

開発の難易度が高い
- OAuth 1.0では、リクエストごとに署名を生成しなければならず、実装が複雑でした。
モバイル環境に適していない
- 当時は主にWebサイト向けに設計されており、スマートフォンアプリなどのモバイル環境では扱いづらかった。
トークンの管理が煩雑
- OAuth 1.0では「アクセストークン」と「リクエストトークン」の2種類を管理する必要があり、開発者にとって負担が大きかった。

1-2-2. OAuth 2.0での改善点

OAuth 2.0は、OAuth 1.0の問題を解決し、より柔軟に使えるように設計されています。

改善点	説明
署名の廃止	リクエストごとの署名が不要になり、開発が容易になった。
アクセストークンの簡素化	1つのアクセストークンでAPIアクセスを管理できるようになり、開発負担が軽減。
認可フローの追加	モバイルアプリやシングルページアプリ（SPA）向けの認可フローを導入し、より多様な環境に対応。
スコープの導入	ユーザーが許可する範囲（スコープ）を細かく指定できるようになり、セキュリティが向上。

このように、OAuth 2.0はOAuth 1.0よりも開発しやすく、セキュリティ面でも改善されたプロトコルとなっています。

そのため、多くのWebサービスやアプリで広く採用されており、現在では業界標準として確立されています。

OAuth 2.0の基本概念

OAuth 2.0を正しく理解するためには、登場する主要な要素を把握することが重要です。

OAuth 2.0は、複数の異なる役割を持つコンポーネントが連携することで成り立っています。

ここでは、OAuth 2.0の仕組みを構成する5つの主要な要素を紹介します。

リソースオーナー（ユーザー） – 自分のデータへのアクセスを許可する人物や組織
クライアント（アプリケーション） – ユーザーのデータを取得・利用するアプリケーション
リソースサーバー – 実際にデータを保管し、提供するサーバー
認可サーバー – ユーザーの認可を管理し、トークンを発行するサーバー
アクセストークンとリフレッシュトークン – クライアントがリソースにアクセスするための鍵

これらの要素がどのように連携しているのかを詳しく見ていきましょう。

2-1. リソースオーナー（ユーザー）

リソースオーナーとは、自分のデータに対するアクセス権を持つ人物や組織のことを指します。

一般的には、サービスを利用するユーザーがリソースオーナーになります。

2-1-1. リソースオーナーの具体例

例えば、Googleのカレンダーに保存された予定情報を考えてみましょう。

あなた（ユーザー）は、Googleカレンダーに保存されている予定情報の所有者です。
その予定情報を外部のアプリ（例：スケジュール管理アプリ）と連携させたい場合、OAuth 2.0を使ってアプリに対してアクセス権を与えることができます。

このように、リソースオーナーは「どのデータを、どのアプリに対して許可するのか」を決定する役割を持っています。

2-2. クライアント（アプリケーション）

クライアントとは、リソースオーナーのデータにアクセスし、それを利用するアプリケーションやサービスのことを指します。

2-2-1. クライアントの種類

OAuth 2.0では、クライアントには大きく分けて以下の2種類があります。

クライアントの種類	説明	例
コンフィデンシャルクライアント	クライアントシークレット（秘密鍵）を安全に保管できる	サーバー上で動作するWebアプリ
パブリッククライアント	クライアントシークレットを保管できない	モバイルアプリやシングルページアプリ（SPA）

パブリッククライアントはセキュリティ上のリスクが高いため、適切なセキュリティ対策が必要になります。

2-3. リソースサーバー

リソースサーバーは、リソースオーナーのデータを保管し、クライアントからのリクエストに応じてデータを提供するサーバーです。

2-3-1. リソースサーバーの具体例

Google Drive（ユーザーのファイルを保管）
Twitter API（ユーザーのツイートデータを提供）
Facebook Graph API（ユーザーのプロフィール情報を提供）

リソースサーバーは、認可サーバーから発行されたアクセストークンを確認し、適切なリクエストかどうかを判断します。

2-4. 認可サーバー

認可サーバーは、OAuth 2.0の中心的な役割を持つサーバーで、ユーザーの認可を管理し、アクセストークンを発行する役割を担います。

2-4-1. 認可サーバーの役割

ユーザーの認証
- 「このユーザーは本当に正しいか？」を確認
クライアントの認可
- 「このアプリにデータアクセスを許可して良いか？」をユーザーに確認
アクセストークンの発行
- 認可されたアプリに対して、アクセス権を示すアクセストークンを発行

例えば、Googleアカウントで別のWebサービスにログインする場合、Googleの認可サーバーが「このユーザーが本当に本人か？」を確認し、「このサービスに対してGoogleのデータへのアクセスを許可するか？」を判断します。

2-5. アクセストークンとリフレッシュトークン

OAuth 2.0では、アクセストークンとリフレッシュトークンの2種類のトークンを使用します。

2-5-1. アクセストークン

アクセストークンは、クライアントがリソースサーバーにリクエストを送る際に必要な鍵（キー）です。

一定時間が経過すると無効になる（セキュリティ対策のため）
クライアントはアクセストークンを使ってリソースサーバーにデータの取得をリクエストする

2-5-2. リフレッシュトークン

リフレッシュトークンは、アクセストークンの期限が切れた際に、新しいアクセストークンを取得するためのトークンです。

アクセストークンの期限が切れても、リフレッシュトークンを使えば再認証不要で新しいアクセストークンを取得できる
これにより、ユーザーの利便性が向上し、頻繁なログインを防ぐことができる

トークンの種類	役割	有効期限
アクセストークン	リソースサーバーへのアクセス用	数分〜数時間
リフレッシュトークン	新しいアクセストークンを取得するためのトークン	数日〜数週間

OAuth 2.0の主要な認可フロー

OAuth 2.0には、用途や環境に応じて選択できる複数の認可フロー（グラントタイプ）があります。

これにより、Webアプリ、モバイルアプリ、サーバーアプリなど、さまざまな形態のアプリケーションが適切な方法で認可を受けられるようになっています。

主な認可フローは次の4つです。

認可フロー	主な用途	特徴
認可コードグラント	Webアプリ	セキュアで広く利用される方式
インプリシットグラント	シングルページアプリ（SPA）	簡単だがセキュリティリスクがある
リソースオーナーパスワードクレデンシャルズグラント	信頼できるアプリ	ユーザーのIDとパスワードを直接扱う
クライアントクレデンシャルズグラント	サーバー間の認証	ユーザーを伴わないシステム間連携

それぞれのフローについて、詳しく解説していきます。

3-1. 認可コードグラント

認可コードグラントは、OAuth 2.0で最も広く利用される認可フローです。

セキュリティが高く、多くのWebアプリケーションで採用されています。

3-1-1. 認可コードグラントの流れ

ユーザーが「○○でログイン」ボタンをクリック
アプリが認可サーバーにリダイレクト（認可コードを取得）
ユーザーが認証し、アプリにアクセスを許可
認可サーバーがアプリに認可コードを送信
アプリが認可コードを使い、アクセストークンを取得
アプリがアクセストークンを使用して、リソースサーバーにデータをリクエスト

この方式は、アクセストークンが直接URLを通じてやり取りされないため、比較的安全です。

3-1-2. 認可コードグラントのメリット

アクセストークンが直接URLに露出しない（セキュリティ向上）
リフレッシュトークンが利用可能（長期間のアクセスが可能）
多くのWebサービスで標準的に採用されている

3-2. インプリシットグラント

インプリシットグラントは、シングルページアプリ（SPA）やモバイルアプリで使われる認可フローです。

認可コードを取得する手順を省略し、アクセストークンを直接発行する点が特徴です。

3-2-1. インプリシットグラントの流れ

ユーザーが「○○でログイン」ボタンをクリック
アプリが認可サーバーにリダイレクト（アクセストークンを直接取得）
アプリがアクセストークンを使用して、リソースサーバーにデータをリクエスト

この方式は、認可コードグラントより簡単ですが、アクセストークンが直接URLを通じて送信されるため、セキュリティリスクが高いとされています。

3-2-2. インプリシットグラントのデメリット

アクセストークンがURLに露出しやすい（盗聴リスクあり）
リフレッシュトークンが使用できない（長期間のアクセスが難しい）
OAuth 2.1では非推奨（セキュリティリスクが理由）

現在では、インプリシットグラントの代わりに「PKCE（ピクシー）」を使った認可コードグラントが推奨されています。

3-3. リソースオーナーパスワードクレデンシャルズグラント

この方式では、ユーザーが自分のIDとパスワードを直接アプリに入力し、アクセストークンを取得します。

3-3-1. リソースオーナーパスワードクレデンシャルズグラントの流れ

ユーザーがアプリにIDとパスワードを入力
アプリが認可サーバーにIDとパスワードを送信
認可サーバーがアクセストークンを発行し、アプリに送信
アプリがアクセストークンを使用してリソースサーバーにデータをリクエスト

この方式は、ユーザーのパスワードをアプリが直接扱うため、セキュリティリスクが高いとされています。

そのため、信頼できるアプリ（企業の公式アプリなど）でのみ使用されます。

3-3-2. リソースオーナーパスワードクレデンシャルズグラントのデメリット

ユーザーのパスワードを直接扱うため、漏洩リスクが高い
外部サービスとの連携には適さない（内部アプリ向け）
OAuth 2.1では非推奨（セキュリティ上の問題が多いため）

3-4. クライアントクレデンシャルズグラント

クライアントクレデンシャルズグラントは、ユーザーを伴わないシステム間連携に使用される認可フローです。

3-4-1. クライアントクレデンシャルズグラントの流れ

アプリ（クライアント）が認可サーバーにクライアントIDとクライアントシークレットを送信
認可サーバーがアクセストークンを発行
アプリがアクセストークンを使用してリソースサーバーにデータをリクエスト

この方式は、バックエンド同士の通信（B2Bサービスやマイクロサービス間通信）でよく使用されます。

3-4-2. クライアントクレデンシャルズグラントのメリット

ユーザーの関与が不要（サーバー間の安全な通信が可能）
APIキーやベーシック認証よりも安全な認可が可能
マイクロサービスやB2Bシステムに適している

OAuth 2.0の実際の利用例

OAuth 2.0は、現在のインターネット上で広く使われている認可プロトコルです。

特に、ソーシャルログインやAPI連携において、その利便性とセキュリティの高さが評価されています。

この章では、OAuth 2.0の代表的な利用例として、ソーシャルログインの実装方法とAPI連携における認可の活用について詳しく解説します。

4-1. ソーシャルログインの実装方法

ソーシャルログインとは、GoogleやFacebook、Twitterなどのアカウントを使用して、他のWebサービスにログインする仕組みのことです。

OAuth 2.0を利用することで、ユーザーは新しいアカウントを作成せずに、すでに持っているアカウントで簡単に認証を行うことができます。

4-1-1. ソーシャルログインの仕組み

ソーシャルログインは、OAuth 2.0の認可コードフローを使用して実装されます。以下の流れで動作します。

ユーザーが「Googleでログイン」ボタンをクリック
認可サーバー（Google）がログインページを表示
ユーザーが認証し、アクセス許可を与える
認可サーバーがアプリに認可コードを発行
アプリが認可コードを使ってアクセストークンを取得
アプリがアクセストークンを使ってユーザー情報を取得し、ログイン処理を行う

この流れを図にすると、以下のようになります。

[ユーザー] → [アプリ] → [認可サーバー] ← 認可コード取得 ← → アクセストークン取得 → [アプリ] → [リソースサーバー]（ユーザー情報取得）

4-1-2. ソーシャルログインのメリット

ソーシャルログインを導入することで、以下のメリットがあります。

ユーザーの利便性向上：新規登録の手間が省け、すぐにログイン可能
セキュリティ向上：パスワード管理の負担が軽減されるため、アカウントの乗っ取りリスクが減少
ユーザー情報の活用：OAuth 2.0を通じて、ユーザーの基本情報（名前、メールアドレスなど）を取得できる

4-1-3. ソーシャルログインの実装手順

一般的なソーシャルログインの実装方法として、GoogleのOAuth 2.0 APIを使用する例を紹介します。

Google Cloud ConsoleでOAuthクライアントIDを取得
リダイレクトURI（認可コードを受け取るURL）を設定
認可コードリクエストを送信（Googleの認可サーバーにアクセス）
認可コードを受け取り、アクセストークンを取得
アクセストークンを使用してユーザー情報を取得

具体的なリクエストURLの例（GoogleのOAuth 2.0認可エンドポイント）：

https://accounts.google.com/o/oauth2/auth? client_id=YOUR_CLIENT_ID& redirect_uri=YOUR_REDIRECT_URI& response_type=code& scope=email%20profile

このように、OAuth 2.0を活用することで、安全かつスムーズなソーシャルログインを実装できます。

4-2. API連携における認可の活用

OAuth 2.0は、Webサービス間のデータ連携（API連携）にも広く利用されています。

APIを提供する企業（Google、Twitter、Dropboxなど）は、OAuth 2.0を利用して、安全にユーザーのデータを外部サービスと共有できます。

4-2-1. API連携の具体例

API連携の代表的な例として、以下のようなものがあります。

サービス	APIの用途	OAuth 2.0の役割
Google Drive	ユーザーのクラウドストレージにアクセス	ユーザーが許可した範囲でのみファイルを取得・編集
Twitter API	ユーザーのツイートを取得・投稿	ユーザーのアカウント情報を安全に提供
Spotify API	ユーザーのプレイリストを取得	音楽アプリがプレイリストを活用できる

4-2-2. API連携におけるOAuth 2.0の流れ

API連携では、アプリ（クライアント）がリソースサーバーにアクセスする際に、OAuth 2.0を活用します。以下の流れで認可が行われます。

ユーザーがアプリにAPI連携の許可を与える
アプリがOAuth 2.0の認可コードを取得
アプリが認可コードを使ってアクセストークンを取得
アプリがアクセストークンを使ってAPIリクエストを送信
APIが認可された範囲内でデータを返す

例えば、Google Drive APIを利用する場合、アクセストークンを取得した後、以下のようなリクエストを送信します。

GET https://www.googleapis.com/drive/v3/files Authorization: Bearer YOUR_ACCESS_TOKEN

このリクエストにより、ユーザーのGoogle Driveに保存されているファイル一覧を取得できます。

4-2-3. API連携のメリット

OAuth 2.0を使ったAPI連携には、以下のメリットがあります。

セキュリティの強化：パスワードを共有せずに安全な認可が可能
最小権限の原則（スコープの設定）：必要なデータのみアクセス許可を付与できる
シームレスなユーザー体験：一度認可すれば、再ログインなしでAPIにアクセス可能

OAuth 2.0のセキュリティ上の注意点

OAuth 2.0は、ユーザーの認可を安全に管理するためのプロトコルですが、適切に実装しないとセキュリティリスクが発生する可能性があります。

特に、アクセストークンの管理、スコープ設定、フィッシング攻撃対策などが重要なポイントです。

この章では、OAuth 2.0を安全に利用するためのセキュリティ対策について詳しく解説します。

5-1. アクセストークンの保護方法

OAuth 2.0では、アクセストークンが第三者に漏洩すると、悪意のある攻撃者がユーザーになりすましてリソースにアクセスする危険性があります。

そのため、アクセストークンの適切な管理が必要です。

5-1-1. アクセストークンを安全に管理する方法

アクセストークンのセキュリティを確保するために、以下の対策を実施することが推奨されます。

HTTPSを使用する
- トークンを送受信する際は、必ずHTTPSを利用し、盗聴を防ぐ。
アクセストークンの有効期限を短くする
- 長期間有効なトークンはリスクが高いため、短めに設定する。
リフレッシュトークンを活用する
- 短命なアクセストークンと併用し、セキュリティを強化する。
トークンの保存場所に注意する
- クライアントサイド（ブラウザやモバイルアプリ）では、セキュアストレージを利用する（例：Secure Storage、Keychain）。
トークンのスコープを最小限にする
- すべてのデータにアクセスできるトークンではなく、必要な範囲だけ許可する。

5-2. スコープ設定と最小特権の原則

OAuth 2.0では、スコープ（Scope）を設定することで、アプリがアクセスできるデータの範囲を制限できます。

スコープを適切に設定することで、万が一トークンが漏洩した場合のリスクを最小限に抑えることができます。

5-2-1. スコープとは？

スコープとは、OAuth 2.0においてクライアント（アプリ）がリソースサーバーから取得できるデータの範囲を定めるものです。

例えば、GoogleのOAuth 2.0 APIでは、次のようなスコープが定義されています。

スコープ	許可されるアクセス内容
`openid`	ユーザーの認証情報（ID）へのアクセス
`profile`	ユーザーの基本情報（名前、アイコンなど）
`email`	ユーザーのメールアドレス
`https://www.googleapis.com/auth/drive.readonly`	Google Driveの読み取り専用アクセス

アプリがリソースにアクセスする際は、必要最小限のスコープを指定することで、リスクを抑えることができます。

5-2-2. 最小特権の原則とは？

最小特権の原則（Principle of Least Privilege）とは、システムやアプリが「必要最低限の権限のみを付与する」というセキュリティの基本原則です。

OAuth 2.0においても、過剰なスコープを設定せず、アプリごとに必要な最小限のアクセス権のみを与えることが重要です。

適切なスコープ設定のポイント

不要なスコープを要求しない（最小限の権限だけをリクエスト）
リソースへの書き込み権限を慎重に設定（read-onlyをデフォルトにする）
ユーザーがスコープを確認できるUIを提供（許可する権限を明確に表示）

5-3. フィッシング攻撃への対策

OAuth 2.0を悪用したフィッシング攻撃が増えています。

攻撃者は、正規のOAuth 2.0ログイン画面に見せかけた偽のページを作成し、ユーザーの認証情報を盗み取る手口を使います。

5-3-1. フィッシング攻撃の手口

偽の認可ページを用意
- 「Googleでログイン」ボタンを押すと、攻撃者が用意した偽の認可ページが表示される。
ユーザーが認証情報を入力
- ユーザーがログイン情報を入力すると、攻撃者が情報を取得。
攻撃者がアクセストークンを不正に取得
- ユーザーになりすましてサービスを利用できるようになる。

5-3-2. フィッシング攻撃を防ぐ対策

認可サーバーのURLを確認する
- https://accounts.google.com/o/oauth2/auth など、正規の認可サーバーのドメインを使用しているか確認する。
PKCE（Proof Key for Code Exchange）を利用する
- クライアント側でコードをハッシュ化し、認可コードの不正取得を防ぐ。
OAuth 2.0のログインページをアプリ内で直接表示しない
- 認可フローはWebViewではなく、システムブラウザを使用する（例：Chrome Custom Tabs、Safari View Controller）。
ユーザーに警告を表示
- 「信頼できるアプリか確認してください」といった警告メッセージを表示する。

OAuth 2.0の最新動向と今後の展望

OAuth 2.0は、現在も進化を続けており、新たなセキュリティ対策や利便性向上のための改良が加えられています。

特に、OAuth 2.1の提案が進められており、OAuth 2.0の弱点を補完する形で改善が行われています。

この章では、OAuth 2.1の提案と主な変更点について詳しく解説します。

6-1. OAuth 2.1の提案と変更点

OAuth 2.1は、OAuth 2.0の仕様を簡潔にまとめ、より安全で使いやすい認可フローを提供するために提案されました。

OAuth 2.0が登場してから10年以上が経過し、その間に発見された問題点を解決するために、いくつかの重要な変更が加えられています。

6-1-1. OAuth 2.1の主な変更点

OAuth 2.1では、以下のような変更が行われています。

変更点	説明
インプリシットグラントの廃止	アクセストークンがURLに露出するリスクが高いため、インプリシットフローは非推奨に。
リソースオーナーパスワードクレデンシャルズグラントの廃止	パスワードを直接アプリに入力させる方式はセキュリティ上のリスクが大きいため廃止。
PKCE（Proof Key for Code Exchange）の必須化	認可コードグラントでPKCEを必須化し、コードインジェクション攻撃を防ぐ。
リフレッシュトークンのセキュリティ強化	トークン漏洩リスクを減らすため、リフレッシュトークンの管理方法が改善。
スコープの簡素化	既存のスコープ管理を見直し、より直感的な方式へ統一。

6-1-2. OAuth 2.1によるメリット

OAuth 2.1の変更により、以下のようなメリットが期待されています。

セキュリティの向上
- インプリシットグラントの廃止やPKCEの必須化により、攻撃リスクが低減。
実装の簡素化
- 古い方式が削除され、OAuth 2.0の標準的な実装がシンプルになる。
ユーザー体験の向上
- トークンの安全な管理が強化され、よりスムーズな認証・認可が可能になる。