---
title: "OAuthとは？OAuth 2.0の仕組み・認可フローと認証との違い、OAuth 2.1の変更点をわかりやすく解説"
url: "https://www.issoh.co.jp/tech/details/8369/"
published: 2025-08-22
updated: 2026-10-25
categories: ["アーキテクチャ"]
publisher: "株式会社一創"
---

# OAuthとは？OAuth 2.0の仕組み・認可フローと認証との違い、OAuth 2.1の変更点をわかりやすく解説

OAuth（オーオース）とは、ユーザーがパスワードを渡さずに、第三者のアプリへ自分のデータを扱う権限だけを委ねるための仕様です。現在使われているOAuth 2.0は、IETFが2012年10月に[RFC 6749](https://www.rfc-editor.org/rfc/rfc6749.html)として発行しました。本記事では4つのロールと認可コードフローの実際のHTTPのやり取りを追い、2025年1月のRFC 9700で使用を禁止・非推奨にされたフローと、策定中のOAuth 2.1で変わる点、自社サービスに組み込むときの判断までを一次仕様にもとづいて整理します。

## まとめ：OAuth 2.0の要点と2026年時点で新規実装に選ぶ認可フロー

- OAuth 2.0は**認可**（何をしてよいか）の仕様で、ログイン（認証）の仕様ではありません。ログインに使うならOpenID Connectを重ねます。
- 登場するのはリソースオーナー・クライアント・認可サーバー・リソースサーバーの4ロールです。クライアントはパスワードの代わりにアクセストークンを受け取り、APIを呼びます。
- 新規実装で選ぶのは、ユーザーが関わるなら**認可コードフロー＋PKCE**、サーバー間なら**クライアントクレデンシャル**、入力手段が乏しい機器なら**デバイス認可グラント**です。
- インプリシットフローはRFC 9700で「SHOULD NOT」（使うべきでない）、リソースオーナー・パスワードフローは「MUST NOT」（使ってはならない）とされました。
- OAuth 2.1は2026年9月3日公開のdraft-16が最新で、2026年10月時点でもまだRFCではありません。変更点の多くはRFC 9700などで既に推奨されている内容です。
- 認可サーバーを自前で書く案は採りません。クライアント側は実績のあるライブラリ、認可サーバー側はOSSかIDaaSに任せ、自社はスコープ設計と失効の運用に工数を割きます。

## OAuthとは何か：RFC 6749の定義と「認可」を委ねる仕組みの意味

RFC 6749は冒頭で、OAuth 2.0を「サードパーティーのアプリケーションがHTTPサービスへの限定的なアクセスを得られるようにする認可フレームワーク」と定義しています。キーワードは「限定的」です。たとえば写真印刷サービスにクラウドストレージの写真を読ませる場合、ユーザーはストレージのパスワードを印刷サービスに教えません。ストレージ事業者の画面で「写真の閲覧」だけを許可し、印刷サービスはその範囲に限った鍵（アクセストークン）を受け取ります。

パスワードを預ける連携では、預け先がメール送信もアカウント削除もでき、1つだけ止めるにはパスワードを変えるしかありません。OAuthはこの全権委任を、範囲と期限を切った委任に置き換えます。

### OAuthの読み方とOAuth 1.0との関係、後方互換性が無い理由

OAuthは日本では「オーオース」と読まれるのが一般的です。前身のOAuth 1.0は2010年4月にRFC 5849として発行され、RFC 6749がこれを廃止（Obsoletes）しました。RFC 6749自身が1.0とは後方互換性が無いと明記しているため、1.0のクライアントは2.0の認可サーバーとそのままではつながりません。1.0はHMAC-SHA1などでリクエストごとに署名する設計でしたが、2.0は署名をやめてTLSでの保護を前提にし、トークンの取得手順をグラントタイプとして分けました。

### 認証と認可の違い：アクセストークンがログインの証明にならない理由

認証（Authentication）は「あなたは誰か」を確かめる処理、認可（Authorization）は「あなたに何を許すか」を決める処理です。社員証で入館を確認するのが認証、その社員証で入れるフロアを決めるのが認可にあたります。MFA・SSO・IDaaSを含めた認証まわりの全体像は[認証・ID管理とは？MFA・SSO・OIDC・IDaaSの違いと選定](https://www.issoh.co.jp/column/details/13631/)で整理しています。

OAuth 2.0のアクセストークンは「この範囲のAPIを呼んでよい」という許可を表すだけで、「誰がログインしたか」をクライアントに証明するものではありません。トークンの形式も規定しておらず、中身を読めない文字列でもかまいません。そのため、ログイン機能に使うのは、OAuth 2.0の上に本人確認の層を足したOpenID Connectです。[OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1%5F0.html)は自身を「OAuth 2.0プロトコルの上に載せたシンプルなアイデンティティ層」と説明しており、ログインしたユーザーの情報はIDトークン（JWT）として受け取ります。違いの詳細は[OIDC（OpenID Connect）とは？仕組み・OAuthとの違い](/tech/details/6532/)で扱っています。

## OAuthとは何かを連携の同意画面で確かめる：許可範囲と取り消しの実際

仕様の言葉だけでは掴みにくいので、利用者として毎日のように目にしている画面に置き換えます。日程調整サービスで「Googleカレンダーと連携」を押すと、ブラウザはいったんGoogleの画面へ移り、「このアプリがGoogleアカウントへのアクセスを求めています」という確認と、カレンダーの閲覧などの許可項目が並びます。この画面がOAuthの認可リクエストの到着点です。

並んでいる許可項目は、アプリが要求したスコープを認可サーバーが人の言葉に直したものです。ユーザーが許可を押すと、ブラウザは日程調整サービスの画面へ戻されます。このとき裏で1回限りの認可コードが渡され、サービスはそれをアクセストークンに交換します。ユーザーがパスワードを入力したのはGoogleの画面だけで、日程調整サービスはパスワードを一度も見ていません。

許可は後からでも取り消しが可能です。多くの提供元はアカウント設定に連携中のアプリの一覧を置いており、そこで外すとトークンが無効になります。アプリ側から不要になったトークンを返上する手順は、RFC 7009（トークンの失効）で定められています。

### OAuthを使うメリットと、OAuthだけでは解決しない3つの範囲

パスワードを預ける旧来の連携と比べると、違いは次の表のとおりです。

| 観点        | パスワードを預ける連携     | OAuth 2.0   |
| --------- | --------------- | ----------- |
| 連携先が知る情報  | IDとパスワード        | アクセストークンのみ  |
| 許す範囲      | アカウントの全操作       | スコープで指定した操作 |
| 有効期間      | パスワード変更まで       | トークンの期限まで   |
| 1社だけ止める方法 | パスワード変更（全社が止まる） | その連携だけ取り消す  |

一方で、OAuthが引き受けない範囲もはっきりしています。1つ目は本人確認で、これはOpenID Connectの役割です。2つ目はトークンの保管で、クライアントが盗まれたトークンを使われた場合、Bearerトークンは持っている人なら誰でも使えます。3つ目はスコープの粒度で、提供元が「読み取り専用」のスコープを用意していなければ、クライアントは必要以上の権限を求めるしかありません。この3点は仕様ではなく、実装と運用の側で埋めます。

## OAuth 2.0の4つのロールとアクセストークン・スコープが担う役割

RFC 6749の1.1節は4つのロールを定義しています。GoogleカレンダーのAPIを使う日程調整サービスを例に当てはめると次のようになります。

| ロール      | RFC 6749での役割   | 日程調整サービスの例          |
| -------- | -------------- | ------------------- |
| リソースオーナー | アクセスを許可できる主体   | カレンダーの持ち主（利用者）      |
| クライアント   | 許可を得てAPIを呼ぶアプリ | 日程調整サービス            |
| 認可サーバー   | 本人を確かめトークンを発行  | accounts.google.com |
| リソースサーバー | トークンを受けてデータを返す | Google Calendar API |

認可サーバーとリソースサーバーは同じ事業者のことが多いものの、RFC 6749は両者の間のやり取りを仕様の範囲外としています。リソースサーバーは、JWT形式のトークンを自分で検証するか、RFC 7662のイントロスペクションで認可サーバーに問い合わせてトークンの有効性を確かめます。

### アクセストークン・リフレッシュトークン・スコープの違いと有効期限の決め方

アクセストークンはAPIを呼ぶときに `Authorization: Bearer <トークン>` ヘッダーで送る鍵です（送り方はRFC 6750。詳しくは[Bearer Token（ベアラートークン）とは？](/tech/details/4150/)）。有効期限を示す `expires_in` はRFC 6749では「RECOMMENDED」（推奨）の扱いで、仕様の例は3600秒です。

リフレッシュトークンは、期限切れのアクセストークンを取り直すための別の鍵です。発行は「OPTIONAL」で、認可サーバーが出さない設計も仕様に沿っています。RFC 9700は公開クライアント（ブラウザやスマートフォンのアプリなどクライアントシークレットを安全に保管できないクライアント）に出すリフレッシュトークンについて、送信者制約をかけるか、使うたびに作り替えるローテーションのどちらかを必須にしました。使わなくなったトークンの保管表と削除ジョブの実装例は[ワラウ不正アクセスで連携トークン流出｜Yahoo! JAPAN ID再連携と対象確認](https://www.issoh.co.jp/tech/details/18391/)で扱っています。設計の判断は[リフレッシュトークンとは？更新フローと寿命・ローテーション設計](/tech/details/16409/)にまとめています。

スコープは許可の範囲を表す文字列です。値の名前は仕様では決まっておらず、Googleなら `https://www.googleapis.com/auth/calendar.readonly` のように提供側が定義します。RFC 9700はアクセストークンの権限を用途に必要な最小限に絞るよう求めており（SHOULD）、読み取りだけで足りる連携で書き込みスコープを要求しないのが基本です。

## 認可コードフロー＋PKCEの流れを実際のHTTPリクエストで追う手順

中心となる認可コードフローで、実際に送られる内容を示します。以下はRFC 6749と[RFC 7636（PKCE）](https://www.rfc-editor.org/rfc/rfc7636.html)の例示値をもとに、scope・state・token\_type をわかりやすい値に置き換えたものです。

1. クライアントがランダムな `code_verifier` を作り、そのSHA-256ハッシュをBase64URL化した値を `code_challenge` として控える。
2. ブラウザを認可サーバーの画面へ移動させる（認可リクエスト）。
3. ユーザーが認可サーバーでログインし、要求されたスコープを許可する。
4. 認可サーバーがブラウザを `redirect_uri` へ戻し、URLに1回限りの認可コードを付ける。
5. クライアントがリダイレクトを介さず認可サーバーへ直接、認可コードと `code_verifier` を送り、アクセストークンを受け取る（トークンリクエスト）。
6. アクセストークンを付けてAPIを呼ぶ。

手順2でブラウザが送る認可リクエストは次の形です（改行は表示用）。

```
GET /authorize?response_type=code
    &client_id=s6BhdRkqt3
    &redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb
    &scope=calendar.readonly
    &state=af0ifjsldkj
    &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
    &code_challenge_method=S256 HTTP/1.1
Host: server.example.com
```

手順5のトークンリクエストはリダイレクトを経由せず、クライアントから認可サーバーのトークンエンドポイントへ直接送ります（SPAやスマートフォンのアプリならアプリ自身が送ります）。認可コードだけを盗まれても、元の `code_verifier` を知らなければトークンに交換できないのがPKCEの効き目です。

```
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb
&client_id=s6BhdRkqt3
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
```

成功すると認可サーバーはJSONを返します。RFC 6749はこの応答に `Cache-Control: no-store` を付けるよう定めています。

```
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store

{
  "access_token": "2YotnFZFEjr1zCsicMWpAA",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA"
}
```

PKCEの値は手元で再計算できます。RFC 7636の付録Bにある `code_verifier` をPythonでハッシュすると、上の `code_challenge` と同じ文字列になります。

```
import base64, hashlib

verifier = "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
digest = hashlib.sha256(verifier.encode("ascii")).digest()
print(base64.urlsafe_b64encode(digest).rstrip(b"=").decode())
# E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
```

`state` はRFC 6749では「RECOMMENDED」ですが、RFC 9700はクライアントにCSRF対策を必須（MUST）とし、認可サーバーのPKCE対応をクライアントが確かめた場合に限り、PKCEでその対策を兼ねてよいとしています。実装手順と検証項目は[認可コードフローとは？認可リクエストからトークン交換までの実装手順と検証設計](/tech/details/16415/)、PKCE単体の仕組みは[PKCEとは？](/tech/details/16405/)で解説しています。

## グラントタイプ一覧と2026年時点でのRFC 9700・OAuth 2.1の扱い

トークンを得る手順を「グラントタイプ」（認可グラント）と呼びます。RFC 6749は4種類を定義し（リフレッシュトークンは6章で定める再取得用のグラント）、のちのRFCで追加されたものもあります。現在の扱いはRFC 9700とOAuth 2.1 draft-16で大きく変わりました。

| グラントタイプ        | 定義       | RFC 9700の扱い     | OAuth 2.1 |
| -------------- | -------- | --------------- | --------- |
| 認可コード          | RFC 6749 | 公開クライアントはPKCE必須 | PKCE込みで存続 |
| インプリシット        | RFC 6749 | SHOULD NOT      | 削除        |
| リソースオーナー・パスワード | RFC 6749 | MUST NOT        | 削除        |
| クライアントクレデンシャル  | RFC 6749 | 禁止なし（sub混同に注意）  | 存続        |
| リフレッシュトークン     | RFC 6749 | 公開クライアントは制約必須   | 存続        |
| デバイス認可         | RFC 8628 | 個別の規定なし         | 拡張として利用可  |

インプリシットフローはアクセストークンをリダイレクトURLに載せて返すため漏れやすく、盗まれたトークンを特定のクライアントに縛る標準手段もありません。かつてSPA向けとされていましたが、現在はSPAでも認可コードフロー＋PKCEを使います。

### クライアントクレデンシャルグラントの用途と機密クライアント限定の理由

ユーザーが介在しない、サーバー同士のAPI呼び出しに使うフローです。クライアントは自分のIDとシークレットを認可サーバーに示し、自分自身の権限でトークンを受け取ります。RFC 6749は「機密クライアント（シークレットを安全に保管できるサーバー側アプリ）だけが使わなければならない」（MUST）と定めており、スマートフォンアプリやSPAにシークレットを埋め込んで使うのは仕様違反です。RFC 9700の4.15節は、このグラントで得たトークンの主体（`sub`）がクライアントのIDになる場合に、実在ユーザーと取り違えられる危険を挙げており、クライアントが自分の `client_id` を自由に選べないよう認可サーバー側で制限することを求めています（SHOULD NOT allow）。

```
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&scope=reports.read
```

### リソースオーナー・パスワードクレデンシャル（ROPC）がMUST NOTになった理由

ユーザーのIDとパスワードをクライアントが直接受け取り、それを認可サーバーに送ってトークンと交換するフローです。旧システムをOAuthへ移行する際の橋渡しとして用意されましたが、パスワードを預けない、というOAuthの前提そのものを崩します。RFC 9700は、クライアントが善意でも資格情報が漏れる場所を増やすこと、多要素認証や複数段階の対話を伴う認証を想定しておらずWebAuthn（パスキー）は実装できない場合があることを理由に「MUST NOT」としました。パスキーの仕組みと導入の判断は[パスキー認証とは？仕組み・パスワードとの違い・企業の導入判断](https://www.issoh.co.jp/column/details/15368/)で扱っています。既存システムで使っている場合は、認可コードフローへの移行計画を立てる対象です。

### デバイス認可グラント（RFC 8628）の流れとテレビ・CLIでの使いどころ

テレビやCLIツールなど、ブラウザでのログインが難しい機器向けに2019年8月のRFC 8628で追加されました。機器は短いユーザーコードを表示し、ユーザーはスマートフォンなど別の端末でURLを開いてコードを入力し、許可します。機器はその間トークンエンドポイントを定期的に問い合わせ、許可されるとトークンを受け取ります。トークンリクエストの `grant_type` は `urn:ietf:params:oauth:grant-type:device_code` です。

## OAuth 2.1 draft-16で変わる8項目とRFC 9700で先行した対策

RFC 6749の発行から約12年の間に見つかった攻撃と対策は、[RFC 9700（OAuth 2.0 Security Best Current Practice、BCP 240）](https://www.rfc-editor.org/rfc/rfc9700.html)として2025年1月にまとまりました。RFC 9700はRFC 6749・6750・6819を更新する文書で、先に挙げたインプリシットとROPCの扱いもここで決まっています。

[OAuth 2.1（draft-ietf-oauth-v2-1）](https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/)は、RFC 6749・RFC 6750・PKCE（RFC 7636）・ネイティブアプリ向けのRFC 8252・RFC 9700などを1本に統合し、RFC 6749とRFC 6750を置き換える予定の文書です。2026年9月3日にdraft-16が公開されましたが、2026年10月25日に確認した時点でも状態はワーキンググループの文書（Internet-Draft）のままで、RFCにはなっていません。draft-16の「Differences from OAuth 2.0」節が挙げる変更は次のとおりです。

- 認可コードフローは既定でPKCEのパラメータを必須にする
- リダイレクトURIは完全一致の文字列比較で照合する
- インプリシット（`response_type=token`）とROPCを仕様から除く
- Bearerトークンをクエリ文字列で送る方法を除く
- 公開クライアントのリフレッシュトークンは送信者制約か1回限りの使用にする
- トークンリクエストから `redirect_uri` パラメータを除く
- 認可サーバーはリクエストボディでのクライアント認証（client\_secret\_post）に対応しなければならない
- PKCEの `plain` 方式を禁止する

多くはRFC 9700で既に推奨されている内容です。ただし、トークンリクエストからの `redirect_uri` の削除と、リクエストボディでのクライアント認証の必須化は2.1独自の変更です。RFC 6749の認可サーバーは、認可リクエストに `redirect_uri` を含めた場合はトークンリクエストでも同じ値を要求するため（4.1.3節でREQUIRED）、現時点では送り続けます。それ以外の項目は、いまから2.1の形で実装できます。

### 認可サーバーの対応状況をメタデータで確かめるコマンドと実測結果

自社が使う認可サーバーがどこまで対応しているかは、RFC 8414またはOpenID Connectのメタデータ（`.well-known`）で確認できます。2026年9月26日に次のコマンドで取得した結果を示します。表のMicrosoft Entra IDはcommon・v2.0の結果です。

```
curl -s https://accounts.google.com/.well-known/openid-configuration \
  | jq '{code_challenge_methods_supported, response_types_supported, device_authorization_endpoint, authorization_response_iss_parameter_supported}'
```

| 項目                   | Google      | Microsoft Entra ID |
| -------------------- | ----------- | ------------------ |
| PKCEの方式              | plain, S256 | 項目なし               |
| response\_typeのtoken | あり          | id\_token tokenのみ  |
| デバイス認可エンドポイント        | あり          | あり                 |
| issパラメータ（RFC 9207）   | true        | 項目なし               |

Googleは現在もインプリシット用の `token` と、OAuth 2.1で禁止される `plain` を受け付けています。認可サーバーが受け付けることと、クライアントが使ってよいことは別です。クライアント側で `response_type=code` と `code_challenge_method=S256` に固定しておけば、サーバーが旧方式を残していても影響を受けません。Microsoftのcommonエンドポイントは `code_challenge_methods_supported` をメタデータに載せていませんが、RFC 9700は対応の示し方としてメタデータ以外の手段も認めているため、項目が無いことは非対応を意味しません。確認に使うのは、ドキュメントと実際の応答です。デバイス認可も同様で、Microsoftは `grant_types_supported` を載せていませんが `device_authorization_endpoint` を公開しています。認可応答の `iss` は2社のうちGoogleだけが宣言しており、複数の認可サーバーを扱うクライアントは次の章のmix-up攻撃への備えをこの差に合わせて選びます。

## OAuthとOpenID Connect・SAML・SSOの違いと組み合わせ方の基本

混同されやすい4つは、役割の層が違います。OAuth 2.0は「APIを呼ぶ権限の委任」、OpenID ConnectはOAuth 2.0の上で「誰がログインしたか」を伝える認証の仕様です。SAMLはXMLで認証結果を受け渡す、企業向けシングルサインオンで長く使われてきた別系統の仕様です（[SAMLとは？認証フロー・IdP/SPの仕組みとOAuth・OIDCとの使い分け](/tech/details/13299/)）。SSO（シングルサインオン）は仕様名ではなく、1回のログインで複数サービスを使える状態を指す言葉で、OpenID ConnectやSAMLはそれを実現する手段です。

社内の複数SaaSへ1回でログインしたいならOpenID ConnectかSAMLでSSOを組み、外部アプリにAPIを使わせる部分にOAuth 2.0を使う、という組み合わせになります。SSOの実現方式とIDトークンの検証手順は[シングルサインオン（SSO）とは？4つの実現方式とIDトークン検証](https://www.issoh.co.jp/tech/details/15821/)で解説しています。

## OAuth認証は危険か：実装で起きる4つの失敗とRFC 9700の対策

OAuth 2.0そのものはパスワードを預けるよりも安全な仕組みですが、脆弱性の多くは仕様の選択肢を誤った実装で起きています。RFC 9700が名指ししている失敗のうち、影響が大きいものを挙げます。

- **リダイレクトURIの照合が甘い**：前方一致やワイルドカードで照合すると、攻撃者のURLへ認可コードが送られます。登録済みURIとの完全一致で照合します（ネイティブアプリのlocalhostリダイレクトのポート番号だけは例外）。
- **オープンリダイレクター**：クエリで受け取った任意のURLへ転送するエンドポイントがクライアントや認可サーバーにあると、コードやトークンが外部へ流れます。RFC 9700はこれを置くこと自体を禁止しています（MUST NOT）。
- **複数の認可サーバーを扱う際の取り違え**：認可応答の `iss` パラメータ（RFC 9207）で発行元を確かめないと、別の認可サーバーに宛てたコードを悪用されるmix-up攻撃が成り立ちます。
- **トークンを送信者に縛っていない**：Bearerトークンは持っている人なら誰でも使えます。RFC 9700はDPoP（RFC 9449）や相互TLS（RFC 8705）での送信者制約を推奨しています（SHOULD）。

もう1つ、仕様の読み違いから起きる典型が「アクセストークンを受け取れたからログイン成功とみなす」実装です。アクセストークンは誰に向けて発行されたものかをクライアントに示さないため、別のアプリ向けに発行されたトークンを差し込まれると、そのトークンの持ち主としてログインを通してしまいます。ログインを作るなら、OAuth 2.0を自前で流用せず、IDトークンの発行先（`aud`）と署名を検証できるOpenID Connectを採用すべきです。JWTの検証項目は[JWTとは？構造・署名検証の仕組みとセッション・OAuth/OIDCとの違い](/tech/details/13453/)で扱っています。

APIキーやセッションとの使い分けは[API認証の設計｜方式選定マトリクスとトークン寿命・監査ログの決め方](/tech/details/17232/)を参照してください。

## OAuth 2.0を構成する主なRFC15本と発行年月、入門で先に読む4本

実際のOAuth 2.0実装は複数のRFCの組み合わせです。主なものを発行順に並べます（発行年月はRFC Editorの登録情報）。

| RFC      | 内容                | 発行       |
| -------- | ----------------- | -------- |
| RFC 6749 | OAuth 2.0本体       | 2012年10月 |
| RFC 6750 | Bearerトークンの送り方    | 2012年10月 |
| RFC 7009 | トークンの失効           | 2013年8月  |
| RFC 7591 | 動的クライアント登録        | 2015年7月  |
| RFC 7636 | PKCE              | 2015年9月  |
| RFC 7662 | トークンイントロスペクション    | 2015年10月 |
| RFC 8252 | ネイティブアプリ向けBCP     | 2017年10月 |
| RFC 8414 | 認可サーバーメタデータ       | 2018年6月  |
| RFC 8628 | デバイス認可グラント        | 2019年8月  |
| RFC 8707 | リソースインジケーター       | 2020年2月  |
| RFC 9126 | PAR（認可リクエストの事前送信） | 2021年9月  |
| RFC 9068 | JWT形式のアクセストークン    | 2021年10月 |
| RFC 9207 | 認可応答のissパラメータ     | 2022年3月  |
| RFC 9449 | DPoP              | 2023年9月  |
| RFC 9700 | セキュリティBCP         | 2025年1月  |

入門で押さえるのはRFC 6749・6750・7636・9700の4本で、残りは必要になった場面で読めば足ります。

## 自社サービスでOAuthを組む判断：自前実装・ライブラリ・IDaaSの線引き

「OAuthに対応したい」という要望は、立場によって作るものがまったく違います。最初に、自社が4ロールのどこを担うのかを決めます。

### 外部APIを呼ぶクライアント側だけを作る場合のライブラリ選定と実装方針

GoogleやMicrosoftのAPIを自社アプリから呼ぶだけなら、自社が作るのはクライアントです。提供元のSDKか、保守が続いているOAuthクライアントライブラリで認可コードフロー＋PKCEを組みます。HTTPの往復を手書きするのは、仕組みを学ぶ検証環境までにとどめます。本番で手書きすると、`state` の照合漏れやリダイレクトURIの比較誤りといった、前章の失敗をそのまま作り込むからです。

### 自社APIを外部に開放し認可サーバーを持つ場合の運用体制と採用条件

自社APIを取引先や外部アプリに使わせる場合は、認可サーバーが要ります。ここで認可サーバーをゼロから書く案は採用しません。トークン発行・失効・鍵の更新・同意画面・監査ログのどれか1つでも誤ると、全利用者のデータが危険にさらされるためです。選択肢は、KeycloakなどのOSSを自社運用するか、Microsoft Entra IDやOktaなどのIDaaSを契約するかの二択です。運用担当を置けず、監査ログの保管も外部に任せたいならIDaaS、データの所在や費用の上限を自社で握りたいならOSSを選びます。IDaaSの比較軸は[IDaaSとは？SSO・IdPとの違いとSAML・OIDC・SCIM連携](https://www.issoh.co.jp/tech/details/16401/)にまとめています。

反対に、社内のバッチ2〜3本が社内APIを呼ぶだけの段階で認可サーバーを導入するのは過剰です。利用者が社内に閉じ、委任する相手もいないなら、APIキーと通信経路の制限で足ります。

### 自社アプリのログインを作る場合の仕様選定と、導入前に決めておく5項目

自社サービスに「Googleでログイン」などのログイン機能を付けたいなら、使う仕様はOAuth 2.0ではなくOpenID Connectです。会員情報の登録・退会・権限管理と一体で設計しないと、外部IDと自社の会員IDの紐付けで破綻します。一創の[会員管理システム開発](https://www.issoh.co.jp/service/system/usersystem/)では、ログイン・会員管理・外部IDとの連携をまとめて設計から請け負っています。

どの立場でも、実装に入る前に次の5項目を決めておくと手戻りが減ります。

1. 要求するスコープの一覧と、読み取り専用で足りる操作の切り分け
2. アクセストークンの有効期限と、リフレッシュトークンを出すかどうか
3. リフレッシュトークンのローテーションか送信者制約のどちらを採るか
4. 利用者が連携を取り消したとき、自社側で削除するデータと期限
5. 登録するリダイレクトURIの完全な一覧（開発・検証・本番ごと）

## よくある質問

OAuthについて、検索されることの多い質問に答えます。

### OAuthとは簡単に言うと何ですか？読み方も教えてください

パスワードを教えずに、外部のアプリへ「この範囲の操作だけしてよい」という許可を渡す仕組みです。許可はアクセストークンという鍵で渡され、範囲と期限が決まっており、後から取り消せます。日本では「オーオース」と読むのが一般的で、バージョンを付けて「オーオース ツー」などと呼ばれます。

### OAuth認証は危険ですか？

パスワードを第三者のアプリに渡さずに済むぶん、パスワードを預ける連携より安全です。危険なのは、リダイレクトURIの照合が甘い、インプリシットやROPCを使っている、アクセストークンの受領をログイン成功とみなしている、といった実装側の誤りです。

### OAuth 2.0とOAuth 2.1のどちらで実装すべきですか？

OAuth 2.1は2026年10月時点でまだRFCではありません。ただし変更点の多くはRFC 9700などで既に推奨されている内容なので、OAuth 2.0のライブラリを使いつつ、認可コードフロー＋PKCE（S256）・リダイレクトURIの完全一致・インプリシットとROPCの不使用を守れば、2.1の要件の大半を満たせます。トークンリクエストの `redirect_uri` は、2.0の認可サーバーが要求するため当面は送り続けます。

### アクセストークンの有効期限は何秒ですか？

仕様に決まった値はありません。RFC 6749は `expires_in` で秒数を返すことを推奨しており、例として3600秒（1時間）を挙げています。実際の長さは認可サーバーの設定次第です。

### クライアントクレデンシャルフローはどんなときに使いますか？

夜間バッチが社内の別システムのAPIを呼ぶなど、ユーザーの操作を伴わないサーバー間通信で使います。シークレットを安全に保管できる機密クライアントに限られ、ブラウザやスマートフォンのアプリでは使えません。

## 関連記事

- [認可コードフローとは？認可リクエストからトークン交換までの実装手順と検証設計を解説](/tech/details/16415/)
- [PKCEとは？認可コード横取り攻撃を防ぐcode\_verifierの実装と検証設計を解説](/tech/details/16405/)
- [OIDC（OpenID Connect）とは？仕組み・OAuthとの違いをわかりやすく解説](/tech/details/6532/)
- [リフレッシュトークンとは？更新フローと寿命・ローテーション設計を実装者向けに解説](/tech/details/16409/)
- [JWTとは？構造・署名検証の仕組みとセッション・OAuth/OIDCとの違いを実装視点で解説](/tech/details/13453/)

---

出典: [OAuthとは？OAuth 2.0の仕組み・認可フローと認証との違い、OAuth 2.1の変更点をわかりやすく解説](<https://www.issoh.co.jp/tech/details/8369/>)（株式会社一創）