項目	内容
Workgroup	Web Authorization Protocol
Internet-Draft	draft-ietf-oauth-first-party-apps-02
Published	2025年10月20日
Intended Status	Standards Track
Expires	2026年4月23日
Authors	A. Parecki | Okta
Authors	G. Fletcher | Capital One Financial
Authors	P. Kasselman | Defakto Security

OAuth 2.0 for First-Party Applications

Abstract

この文書は、Authorization Challenge Endpoint を定義します。これは、ネイティブな体験を用いてユーザーからの認可を取得するプロセスを制御したいファーストパーティ・クライアントをサポートします。

多くの場合、これはネイティブアプリケーションに適した、完全にブラウザなしの OAuth 2.0 体験を提供でき、予期しない状況、高リスク、またはエラー条件においてのみブラウザへ委譲します。

About This Document

この注記は、RFC として公開する前に削除される予定です。

このドラフトの最新改訂版は、https://drafts.oauth.net/oauth-first-party-apps/draft-ietf-oauth-first-party-apps.html で参照できます。この文書のステータス情報は、https://datatracker.ietf.org/doc/draft-ietf-oauth-first-party-apps/ で参照できます。

この文書に関する議論は、Web Authorization Protocol Working Group のメーリングリスト（mailto:oauth@ietf.org）で行われます。これは https://mailarchive.ietf.org/arch/browse/oauth/ にアーカイブされています。購読は https://www.ietf.org/mailman/listinfo/oauth/ から行えます。

このドラフトのソースおよび Issue Tracker は、https://github.com/oauth-wg/oauth-first-party-apps で参照できます。

Status of This Memo

この Internet-Draft は、BCP 78 および BCP 79 の規定に完全に準拠して提出されています。

Internet-Drafts は、Internet Engineering Task Force（IETF）の作業文書です。他のグループも作業文書を Internet-Drafts として配布する場合があることに注意してください。現在の Internet-Drafts の一覧は、https://datatracker.ietf.org/drafts/current/ にあります。

Internet-Drafts は、最大 6 か月間有効なドラフト文書であり、いつでも更新、置換、または他の文書によって廃止される可能性があります。Internet-Drafts を参照資料として使用したり、「作業中（work in progress）」として以外に引用したりすることは不適切です。

この Internet-Draft は 2026年4月23日に期限切れとなります。

Copyright Notice

Copyright (c) 2025 IETF Trust および文書の著者として特定された個人。All rights reserved.

この文書は、この文書の公開日に有効な、BCP 78 および IETF Trust の「IETF 文書に関する法的規定」（https://trustee.ietf.org/license-info）の適用を受けます。これらの文書には、この文書に関するあなたの権利および制限が記載されているため、注意深く確認してください。この文書から抽出されたコード構成要素は、Trust Legal Provisions の Section 4.e で説明されている Revised BSD License の文言を含めなければならず、また Revised

Table of Contents

• OAuth 2.0 for First-Party Applications
  • Abstract
  • About This Document
  • Status of This Memo
  • Copyright Notice
  • Table of Contents
  • 1. Introduction
    • 1.1. Usage and Applicability
    • 1.2. Limitations of this specification
    • 1.3. User Experience Considerations
  • 2. Conventions and Definitions
    • 2.1. Terminology
  • 3. Protocol Overview
    • 3.1. Initial Authorization Request
    • 3.2. Refresh Token Request
    • 3.3. Resource Request
  • 4. Protocol Endpoints
    • 4.1. Authorization Challenge Endpoint
    • 4.2. Token endpoint
  • 5. Authorization Initiation
    • 5.1. Authorization Challenge Request
    • 5.2. Authorization Challenge Response
      • 5.2.1. Authorization Code Response
      • 5.2.2. Error Response
        • 5.2.2.1. Redirect to Web Error Response
    • 5.3. Intermediate Requests
      • 5.3.1. Auth Session
  • 6. Token Request
    • 6.1. Token Endpoint Successful Response
    • 6.2. Token Endpoint Error Response
  • 7. Resource Server Error Response
  • 8. Authorization Server Metadata
  • 9. Security Considerations
    • 9.1. First-Party Applications
    • 9.2. Phishing
    • 9.3. Credential Stuffing Attacks
    • 9.4. Client Authentication
    • 9.5. Sender-Constrained Tokens
      • 9.5.1. DPoP: Demonstrating Proof-of-Possession
      • 9.5.2. Other Proof of Possession Mechanisms
    • 9.6. Auth Session
      • 9.6.1. Auth Session DPoP Binding
      • 9.6.2. Auth Session Lifetime
    • 9.7. Multiple Applications
      • 9.7.1. User Experience Risk
      • 9.7.2. Technical Risk
      • 9.7.3. Mitigation
    • 9.8. Single Page Applications
  • 10. IANA Considerations
    • 10.1. OAuth Parameters Registration
    • 10.2. OAuth Server Metadata Registration
  • 11. References
    • 11.1. Normative References
    • 11.2. Informative References
  • Appendix A. Example User Experiences
    • A.1. Passkey
    • A.2. Redirect to Authorization Server
    • A.3. Passwordless One-Time Password (OTP)
    • A.4. E-Mail Confirmation Code
    • A.5. Mobile Confirmation Code
    • A.6. Re-authenticating to an app a week later using OTP
    • A.7. Step-up Authentication using Confirmation SMS
    • A.8. Registration
  • Appendix B. Example Implementations
    • B.1. Authorization Challenge Request Parameters
    • B.2. Authorization Challenge Response Parameters
    • B.3. Example Sequence
    • [B.3.] Example Sequence
  • [Appendix C.] Design Goals
  • [Appendix D.] Document History
  • Acknowledgments
  • Authors' Addresses

1. Introduction

この文書「OAuth for First-Party Apps（FiPA）」は、OAuth 2.0 Authorization Framework（RFC6749）を、新しいエンドポイント authorization_challenge_endpoint により拡張し、ネイティブな体験を用いてユーザーから認可を取得するプロセスを制御したいファーストパーティ・アプリケーションをサポートします。

クライアントはユーザーから任意の初期情報を収集し、その情報に加えてクライアントのリクエストに関する情報を Authorization Challenge Endpoint に POST し、応答として認可コードまたはエラーコードのいずれかを受け取ります。エラーコードは、クライアントが追加情報を得るためにユーザーへのプロンプトを継続できることを示す場合もあれば、ユーザーがブラウザでフローを完了するためにクライアントがブラウザを起動する必要があることを示す場合もあります。

Authorization Challenge Endpoint は、認可エンドポイントへのリダイレクトまたはブラウザ起動の代わりに OAuth フローを開始するために使用されます。

リダイレクトベースの Authorization Code グラントを用いる完全委任型アプローチが一般に望ましい一方で、このドラフトはクライアントがユーザーと直接やり取りできるメカニズムを提供します。これは、（通常ファーストパーティ・アプリケーションにおいてそうであるように）認可サーバーとクライアントの間に高度な信頼を必要とします。ネイティブのモバイルまたはデスクトップ・アプリケーションなど、リダイレクトベースのアプローチにユーザビリティ上の懸念がある場合にのみ検討されるべきです。

このドラフトはまた、トークンレスポンス（通常はリフレッシュトークン・リクエストへの応答で使用される）およびリソースサーバーのレスポンスを拡張し、認可サーバーまたはリソースサーバーが、クライアントはユーザーに対して認可を再要求すべきであることを示せるようにします。これには、RFC9470 で定義されたパラメータを含めることにより、ステップアップ認証の要求を含めることもできます。

1.1. Usage and Applicability

この仕様は、ファーストパーティ・アプリケーションによってのみ使用されなければなりません（MUST）。ここでファーストパーティ・アプリケーションとは、認可サーバーとアプリケーションが同一の主体によって管理され、ユーザーが両者を同一主体として理解している場合を指します。

この仕様はサードパーティ・アプリケーションによって使用されてはなりません（MUST NOT）。また認可サーバーは、サードパーティ・アプリケーションによる使用を防止するための措置を講じるべきです（SHOULD）。（例：特定のクライアント ID に対してのみこのグラントを有効化し、可能な場合にはファーストパーティ・アプリを認証するための措置を講じる。例えば、I-D.ietf-oauth-attestation-based-client-auth で説明されているアプリのアテステーションを使用する、など。）

ここで説明した以外のシナリオでこの仕様を使用すると、ユーザーおよびサービス提供者にとって意図しないセキュリティおよびプライバシーの問題につながります。

この仕様は、ファーストパーティのネイティブアプリケーション（モバイルアプリケーションおよびデスクトップアプリケーションの両方を含む）で使用されるよう設計されています。

