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

OAuth（オーオース）とは、ユーザーがパスワードを渡さずに、第三者のアプリへ自分のデータを扱う権限だけを委ねるための仕様です。現在使われているOAuth 2.0は、IETFが2012年10月にRFC 6749として発行しました。本記事では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の違いと選定で整理しています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

中心となる認可コードフローで、実際に送られる内容を示します。以下はRFC 6749とRFC 7636（PKCE）の例示値をもとに、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でその対策を兼ねてよいとしています。実装手順と検証項目は認可コードフローとは？認可リクエストからトークン交換までの実装手順と検証設計、PKCE単体の仕組みはPKCEとは？で解説しています。

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

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

インプリシットフローはアクセストークンをリダイレクト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」としました。パスキーの仕組みと導入の判断はパスキー認証とは？仕組み・パスワードとの違い・企業の導入判断で扱っています。既存システムで使っている場合は、認可コードフローへの移行計画を立てる対象です。

デバイス認可グラント（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）として2025年1月にまとまりました。RFC 9700はRFC 6749・6750・6819を更新する文書で、先に挙げたインプリシットとROPCの扱いもここで決まっています。

OAuth 2.1（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は現在もインプリシット用の 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との使い分け）。SSO（シングルサインオン）は仕様名ではなく、1回のログインで複数サービスを使える状態を指す言葉で、OpenID ConnectやSAMLはそれを実現する手段です。

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

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との違いで扱っています。

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

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

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

入門で押さえるのは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連携にまとめています。

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

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

自社サービスに「Googleでログイン」などのログイン機能を付けたいなら、使う仕様はOAuth 2.0ではなくOpenID Connectです。会員情報の登録・退会・権限管理と一体で設計しないと、外部IDと自社の会員IDの紐付けで破綻します。一創の会員管理システム開発では、ログイン・会員管理・外部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を呼ぶなど、ユーザーの操作を伴わないサーバー間通信で使います。シークレットを安全に保管できる機密クライアントに限られ、ブラウザやスマートフォンのアプリでは使えません。

関連記事

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