複数のアプリを提供しており、ユーザーが同一デバイス上で複数のアプリを使用することを想定している場合、各アプリがこの仕様を実装する、またはこの仕様を実装する SDK を使用する以外に、アプリ間でユーザーのログインを共有するより良い方法があるかもしれません。例えば OpenID.Native-SSO は、ユーザーとの一切の対話なしに、あるアプリが別のアプリのトークンを交換することで新しいトークンを取得するためのメカニズムを提供します。詳細は Section 9.7 を参照してください。

1.2. Limitations of this specification

この仕様のスコープは、ファーストパーティ・アプリケーションに限定されます。Section 9 の全体を確認してください。また、複数のファーストパーティ・アプリケーションをサポートする場合は、Section 9.7 も確認してください。

このドラフトはネイティブ OAuth 体験のための枠組みを提供しますが、各実装は、認可サーバーとやり取りする OAuth クライアントに期待する具体的な振る舞いを定義する必要があります。このように詳細が明確に定義されないことは、通常は相互運用性の低下につながりますが、この場合は許容されます。というのも、この仕様はファーストパーティ・アプリケーションにのみ適用されるため、密結合な環境で展開されることを意図しているからです。

1.3. User Experience Considerations

異なる認証チャレンジのユーザー体験上の影響、ならびにユーザーが認可を試みているデバイスについて考慮することが重要です。

例えば、入力制約のあるデバイス（例：TV）でユーザーにパスワード入力を求めると、多くのユーザー摩擦を生むと同時に、部屋にいる他者へユーザーのパスワードを晒すことにもなります。一方で、例えば TV リモコン上の指紋リーダーを用いて FIDO2 のパスキー認証を可能にする、といったチャレンジ手法を用いることは良い体験となるでしょう。

認可サーバーは、認証チャレンジを提示する際にユーザーのデバイスを考慮するべきです（SHOULD）。また開発者は、この仕様を実装するデバイスがユーザーにとって良い体験を提供できるかどうかを考慮するべきです（SHOULD）。ユーザーのデバイスと認証チャレンジ手法の組み合わせが、多くの摩擦またはセキュリティリスクを生む場合、OAuth 2.0 Device Authorization Grant（RFC8628）のような仕様の使用を検討してください。OAuth 2.0 Device Authorization Grant（RFC8628）のようにクロスデバイスの認可メカニズムを用いる場合は、Cross-Device Flows: Security Best Current Practice（I-D.ietf-oauth-cross-device-security）で特定されたセキュリティのベストプラクティスを取り入れてください。

2. Conventions and Definitions

この文書中のキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「NOT RECOMMENDED」「MAY」「OPTIONAL」は、BCP 14（RFC2119）（RFC8174）で説明されているとおりに解釈されます。ただし、ここに示すように、これらがすべて大文字で現れる場合、かつその場合に限ります。

2.1. Terminology

この仕様は、RFC6749 により定義される用語「Access Token」「Authorization Code」「Authorization Endpoint」「Authorization Server（AS）」「Client」「Client Authentication」「Client Identifier」「Client Secret」「Grant Type」「Protected Resource」「Redirection URI」「Refresh Token」「Resource Owner」「Resource Server（RS）」「Token Endpoint」を使用します。

TODO: RFC6749 への参照を OAuth 2.1 に置き換える

3. Protocol Overview

この仕様が OAuth システムのさまざまな部分を拡張する主要な方法は 3 つあります。

3.1. Initial Authorization Request

                                                +-------------------+
                                                |   Authorization   |
                          (B)Authorization      |      Server       |
             +----------+    Challenge Request  |+-----------------+|
(A)Client+---|  First-  |---------------------->||  Authorization  ||
   Starts|   |  Party   |                       ||   Challenge     ||
   Flow  +-->|  Client  |<----------------------||    Endpoint     ||
             |          | (C)Authorization      ||                 ||
             |          |    Error Response     ||                 ||
             |          |         :             ||                 ||
             |          |         :             ||                 ||
             |          | (D)Authorization      ||                 ||
             |          |    Challenge Request  ||                 ||
             |          |---------------------->||                 ||
             |          |                       ||                 ||
             |          |<----------------------||                 ||
             |          | (E) Authorization     |+-----------------+|
             |          |     Code Response     |                   |
             |          |                       |                   |
             |          |                       |                   |
             |          |                       |                   |
             |          | (F) Token             |                   |
             |          |     Request           |+-----------------+|
             |          |---------------------->||      Token      ||
             |          |                       ||     Endpoint    ||
             |          |<----------------------||                 ||
             |          | (G) Access Token      |+-----------------+|
             |          |                       |                   |
             +----------+                       +-------------------+

図: ファーストパーティ・クライアントの認可コード・リクエスト

• (A) ファーストパーティ・クライアントは、ユーザーに「サインイン」ボタンを提示する、またはユーザーからメールアドレスやユーザー名などの情報を収集することにより、フローを開始します。

• (B) クライアントは、Authorization Challenge Endpoint に対して POST リクエストを行うことにより認可リクエストを開始します。必要に応じて、ユーザーから収集した情報（例：メールアドレスまたはユーザー名）を含めます。

• (C) 認可サーバーは、Authorization Challenge Endpoint に提供された情報が認可を付与するのに十分かどうかを判断し、認可コードで応答するか、またはエラーで応答します。この例では、追加情報が必要であると判断し、エラーで応答します。このエラーには、次に収集すべき情報についてクライアントを導くための追加情報が含まれる場合があります。情報を収集して Authorization Challenge Endpoint に送信し、その後エラーまたは認可コードを受け取るというこのパターンは、数回繰り返される可能性があります。

• (D) クライアントは追加情報（例：署名済みのパスキー・チャレンジ、またはメールからのワンタイムコード）を収集し、Authorization Challenge Endpoint に対して POST リクエストを行います。

• (E) Authorization Challenge Endpoint は認可コードを返します。

• (F) クライアントは、ステップ (E) で受け取った認可コードを送信し、Token Endpoint からトークンを取得します。

• (G) 認可サーバーは Token Endpoint から Access Token を返します。

3.2. Refresh Token Request

クライアントがリフレッシュトークンを使用して新しいアクセストークンを取得する際、認可サーバーは、ユーザーの再認証が必要であることを示すために、エラーで応答してもよい（MAY）です。

3.3. Resource Request

リソースサーバーに対してリソースリクエストを行う際、リソースサーバーは OAuth 2.0 Step-Up Authentication Challenge Protocol（RFC9470）に従ってエラーで応答してもよく（MAY）、ユーザーの再認証が必要であることを示します。

4. Protocol Endpoints

4.1. Authorization Challenge Endpoint

認可チャレンジ・エンドポイントは、この仕様により定義される新しいエンドポイントであり、ファーストパーティ・アプリケーションが認可コードを取得するために使用します。

認可チャレンジ・エンドポイントは、認可サーバー上の HTTP API であり、application/x-www-form-urlencoded 形式を用いて HTTP リクエストメッセージボディ内にパラメータを含めた HTTP POST リクエストを受け付けます。この形式は、RFC6749 の Appendix B に記載されているとおり、UTF-8 の文字エンコーディングを持ちます。認可チャレンジ・エンドポイントの URL は "https" スキームを使用しなければなりません（MUST）。

認可サーバーが Token Endpoint においてこのクライアントに対してクライアント認証を要求する場合、認可サーバーは Authorization Challenge Endpoint においてもこのクライアントに対してクライアント認証を要求しなければなりません（MUST）。詳細は Section 9.4 を参照してください。

この仕様をサポートする認可サーバーは、Section 8 で定義される authorization_challenge_endpoint パラメータを使用して、認可サーバー・メタデータ文書（RFC8414）に自身の認可チャレンジ・エンドポイントの URL を含めるべきです（SHOULD）。

このエンドポイントは、認可エンドポイント向けに RFC6749 で定義される認可リクエスト・パラメータに加え、認可エンドポイント向けに定義されるすべての適用可能な拡張を受け付けます。そのような拡張の例として、Proof Key for Code Exchange（PKCE）（RFC7636）、Resource Indicators（RFC8707）、および OpenID Connect（OpenID）があります。いくつかの拡張パラメータはウェブ文脈では意味を持つ一方で、ネイティブなメカニズムでは意味を持たないことに注意することが重要です（例：response_mode=query）。ある拡張が、このユースケースで意味を持たないパラメータを定義している場合に AS が何をするかについてはスコープ外です。

クライアントは、ユーザーから収集した情報（例：署名済みパスキー・チャレンジまたは MFA コード）を含めても含めなくても、認可フローを開始します。

認可チャレンジ・エンドポイントのレスポンスは、認可コードまたはエラーコードのいずれかであり、またクライアントが後続のリクエストで使用する auth_session を含む場合もあります。

クライアントと認可サーバーの間のさらなる通信は、Authorization Challenge Endpoint または認可サーバー上のその他のプロプライエタリなエンドポイントで発生してもよい（MAY）です。

4.2. Token endpoint

トークン・エンドポイントは、OAuth 2.0（RFC6749）の Section 3.2 で説明されているとおり、クライアントがその認可グラントまたはリフレッシュトークンを提示してアクセストークンを取得するために使用されます。

この仕様は、認可サーバーがユーザーに対する追加の認証が必要であることを示せるようにするため、トークン・エンドポイントのレスポンスを拡張します。

5. Authorization Initiation

クライアントは、まずユーザーに対してユーザー識別子またはその他のアカウント情報の入力を促すことで、認可フローを開始したい場合があります。認可チャレンジ・エンドポイントは、このログインヒントを収集し、次のステップ（MFA フローを行うのか、OAuth のリダイレクトベースのフローを実行するのか）へクライアントを誘導するための新しいエンドポイントです。

この仕様のセキュリティを維持するために、認可サーバーは、認証フローを続行する前にクライアントの「ファーストパーティ性」を検証しなければなりません（MUST）。追加の考慮事項については Section 9.1 を参照してください。

5.1. Authorization Challenge Request

クライアントは、HTTP リクエストボディにおいて、UTF-8 の文字エンコーディングを持つ application/x-www-form-urlencoded 形式を使用し、以下のパラメータに加えて任意の拡張からのパラメータを追加することにより、認可チャレンジ・エンドポイントへリクエストを行います。

"client_id":

クライアントが認可サーバーに対して認証を行っておらず、かつ auth_session が含まれていない場合に REQUIRED です。

"scope":

OPTIONAL。RFC6749 で定義される OAuth スコープです。

"auth_session":

OPTIONAL。クライアントが以前に auth session を取得している場合（Section 5.3.1 で説明）。

"code_challenge":

OPTIONAL。RFC7636 で定義される code challenge です。詳細は Section 5.2.2.1 を参照してください。

"code_challenge_method":

OPTIONAL。RFC7636 で定義される code challenge method です。詳細は Section 5.2.2.1 を参照してください。

このエンドポイントで使用される追加のパラメータは、特定の実装およびこの仕様への拡張によって定義されてもよい（MAY）です。

例えば、ユーザーの電話番号を与えてフローを開始するために、クライアントは次のリクエストを行います。改行は説明のためにのみ示されています。

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

login_hint=%2B1-310-123-4567&scope=profile &client_id=bb16c14c73415

5.2. Authorization Challenge Response

認可サーバーは、ここまでに提供された情報が認可コードを発行するのに十分かどうかを判断し、十分であれば認可コードで応答します。情報が認可コードを発行するのに十分でない場合、認可サーバーはエラーレスポンスで応答しなければなりません（MUST）。

5.2.1. Authorization Code Response

認可サーバーは、RFC8259 で定義される application/json メディアタイプを使用して HTTP レスポンス・コンテンツを作成し、以下のパラメータと HTTP 200（OK）ステータスコードにより認可コードを発行します。

"authorization_code":

REQUIRED。認可サーバーによって発行された認可コードです。

例:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{ "authorization_code": "uY29tL2F1dGhlbnRpY" }

5.2.2. Error Response

リクエストに無効なパラメータまたは不正なデータが含まれる場合、または認可サーバーがユーザーと直接やり取りしたい場合、認可サーバーは（以下で別途指定されない限り）HTTP 400（Bad Request）ステータスコードで応答し、レスポンスに以下のパラメータを含めます。

"error":

REQUIRED。以下のいずれかの単一の ASCII（USASCII）エラーコードです。

"invalid_request":

リクエストに必須パラメータが欠けている、サポートされないパラメータ値が含まれる、パラメータが重複している、複数のクレデンシャルが含まれている、クライアント認証に複数のメカニズムが用いられている、またはその他の理由で不正形式です。

"invalid_client":

クライアント認証に失敗しました（例：不明なクライアント、クライアント認証が含まれていない、またはサポートされない認証方式）。認可サーバーは、どの HTTP 認証スキームがサポートされているかを示すために、HTTP 401（Unauthorized）ステータスコードを返してもよい（MAY）です。クライアントが Authorization リクエストヘッダフィールドを介して認証を試みた場合、認可サーバーは HTTP 401（Unauthorized）ステータスコードで応答し、クライアントが使用した認証スキームに一致する WWW-Authenticate レスポンスヘッダフィールドを含めなければなりません（MUST）。

"unauthorized_client":

認証済みのクライアントが、このエンドポイントの使用を許可されていません。

"invalid_session":

提供された auth_session が無効、期限切れ、失効済み、またはその他の理由で無効です。

"invalid_scope":

要求されたスコープが無効、不明、不正形式、またはリソースオーナーにより付与されたスコープを超えています。

"insufficient_authorization":

提示された認可が不十分であり、認可サーバーはクライアントに対して認可を完了するための追加ステップを取るよう要求しています。

"redirect_to_web":

リクエストは、ユーザーとのさらなる直接的なやり取りによっては満たすことができません。代わりに、クライアントは新しい認可コード・フローを開始し、ユーザーがウェブブラウザ内で認可サーバーとやり取りできるようにすべきです。詳細は Section 5.2.2.1 を参照してください。

error パラメータの値は、集合 %x20-21 / %x23-5B / %x5D-7E の外にある文字を含んではなりません（MUST NOT）。

認可サーバーは、認可サーバーの要件に基づいて、これらのエラーコードをカスタムメッセージで拡張してもよい（MAY）です。

"error_description":

OPTIONAL。発生したエラーの理解を助けるために、クライアント開発者を支援する追加情報を提供する、人間が読める ASCII（USASCII）テキストです。error_description パラメータの値は、集合 %x20-21 / %x23-5B / %x5D-7E の外にある文字を含んではなりません（MUST NOT）。

"error_uri":

OPTIONAL。エラーに関する情報を含む、人間が読めるウェブページを識別する URI です。これは、クライアント開発者にエラーに関する追加情報を提供するために使用されます。error_uri パラメータの値は URI-reference 構文に適合しなければならず（MUST）、したがって集合 %x21 / %x23-5B / %x5D-7E の外にある文字を含んではなりません（MUST NOT）。

"auth_session":

OPTIONAL。auth session により、認可サーバーは、このクライアントによる後続リクエストを、進行中の認可リクエスト・シーケンスに関連付けることができます。クライアントは、エラーレスポンスとともに auth_session を受け取った場合、認可チャレンジ・エンドポイントへのフォローアップ・リクエストに auth_session を含めなければなりません（MUST）。

"request_uri":

OPTIONAL。RFC9126 の Section 2.2 で説明される request URI です。

"expires_in":

OPTIONAL。RFC9126 の Section 2.2 で説明される、request_uri の有効期間（秒）です。

この仕様は、ユーザーを適切に認証するためにクライアントが取らなければならないアクションに関連する新しいエラーコードを、認可サーバーが定義することを要求します。これらの新しいエラーコードは、この仕様の認可サーバー実装に固有であり、意図的にスコープ外とされています。

これらのパラメータは、RFC7159 で定義される application/json メディアタイプを用いて、HTTP レスポンスのコンテンツに含められます。パラメータは、各パラメータを最上位の構造レベルに追加することで JSON 構造へ直列化されます。パラメータ名と文字列値は JSON 文字列として含められます。数値は JSON 数値として含められます。パラメータの順序は重要ではなく、変わり得ます。

認可サーバーは、実装に応じてレスポンスに追加のパラメータを定義してもよい（MAY）です。認可サーバーはまた、レスポンスが JSON であり application/<AS-defined>+json に適合する限り、エラーレスポンスに対してより具体的なコンテンツタイプを定義してもよい（MAY）です。

5.2.2.1. Redirect to Web Error Response

認可サーバーは、リスク評価、アプリケーションでサポートされていない新しい認証方式の導入、またはアカウント回復のような例外フローを処理するために、ユーザーと直接やり取りすることを選択する場合があります。クライアントにこのエラーを示すために、認可サーバーは、上で定義した redirect_to_web エラーコードを持つエラーレスポンスを返します。

この場合、クライアントは RFC6749 および RFC7636 に従って、PKCE を伴う新しい OAuth Authorization Code フローを開始することが期待されます。

クライアントがこのエラーレスポンスの発生頻度が高いと見込む場合、クライアントは初回の認可チャレンジ・リクエストに PKCE（RFC7636）の code_challenge を含めてもよい（MAY）です。これにより、認可サーバーは実質的に認可チャレンジ・リクエストを PAR（RFC9126）リクエストとして扱い、エラーレスポンスにおいて RFC9126 で定義される request_uri および expires_in を返せるようになります。その後、クライアントは request_uri 値を使用して、RFC9126 の Section 4 で定義される認可リクエストを構築します。

5.3. Intermediate Requests

上で説明した insufficient_authorization エラーを認可サーバーが返した場合、これは、クライアントがユーザーに対して要求すべき追加情報があることを示しています。そしてクライアントは、認可リクエストが満たされ、認可コードが返されるまで、ユーザーから情報を要求し続け、認可サーバーへのリクエストを継続すべきです。

これらの中間リクエストはこの仕様のスコープ外であり、認可サーバーによって定義されることが期待されます。これらのリクエストの形式は、初回の認可チャレンジ・リクエストの形式に適合する必要はありません（例：リクエスト形式が application/x-www-form-urlencoded ではなく application/json である場合があります）。

これらの中間リクエストは、Authorization Challenge Endpoint ではなく、認可サーバー上のプロプライエタリなエンドポイントに送信されてもよい（MAY）です。

5.3.1. Auth Session

auth_session は、同一クライアントからの後続リクエストを関連付けられるようにするために、認可サーバーが発行する値です。これは、ブラウザのクッキーが同一ブラウザによる複数のリクエストを認可サーバーに関連付ける方法に類似することを意図しています。

auth_session の値はクライアントにとって完全に不透明であり、そのため認可サーバーは、例えばランダム文字列を使用する、またはバックエンドで状態を維持していない場合には JWE を使用するなどして、クライアントによる値の検査からこの値を適切に保護しなければなりません（MUST）。

クライアントが auth_session を持っている場合、クライアントは認可チャレンジ・エンドポイントへの将来のリクエストにそれを含めなければなりません（MUST）。クライアントは、将来のリクエストで使用できるようにするため、認可コードの発行後も auth_session を保存しなければなりません（MUST）。

この仕様で定義されるすべてのレスポンスは、新しい auth_session 値を含む場合があります。クライアントは auth_session 値が固定であると仮定してはならず（MUST NOT）、レスポンスで auth_session 値を受け取った場合に保存済みの auth_session 値を更新できるよう備えなければなりません（MUST）。

セッションハイジャックのリスクを緩和するため、'auth_session' はデバイスにバインドされなければならず（MUST）、認可サーバーは、それがバインドされたデバイスとは異なるデバイスから提示された場合には 'auth_session' を拒否しなければなりません（MUST）。

追加のセキュリティ上の考慮事項については Section 9.6 を参照してください。

6. Token Request

クライアントは、認可チャレンジ・エンドポイントから取得した認可コードを使用して、トークン・エンドポイントへリクエストを行います。

この仕様は、RFC6749 の Section 4.1.3 で定義されるトークン・リクエスト・パラメータを超える追加パラメータを定義しません。しかし注目すべき点として、このリクエストには redirect_uri パラメータは含まれません。なぜなら、認可リクエストに redirect_uri パラメータが含まれていなかったためです。

6.1. Token Endpoint Successful Response

この仕様は、RFC6749 の Section 5.1 で定義される OAuth 2.0 のトークンレスポンスを、Section 5.3.1 で定義される追加パラメータ auth_session によって拡張します。

成功したトークンレスポンスの例を以下に示します。

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

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

このレスポンスには、クライアントが Section 5.3.1 で説明されるとおり、認可チャレンジ・エンドポイントへの後続リクエストに含めることが期待される auth_session パラメータが含まれてもよい（MAY）です。auth_session パラメータはまた、認可コードがこの仕様で定義されるフローではなく、従来の OAuth 認可コード・フローにより取得された場合であっても含められてよい（MAY）です。

トークンレスポンスに auth_session パラメータを含めることで、ステップアップ認証（RFC9470）のようなフローが可能となり、認可サーバーは以前のセッションのコンテキストを復元し、必要なステップアップ要素のみを求めてプロンプトできます。例のアプリケーションについては Appendix A.7 を参照してください。

6.2. Token Endpoint Error Response

有効なリフレッシュトークンを用いたリクエストを含め、トークン・エンドポイントへのあらゆるリクエストに対して、認可サーバーは成功したアクセストークンレスポンスの代わりに、認可チャレンジで応答できます。

認可チャレンジ・エラーレスポンスは、OAuth 2.0（RFC6749）の Section 5.2 で定義される特定種別のエラーレスポンスであり、エラーコードが次の値に設定されます。

"error": "insufficient_authorization":

提示された認可が不十分であり、認可サーバーはクライアントに対して認可を完了するための追加ステップを取るよう要求しています。

さらに、このレスポンスには、クライアントが認可チャレンジ・エンドポイントへの後続リクエストに含めることが期待される auth_session パラメータが含まれてもよい（MAY）です。

"auth_session":

OPTIONAL。任意の auth session 値により、認可サーバーは、このクライアントによる後続リクエストを進行中の認可リクエスト・シーケンスに関連付けることができます。クライアントは、エラーレスポンスとともに auth_session を受け取った場合、チャレンジ・エンドポイントへのフォローアップ・リクエストに auth_session を含めなければなりません（MUST）。

例:

HTTP/1.1 403 Forbidden
Content-Type: application/json
Cache-Control: no-store

{ "error": "insufficient_authorization", "auth_session": "uY29tL2F1dGhlbnRpY"
}

7. Resource Server Error Response

Step-Up Authentication（RFC9470）は、リソースサーバーがクライアントに対して、OpenID（OpenID）由来の acr_values および max_age を含む新しい認可リクエストを開始するよう伝えるために使用できる、新しいエラーコード値を定義します。このエラーレスポンスを受け取ると、クライアントは認可チャレンジ・エンドポイントで新しいファーストパーティ認可リクエストを開始し、エラーレスポンスで返された acr_values、max_age、および scope を含めます。

この仕様は、RFC9470 および RFC6750 で定義されるものを超えて、リソースサーバーのエラーレスポンスのための新しいパラメータを定義しません。

8. Authorization Server Metadata

以下の認可サーバー・メタデータ・パラメータ（RFC8414）が導入され、ファーストパーティ・アプリケーションに関するサーバーの能力およびポリシーを示します。

"authorization_challenge_endpoint":

クライアントが認可リクエストを開始し、最終的に認可コードを取得できる認可チャレンジ・エンドポイントの URL です。

9. Security Considerations

9.1. First-Party Applications

ファーストパーティ・アプリケーションとは、アプリケーションが使用する認可サーバーと同一の主体によって管理され、ユーザーが両者を同一主体として理解しているアプリケーションです。

ファーストパーティ・アプリケーションにおいては、ユーザーがアプリケーションと認可サーバーが同一ブランドに属していると認識することが重要です。例えば、銀行が自社のモバイルアプリケーションを公開する場合です。

この仕様は、クライアントアプリケーションがエンドユーザーと直接やり取りでき、かつアプリケーションがユーザーから収集したあらゆる情報を認可サーバーへ送信することを扱うため、認可サーバーがクライアントに対しても高い信頼を有する場合に、ファーストパーティ・アプリケーションにのみ使用されることが期待されます。

この仕様は、認可サーバーがアプリケーションのファーストパーティ性に対する信頼をどのように確立するかについて規定的ではありません。モバイルプラットフォームでは、多くがアプリストアへアプリを作成／署名／アップロードした主体を識別するために利用できる、アプリケーション・アテステーションの何らかのメカニズムをサポートしています。アプリのアテステーションは、アテステーションベースのクライアント認証（I-D.ietf-oauth-attestation-based-client-auth）や動的クライアント登録（RFC7591）といったメカニズムと組み合わせて、クライアント検証（ファーストパーティ性）に加えて強力なクライアント認証を可能にできます。必要となる正確な手順はこの仕様のスコープ外です。ブラウザ内（例：Single Page Apps）という文脈で動作するアプリケーションでは、クライアントのファーストパーティ性を検証することがはるかに困難である点に注意してください。追加の詳細については Section 9.8 を参照してください。

9.2. Phishing

この仕様を使用するとフィッシングのリスクが増加する方法は 2 つあります。

1. 悪意あるアプリケーション：この仕様では、クライアントがエンドユーザーと直接やり取りし、ユーザーから提供された情報を収集して認可サーバーへ送信します。攻撃者がクライアントになりすまし、ユーザーをうまく騙してそれを利用させた場合、ユーザーは悪意あるアプリケーションに対して自分のクレデンシャルを渡していることに気付かないかもしれません。

2. ユーザー教育：リダイレクトベースの認可コード・フローを用いる従来の OAuth 展開では、ユーザーは認可サーバーでのみクレデンシャルを入力し、他の「偽」ウェブサイトでクレデンシャルを入力しないよう説明するのは簡単です。この仕様により、ユーザーがクレデンシャルを入力することが期待される新しい場所を導入することで、クレデンシャルを盗もうとしている可能性のある他の偽のログインプロンプトを、ユーザーがどのように見分けるべきかを教えることがより複雑になります。

これらのリスクのため、認可サーバーは、自身のリスク評価に基づき、プロセスのいかなる段階においてもユーザーにリダイレクトベースのフローを通らせることを要求することを決定してもよい（MAY）です。

9.3. Credential Stuffing Attacks

認可チャレンジ・エンドポイントは、ユーザーのクレデンシャルを直接受け取り、認可コードを返すことができます。これは、アプリケーションの真正性を確保するための追加措置が取られない場合、クレデンシャル・スタッフィング攻撃を実行する新たなベクタを露出させます。

認可サーバーは、ブラウザベースの認証フローにおいてこのリスクを監視し低減するために、組み込みまたはサードパーティのセキュリティツールの組み合わせを既に備えている場合があります。実装者は、認可チャレンジ・エンドポイントにおいてこのリスクを低減するために、同様のセキュリティ対策を検討するべきです（SHOULD）。さらに、可能な場合にはアテステーション API を使用し、リクエストが同一主体が所有するアプリケーションから発生しているという信頼度の水準を認可サーバーへ主張するべきです（SHOULD）。

9.4. Client Authentication

通常、モバイルおよびデスクトップ・アプリケーションは OAuth において「パブリッククライアント」と見なされます。というのも、静的に構成されたクライアント・クレデンシャルのセットを同梱して出荷することができないためです（RFC8252）。このため、このパターンを展開する者にとって、クライアントのなりすましは懸念事項となるべきです。クライアント認証がない場合、悪意あるユーザーまたは攻撃者は、アプリケーションが認可サーバーへ行うリクエストを模倣し、正当なクライアントであるかのように装うことができます。

実装者は、オペレーティングシステムから利用可能なアテステーション API を使用するなど、クライアントなりすましのリスクを制限するための追加措置を検討するべきです（SHOULD）。

9.5. Sender-Constrained Tokens

認可チャレンジ・リクエストへの応答として発行されるトークンは、トークン窃取およびリプレイのリスクを緩和するために、送信者制約されるべきです（SHOULD）。

所持証明（Proof-of-Possession）技術は、トークンを暗号鍵へバインドすることで、トークンを制約します。トークンが提示されるたびに、そのトークンを提示しているクライアントが、トークンにバインドされた暗号鍵も制御していることを示す証明を伴わなければなりません（MUST）。所持証明の送信者制約付きトークンが、暗号鍵の有効な所持証明なしに提示された場合、それは拒否されなければなりません（MUST）。

9.5.1. DPoP: Demonstrating Proof-of-Possession

DPoP（RFC9449）は、OAuth（RFC6749）のアクセストークンおよびリフレッシュトークンを送信者制約するための、アプリケーション層のメカニズムです。DPoP がトークンを送信者制約するために使用される場合、クライアントは、認可サーバーへのあらゆるトークンリクエストおよびリソースサーバーとのやり取りのたびに DPoP を使用するべきです（SHOULD）。

DPoP には、認可コードを DPoP 鍵にバインドして、認可フロー全体のエンドツーエンドのバインディングを可能にするための、任意の機能が含まれます。この仕様のバックチャネル的性質を踏まえると、リダイレクトベースの認可コード・フローと比較して、攻撃者が認可コードおよび PKCE のコード検証子へアクセスする機会ははるかに少なくなります。この仕様では、認可コードはバックチャネル・リクエストを介して取得されます。それにもかかわらず、認可コードのバインディングを省略すると、DPoP が提供するエンドツーエンド保護にギャップが残るため、DPoP の認可コード・バインディングは使用されるべきです（SHOULD）。

DPoP による認可コード・バインディングのメカニズムは、RFC9449 の Section 10.1 で Pushed Authorization Requests（PAR）に対して定義されるものと同様です。DPoP で認可コードをバインドするために、クライアントは Authorization Challenge Request に DPoP ヘッダを追加しなければなりません（MUST）。認可サーバーは、RFC9449 の Section 4.3 で定義されるとおり、DPoP ヘッダに含まれていた DPoP proof JWT を検証しなければなりません（MUST）。認可サーバーは、後続のすべての Authorization Challenge Request および最終的なトークンリクエストにおいて同じ鍵が使用されることを保証しなければなりません（MUST）。認可サーバーは、元の Authorization Challenge Request で提示された同じ鍵に対する DPoP proof が提供されない限り、後続の Authorization Challenge Request または最終的なトークンリクエストを拒否しなければなりません（MUST）。

上記メカニズムは、リクエストの種類に関係なく、クライアントが認可サーバーへのすべてのリクエストに DPoP ヘッダを付与できるため、クライアントの実装を単純化します。このメカニズムは、DPoP ヘッダが秘密鍵の所持証明を含むため、dpop_jkt パラメータを使用するよりも強いバインディングを提供します。

9.5.2. Other Proof of Possession Mechanisms

アクセストークンおよびリフレッシュトークンを送信者制約するために、他の所持証明メカニズムを使用できる可能性があります。これらのメカニズムを定義することは、この仕様のスコープ外です。

9.6. Auth Session

9.6.1. Auth Session DPoP Binding

クライアントと認可サーバーが、アクセストークンおよび／または認可コードの DPoP バインディングを使用している場合、auth_session 値も保護されるべきです（SHOULD）。認可サーバーは、auth_session 値を DPoP 公開鍵に関連付けるべきです（SHOULD）。これにより、認可サーバーが DPoP proof に追加のクレームを含める必要がなくなる一方で、proof を提示するクライアントが DPoP 鍵を制御しているという保証の恩恵を受けられます。auth_session 値を DPoP 公開鍵に関連付けるために、認可サーバーは次を行います。

• クライアントが DPoP proof を提示する際に、同じ DPoP 公開鍵が使用されていることを確認しなければなりません（MUST）。

• クライアントが Section 5.1 で説明されるとおり Authorization Challenge Request に auth_session を含めるたびに、クライアントが対応する秘密鍵を制御していることを保証するために DPoP proof を検証しなければなりません（MUST）。

auth_session 値の DPoP バインディングにより、auth_session が参照するコンテキストが盗まれて別のデバイスにより再利用されることを防げます。

9.6.2. Auth Session Lifetime

この仕様は、auth_session 値の存続期間について、いかなる要件も仮定も置きません。存続期間と失効は認可サーバーの裁量に委ねられ、認可サーバーは、予定された期限切れ、セキュリティイベント、または失効イベントなど、いかなる理由によってもこの値を無効化することを選択できます。

クライアントは、auth_session 値の特定の存続期間について、いかなる仮定もしてはならず（MUST NOT）、またそれに依存してはなりません。

9.7. Multiple Applications

AS が複数のファーストパーティ・アプリケーションをサポートする場合、追加のリスクをいくつか考慮することが重要です。これらのリスクは、以下で説明する 2 つの主要カテゴリ、すなわち「体験リスク（Experience Risk）」と「技術的リスク（Technical Risk）」に分類されます。

9.7.1. User Experience Risk

ユーザーが異なるユーザー体験の中で認証クレデンシャルの提供を求められるたびに、ユーザーが見た目の異なる体験でクレデンシャルを入力することに慣れてしまうため、フィッシング攻撃の被害に遭う可能性が高まる効果があります。複数のファーストパーティ・アプリケーションがサポートされる場合、実装は、ネイティブ体験がすべてのファーストパーティ・アプリケーションにわたって同一であることを保証しなければなりません（MUST）。

もう一つの体験リスクは、見た目の異なる体験や振る舞いによって引き起こされるユーザーの混乱です。これは、ユーザーがファーストパーティ・アプリケーションの認証体験を完了しない可能性を高めることがあります。

9.7.2. Technical Risk

体験上のリスクに加えて、ファーストパーティ・アプリケーションにおける複数の実装は、誤った実装のリスクを高めるとともに、各実装がそれぞれ固有の弱点を露出し得るため、攻撃対象領域（アタックサーフェス）を拡大します。

9.7.3. Mitigation

これらのリスクに対処するため、複数のファーストパーティ・アプリケーションをサポートしなければならず、かつ OpenID.Native-SSO のような他の方法が適用できない場合には、異なるアプリケーション間で実装の一貫性を確保し、すべてのファーストパーティ・アプリでユーザー体験を同一にするために、クライアントサイドの SDK を使用することが RECOMMENDED です。

9.8. Single Page Applications

Single Page Applications（SPA）は、ブラウザインスタンスのコンテキスト内でスクリプト言語として実行されます。この環境は、ネイティブアプリケーションと比べて、特に次のようないくつかの固有の課題を伴います。

• Cross-Site Scripting（XSS）攻撃の可能性による、重大な攻撃ベクタ

• ブラウザベースのアプリケーションのファーストパーティ性を安全にアテストするための選択肢が少ないこと

ブラウザにおける XSS 攻撃のリスクについての詳細な議論は、I-D.ietf-oauth-browser-based-apps を参照してください。

さらに、Single-Page App の性質上、ユーザーは既にブラウザ文脈にいるため、従来の OAuth Authorization Code Flow のためにフルページのリダイレクトやポップアップウィンドウを行うユーザー体験上のコストは、ネイティブアプリケーションでそれを行うコストよりはるかに小さくなります。ブラウザでこの仕様を実装する複雑さとリスクは、その文脈で得られるであろうユーザー体験上の利得を、おそらく上回りません。

これらの理由により、ブラウザベースのアプリケーションでこの仕様を使用することは NOT RECOMMENDED です。

10. IANA Considerations

10.1. OAuth Parameters Registration

IANA は、RFC6749 によって確立された IANA「OAuth Parameters」レジストリ（IANA.oauth-parameters）に、以下の値を（TBD）登録しました。

Parameter name: auth_session

Parameter usage location: トークンレスポンス

Change Controller: IETF

Specification Document: この仕様の Section 5.4

10.2. OAuth Server Metadata Registration

IANA は、RFC8414 によって確立された IANA「OAuth Authorization Server Metadata」レジストリ（IANA.oauth-parameters）に、以下の値を（TBD）登録しました。

Metadata Name: authorization_challenge_endpoint

Metadata Description: 認可サーバーの認可チャレンジ・エンドポイントの URL。

Change Controller: IESG

Specification Document: この仕様の Section 4.1

11. References

11.1. Normative References

[I-D.ietf-oauth-cross-device-security]

Kasselman, P., Fett, D., and F. Skokan, 「Cross-Device Flows: Security Best Current Practice」, Work in Progress, Internet-Draft, draft-ietf-oauth-cross-device-security-12, 5 September 2025, 。

[IANA.JWT]

「 BROKEN REFERENCE 」。

[IANA.oauth-parameters]

IANA, 「OAuth Parameters」, 。

[OpenID]

Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, 「OpenID Connect Core 1.0」, November 2014, 。

[OpenID.Native-SSO]

Fletcher, G., 「OpenID Connect Native SSO for Mobile Apps」, November 2022, 。

[RFC2119]

Bradner, S., 「Key words for use in RFCs to Indicate Requirement Levels」, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, 。

[RFC6749]

Hardt, D., Ed., 「The OAuth 2.0 Authorization Framework」, RFC 6749, DOI 10.17487/RFC6749, October 2012, 。

[RFC7159]

Bray, T., Ed., 「The JavaScript Object Notation (JSON) Data Interchange Format」, RFC 7159, DOI 10.17487/RFC7159, March 2014, 。

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, 「JSON Web Signature (JWS)」, RFC 7515, DOI 10.17487/RFC7515, May 2015, 。

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, 「JSON Web Token (JWT)」, RFC 7519, DOI 10.17487/RFC7519, May 2015, 。

[RFC7591]

Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, 「OAuth 2.0 Dynamic Client Registration Protocol」, RFC 7591, DOI 10.17487/RFC7591, July 2015, 。

[RFC7636]

Sakimura, N., Ed., Bradley, J., and N. Agarwal, 「Proof Key for Code Exchange by OAuth Public Clients」, RFC 7636, DOI 10.17487/RFC7636, September 2015, 。

[RFC8174]

Leiba, B., 「Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words」, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, 。

[RFC8259]

Bray, T., Ed., 「The JavaScript Object Notation (JSON) Data Interchange Format」, STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, 。

[RFC8414]

Jones, M., Sakimura, N., and J. Bradley, 「OAuth 2.0 Authorization Server Metadata」, RFC 8414, DOI 10.17487/RFC8414, June 2018, 。

[RFC8628]

Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, 「OAuth 2.0 Device Authorization Grant」, RFC 8628, DOI 10.17487/RFC8628, August 2019, 。

[RFC8707]

Campbell, B., Bradley, J., and H. Tschofenig, 「Resource Indicators for OAuth 2.0」, RFC 8707, DOI 10.17487/RFC8707, February 2020, 。

[RFC9126]

Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, 「OAuth 2.0 Pushed Authorization Requests」, RFC 9126, DOI 10.17487/RFC9126, September 2021, 。

[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, 「OAuth 2.0 Demonstrating Proof of Possession (DPoP)」, RFC 9449, DOI 10.17487/RFC9449, September 2023, 。

[RFC9470]

Bertocci, V. and B. Campbell, 「OAuth 2.0 Step Up Authentication Challenge Protocol」, RFC 9470, DOI 10.17487/RFC9470, September 2023, 。

[SHS]

Technology, N. I. of S. and., 「"Secure Hash Standard (SHS)"」, FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, 。

[USASCII]

Institute, A. N. S., 「Coded Character Set -- 7-bit American Standard Code for Information Interchange, ANSI X3.4」, 1986。

11.2. Informative References

[I-D.ietf-oauth-attestation-based-client-auth]

Looker, T., Bastian, P., and C. Bormann, 「OAuth 2.0 Attestation-Based Client Authentication」, Work in Progress, Internet-Draft, draft-ietf-oauth-attestation-based-client-auth-07, 15 September 2025, 。

[I-D.ietf-oauth-browser-based-apps]

Parecki, A., De Ryck, P., and D. Waite, 「OAuth 2.0 for Browser-Based Applications」, Work in Progress, Internet-Draft, draft-ietf-oauth-browser-based-apps-25, 3 July 2025, 。

[RFC6750]

Jones, M. and D. Hardt, 「The OAuth 2.0 Authorization Framework: Bearer Token Usage」, RFC 6750, DOI 10.17487/RFC6750, October 2012, 。

[RFC8252]

Denniss, W. and J. Bradley, 「OAuth 2.0 for Native Apps」, BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, 。

Appendix A. Example User Experiences

この節は、この仕様が特定のユースケースを支援するためにどのように使用され得るかについての、非規範的（non-normative）な例を提供します。

A.1. Passkey

ユーザーは（パスワードなしで）パスキーでログインすることができます。

1. クライアントはユーザーからユーザー名を収集します。

2. クライアントは、ユーザー名を含めて、認可チャレンジ・リクエスト（Section 5.1）を認可チャレンジ・エンドポイント（Section 4.1）へ送信します。

3. 認可サーバーはユーザー名を検証し、チャレンジを返します。

4. クライアントはプラットフォーム・オーセンティケータを使ってチャレンジに署名します。これにより、ユーザーは生体情報または PIN による検証を求められます。

5. クライアントは、署名済みチャレンジ、ユーザー名、およびクレデンシャル ID を認可チャレンジ・エンドポイント（Section 4.1）へ送信します。

6. 認可サーバーは署名済みチャレンジを検証し、認可コードを返します。

7. クライアントは、トークン・リクエスト（Section 6）をトークン・エンドポイントへ発行することにより、アクセストークンおよびリフレッシュトークンを要求します。

8. 認可サーバーは認可コードを検証し、要求されたトークンを発行します。

A.2. Redirect to Authorization Server

ユーザーは、アカウントのリセットを実行するために、認可サーバーへリダイレクトされることがあります。

1. クライアントはユーザーからユーザー名を収集します。

2. クライアントは、ユーザー名を含めて、認可チャレンジ・リクエスト（Section 5.1）を認可チャレンジ・エンドポイント（Section 4.1）へ送信します。

3. 認可サーバーはユーザー名を検証し、アカウントがロックされていることを判断して、リダイレクトのエラーレスポンスを返します。

4. クライアントはリダイレクト・メッセージを解析し、ブラウザを開いて、PKCE を用いた OAuth 2.0 フローを実行しながらユーザーを認可サーバーへリダイレクトします。

5. ユーザーは、認可サーバーとの多段階の認証フローを実行することで、アカウントをリセットします。

6. 認可サーバーは、クライアントへのリダイレクトで認可コードを発行し、その後クライアントはそれをアクセストークンおよびリフレッシュトークンと交換します。

A.3. Passwordless One-Time Password (OTP)

パスワードレスのワンタイムパスワード（OTP）方式では、ユーザーはワンタイムパスワード生成器を所持します。この生成器はハードウェアデバイスである場合もあれば、携帯電話上のアプリとして実装される場合もあります。ユーザーはユーザー識別子とワンタイムパスワードを提示し、認可サーバーがそれを検証した後に認可コードを発行します。その認可コードは、アクセストークンおよびリフレッシュトークンと交換できます。

1. クライアントはユーザーからユーザー名と OTP を収集します。

2. クライアントは、ユーザー名と OTP を含めて、認可チャレンジ・リクエスト（Section 5.1）を認可チャレンジ・エンドポイント（Section 4.1）へ送信します。

3. 認可サーバーはユーザー名と OTP を検証し、認可コードを返します。

4. クライアントは、トークン・リクエスト（Section 6）をトークン・エンドポイントへ発行することにより、アクセストークンおよびリフレッシュトークンを要求します。

5. 認可サーバーは認可コードを検証し、要求されたトークンを発行します。

A.4. E-Mail Confirmation Code

ユーザーは、電子メールアドレスを制御していることを証明するために、認証手続き（authentication ceremony）の一部として、電子メール確認コードの提示を求められることがあります。ユーザーは電子メールアドレスを提示し、その後、その電子メールアドレスへ送られた検証コードを入力することを求められます。正しい検証コードが認可サーバーへ返されると、認可サーバーはアクセストークンおよびリフレッシュトークンを発行します。

1. クライアントはユーザーから電子メールアドレスを収集します。

2. クライアントは、電子メールアドレスを認可チャレンジ・リクエスト（Section 5.1）として認可チャレンジ・エンドポイント（Section 4.1）へ送信します。

3. 認可サーバーは電子メールアドレスへ検証コードを送信し、"error": "insufficient_authorization"、"auth_session"、および電子メール検証コードを入力しなければならないことを示すカスタムプロパティを含むエラーレスポンス（Section 5.2.2）を返します。

4. クライアントは、ユーザーが電子メール検証コードをクライアントへコピーするよう案内するユーザー体験を提示します。電子メール検証コードが入力されると、クライアントは、電子メール検証コードに加えて、直前のエラーレスポンスで返された auth_session パラメータを含めて、認可チャレンジ・リクエストを認可チャレンジ・エンドポイントへ送信します。

5. 認可サーバーは auth_session を用いてセッションを維持し、電子メール検証コードを検証した上で、クライアントへ認可コードを発行します。

6. クライアントは、認可コードをトークン・リクエスト（Section 6）としてトークン・エンドポイントへ送信します。

7. 認可サーバーは認可コードを検証し、アクセストークンおよびリフレッシュトークンを発行します。

この検証の代替版として、ユーザーが検証コードを手動で入力する代わりに、メール内のリンクをクリックする方法があります。これは通常、ログインフローの途中（inline）というより、メール検証フローのために行われます。ユーザー体験が異なるにもかかわらず、代替フローにおけるプロトコルレベルの詳細は同一のままです。上記の手順 4 を除くすべての手順は同一ですが、クライアントは、以下に説明される手順 4 のための代替ユーザー体験を提示します。

• クライアントは、メールアドレスへ送られたリンクをクリックするようユーザーに指示するメッセージを提示します。ユーザーはメール内のリンクをクリックし、そのリンクには URL 内に検証コードが含まれています。その URL はアプリを起動し、検証コードをクライアントへ渡します。クライアントは検証コードと auth_session を認可チャレンジ・エンドポイントへ送信します。

A.5. Mobile Confirmation Code

ユーザーは、携帯電話番号を制御していることを証明するために、認証手続き（authentication ceremony）の一部として、確認コードの提示を求められることがあります。ユーザーは電話番号を提示し、その後、その電話へ送られた確認コードを入力することを求められます。正しい確認コードが認可サーバーへ返されると、認可サーバーはアクセストークンおよびリフレッシュトークンを発行します。

1. クライアントはユーザーから携帯電話番号を収集します。

2. クライアントは、電話番号を認可チャレンジ・リクエスト（Section 5.1）として認可チャレンジ・エンドポイント（Section 4.1）へ送信します。

3. 認可サーバーは電話番号へ確認コードを送信し、"error": "insufficient_authorization"、"auth_session"、および確認コードを入力しなければならないことを示すカスタムプロパティを含むエラーレスポンス（Section 5.2.2）を返します。

4. クライアントは、ユーザーが確認コードを入力するよう案内するユーザー体験を提示します。コードが入力されると、クライアントは、確認コードに加えて、直前のエラーレスポンスで返された auth_session パラメータを含めて、認可チャレンジ・リクエストを認可チャレンジ・エンドポイントへ送信します。

5. 認可サーバーは auth_session を用いてセッション・コンテキストを維持し、コードを検証した上で、クライアントへ認可コードを発行します。

6. クライアントは、認可コードをトークン・リクエスト（Section 6）としてトークン・エンドポイントへ送信します。

7. 認可サーバーは認可コードを検証し、アクセストークンおよびリフレッシュトークンを発行します。

A.6. Re-authenticating to an app a week later using OTP

クライアントは、過去の成功したユーザー認証の結果として、アクセストークンおよびリフレッシュトークンを所持している場合があります。ユーザーは 1 週間後にアプリへ戻り、アプリへアクセスします。クライアントはアクセストークンを提示しますが、アクセストークンがもはや有効ではないことを示すエラーを受け取ります。クライアントは、新しいアクセストークンを取得するために、リフレッシュトークンを認可サーバーへ提示します。認可サーバーが自身のポリシーに基づく理由でユーザー操作を要求する場合、リフレッシュトークンを拒否し、クライアントは新しいアクセストークンおよびリフレッシュトークンを取得するためにユーザー認証フローを再開始します。

1. クライアントは、ユーザー認証を含む認可付与フロー（Authorization Grant Flow）の以前の完了に続いて、短命なアクセストークンと長命なリフレッシュトークンを持っています。

2. 1 週間後、ユーザーはアプリを起動し、リソースサーバー上の保護されたリソースへアクセスしようとします。

3. リソースサーバーは、アクセストークンが期限切れであるため無効であることを示すエラーコードで応答します。

4. クライアントは、新しいアクセストークンを取得するために、リフレッシュトークンを認可サーバーへ提示します（RFC6749 の section 6）。

5. 認可サーバーは、ユーザーからの OTP が必要であることを示すエラーコードと、auth_session を返します。

6. クライアントはユーザーに OTP の入力を促します。

7. クライアントは OTP と auth_session を、認可チャレンジ・リクエスト（Section 5.1）として認可チャレンジ・エンドポイント（Section 4.1）へ送信します。

8. 認可サーバーは auth_session と OTP を検証し、認可コードを返します。

9. クライアントは、認可コードをトークン・リクエスト（Section 6）としてトークン・エンドポイントへ送信します。

10. 認可サーバーは認可コードを検証し、要求されたトークンを発行します。

11. クライアントは、保護されたリソースへアクセスするために、新しいアクセストークンをリソースサーバーへ提示します。

A.7. Step-up Authentication using Confirmation SMS

クライアントは、ユーザーが OTP で認証した後に、以前アクセストークンおよびリフレッシュトークンを取得していました。ユーザーが保護されたリソースへアクセスしようとすると、リソースサーバーは追加の認証レベルが必要であると判断し、ステップアップ認証をトリガします。ステップアップ認証の仕様で定義される acr_values と max_age を使用して、望ましい認証レベルを示します。クライアントは、acr_values と max_age パラメータを示して認可サーバーへ認可リクエストを開始します。認可サーバーは、acr_values と max_age の値が満たされるまで追加認証を促すエラーメッセージで応答し、その後、新しいアクセストークンおよびリフレッシュトークンを発行します。

1. クライアントは、ユーザー認証を含む認可コード付与フロー（Authorization Code Grant Flow）の完了に続いて、短命なアクセストークンと長命なリフレッシュトークンを持っています。

2. クライアントがアクセストークンをリソースサーバーへ提示すると、リソースサーバーは、ユーザーがアクセスしたいリソースを踏まえるとアクセストークン内の acr クレームが不十分であると判断し、insufficient_user_authentication エラーコードとともに、望ましい acr_values と望ましい max_age を返します。

3. クライアントは、auth_session、acr_values、および max_age パラメータを含めて、認可チャレンジ・リクエスト（Section 5.1）を認可チャレンジ・エンドポイント（Section 4.1）へ送信します。

4. 認可サーバーは auth_session を検証し、acr_values に基づいて満たすべき認証方法を判定し、"error": "insufficient_authorization" と OTP を入力しなければならないことを示すカスタムプロパティを含むエラーレスポンス（Section 5.2.2）で応答します。

5. クライアントはユーザーに OTP を求め、ユーザーは取得して入力します。

6. クライアントは auth_session と OTP を含めて、認可チャレンジ・リクエストを認可チャレンジ・エンドポイントへ送信します。

7. 認可サーバーは OTP を検証し、認可コードを返します。

8. クライアントは、認可コードをトークン・リクエスト（Section 6）としてトークン・エンドポイントへ送信します。

9. 認可サーバーは認可コードを検証し、更新された acr 値を持つアクセストークンとともにリフレッシュトークンを発行します。

10. クライアントはアクセストークンをリソースサーバーへ提示し、リソースサーバーは acr 値が要件を満たすことを検証した上で、保護されたリソースへのアクセスを許可します。

A.8. Registration

この例は、このドラフトで定義されるメカニズムを使用して、メールアドレスから始まる完全なユーザー登録フローを作成する方法を説明します。この例では、認可サーバーのポリシーは、これらのチャレンジが、これまで認識されていなかったメールおよび電話番号へ送信されることを許可し、ユーザーアカウントをその場で作成することです。

1. クライアントはユーザーからユーザー名を収集します。

2. クライアントは、ユーザー名を含めて、認可チャレンジ・リクエスト（Section 5.1）を認可チャレンジ・エンドポイント（Section 4.1）へ送信します。

3. 認可サーバーは、"error": "insufficient_authorization"、"auth_session"、およびメールアドレスを収集しなければならないことを示すカスタムプロパティを含むエラーレスポンス（Section 5.2.2）を返します。

4. クライアントはユーザーから電子メールアドレスを収集します。

5. クライアントは、auth_session パラメータとともに、2 回目の認可チャレンジ・リクエストの一部として、電子メールアドレスを認可チャレンジ・エンドポイントへ送信します。

6. 認可サーバーは電子メールアドレスへ検証コードを送信し、"error": "insufficient_authorization"、"auth_session"、および電子メール検証コードを入力しなければならないことを示すカスタムプロパティを含むエラーレスポンスを返します。

7. クライアントは、ユーザーが電子メール検証コードをクライアントへコピーするよう案内するユーザー体験を提示します。電子メール検証コードが入力されると、クライアントは、電子メール検証コードに加えて、直前のエラーレスポンスで返された auth_session パラメータを含めて、認可チャレンジ・リクエストを認可チャレンジ・エンドポイントへ送信します。

8. 認可サーバーは auth_session を用いてセッション・コンテキストを維持し、電子メール検証コードを検証します。さらに、アカウント回復の目的で電話番号も必要であると判断し、"error": "insufficient_authorization"、"auth_session"、および電話番号を収集しなければならないことを示すカスタムプロパティを含むエラーレスポンスを返します。

9. クライアントはユーザーから携帯電話番号を収集します。

10. クライアントは、auth_session とともに、電話番号を認可チャレンジ・リクエストとして認可チャレンジ・エンドポイントへ送信します。

11. 認可サーバーは auth_session パラメータを用いて以前のリクエストを関連付けます。電話番号へ確認コードを送信し、"error": "insufficient_authorization"、"auth_session"、および SMS 確認コードを入力しなければならないことを示すカスタムプロパティを含むエラーレスポンスを返します。

12. クライアントは、ユーザーが SMS 確認コードを入力するよう案内するユーザー体験を提示します。SMS 検証コードが入力されると、クライアントは、確認コードに加えて、直前のエラーレスポンスで返された auth_session パラメータを含めて、認可チャレンジ・リクエストを認可チャレンジ・エンドポイントへ送信します。

13. 認可サーバーは auth_session を用いてセッション・コンテキストを維持し、SMS 検証コードを検証した上で、クライアントへ認可コードを発行します。

14. クライアントは、認可コードをトークン・リクエスト（Section 6）としてトークン・エンドポイントへ送信します。

15. 認可サーバーは認可コードを検証し、要求されたトークンを発行します。

Appendix B. Example Implementations

この仕様を成功裏に実装するために、認可サーバーは、クライアントが認可チャレンジ・リクエスト（Section 5.1）で送信することが期待される値についての独自の具体的要件に加え、認可チャレンジ・レスポンス（Section 5.2）における独自の具体的エラーコードを定義する必要があります。

以下は、ユーザー名と OTP でユーザーがログインできるようにする完全な実装に必要なパラメータの例です。

B.1. Authorization Challenge Request Parameters

Section 5.1 で定義されるリクエストパラメータに加えて、認可サーバーは以下の追加パラメータを定義します。

"username":

初回の Authorization Challenge Request に REQUIRED です。

"otp":

ユーザーから収集した OTP。下で定義される otp_required エラーに応答して Authorization Challenge Request を再試行する際に REQUIRED です。

B.2. Authorization Challenge Response Parameters

Section 5.2 で定義されるレスポンスパラメータに加えて、認可サーバーは、以下の error レスポンスのための追加値を定義します。

"otp_required":

クライアントはユーザーから OTP を収集し、2 回目のリクエストで OTP を認可チャレンジ・エンドポイントへ送信するべきです。 このエラー値で使用する HTTP レスポンスコードは 401 Unauthorized です。

B.3. Example Sequence

クライアントはユーザーにユーザー名の入力を促し、初回の Authorization Challenge Request にユーザー名を含めて送信します。

[B.3.] Example Sequence

クライアントはユーザーにユーザー名の入力を促し、そのユーザー名を初回の Authorization Challenge Request に含めて送信する。

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

username=alice&scope=photos&client_id=bb16c14c73415

Authorization Server は、OTP が必要であることを示すエラーレスポンスを送信する。

HTTP/1.1 401 Unauthorized
Content-Type: application/json
Cache-Control: no-store

{ "error": "otp_required", "auth_session": "ce6772f5e07bc8361572f" }

クライアントはユーザーに OTP の入力を促し、新しい Authorization Challenge Request を送信する。

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

auth_session=ce6772f5e07bc8361572f&otp=555121

Authorization Server は、期待されるユーザーを特定するために auth_session を検証し、その後そのユーザーの OTP を検証し、認可コードで応答する。

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{ "authorization_code": "uY29tL2F1dGhlbnRpY" }

クライアントは認可コードを token endpoint に送信する。

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

grant_type=authorization_code&client_id=bb16c14c73415&code=uY29tL2F1dGhlbnRpY

Authorization Server は access token と refresh token で応答する。

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{ "token_type": "Bearer", "expires_in": 3600, "access_token": "d41c0692f1187fd9b326c63d", "refresh_token": "e090366ac1c448b8aed84cbc07" }

[Appendix C.] Design Goals

この仕様は、クライアントが認可グラントを取得するために使用できる新しい認可フローを定義する。この仕様をこのように設計した主な理由は 2 つある。

これにより、既存の OAuth 実装は、token endpoint を新しいロジックで拡張する必要がなく、既存コードに対する変更をより少なくできる。代わりに、新しいロジックは完全に新しい endpoint にカプセル化でき、その出力は認可コードであり、既存の token endpoint で access token と引き換えることができる。

これはまた、リダイレクトベースの認可コードフローの既存アーキテクチャをより忠実に反映している。認可コードフローでは、クライアントはまずブラウザを authorization endpoint にリダイレクトすることでリクエストを開始し、その時点で authorization server は、適切な方法でユーザーを認証するための独自のカスタムロジックを引き継ぎ、実際のユーザー認証プロセスのために他の endpoint とやり取りすることもある。その後、authorization server はユーザーをクライアントアプリケーションにリダイレクトして戻し、クエリ文字列に認可コードを含める。この仕様は、クライアントがまず Authorization Challenge Endpoint に POST リクエストを行い、その時点で authorization server がユーザーを認証するための独自のカスタムロジックを提供し、最終的に認可コードを返すことで、既存のアプローチを踏襲している。

別の設計として、WebAuthn や OTP などの異なる認証要素に対して新しいカスタム grant type を定義することも考えられる。この設計の欠点は、概念的にこれらの認証方法が OAuth grant に対応しないことである。言い換えると、OAuth の authorization grant は、ユーザーがあるデータへのアクセスを認可する意図を捉えるものであり、その認可は認可コードによって表され、ユーザーを認証する異なる方法によって表されるのではない。

別の代替案として、Authorization Challenge Endpoint がユーザーの認証に成功した際に access token を返すようにすることも考えられる。これは意図的に採用されなかった。なぜなら、トークンが返される新しい endpoint を追加することになるからである。ほとんどのデプロイメントでは、Token Endpoint は実際にトークンを発行する唯一の endpoint であり、トークンバインディングやレート制限などに関するすべての実装ロジックを含む。同様のロジックと保護を備える必要があるトークン発行 endpoint を新たに定義するのではなく、新しい endpoint は認可コードのみを発行し、それを既存の Token Endpoint でトークンと交換できるようにする。これはリダイレクトベースの Authorization Code Flow と同様である。

これらの設計上の意思決定により、authorization server の実装は、この仕様をサポートするために必要な変更を分離し、カプセル化できるはずである。

[Appendix D.] Document History

-02

• 所属と謝辞を更新
• 編集上の明確化
• Attestation-Based Client Authentication への参照を追加

-01

• 「ユーザーの再認可（re-authorization of the user）」を「ユーザーの再認証（re-authentication of the user）」に修正

-00

• OAuth WG に採択、以前の個人ドラフトから変更なし

Acknowledgments

著者らは、これが議論された OAuth Security Workshop 2023 セッションの参加者、および最終仕様を形作り整えることに寄与した以下の個人のアイデア、フィードバック、文言に感謝する。

Alejo Fernandez、Brian Campbell、Dean Saxe、Dick Hardt、Dmitry Telegin、Janak Amarasena、Jeff Corrigan、John Bradley、Justin Richer、Mike Jones、Orie Steele、Tim Cappalli、Tobias Looker、Yaron Sheffer。

Authors' Addresses

項目	内容
氏名	Aaron Parecki
所属	Okta
Email	aaron@parecki.com
氏名	George Fletcher
所属	Capital One Financial
Email	george.fletcher@capitalone.com
氏名	Pieter Kasselman
所属	Defakto Security
Email	pieter@defakto.security