要約

  • OAuth for First-Party Applications revision 04は、認可コードを返す、追加のユーザー入力をアプリに求める、ブラウザへ切り替える、という三つの方向を持つHTTPS APIを提案する。リダイレクトを省く代わりに、インストール済みアプリ、publisher証拠、表示面、リスク指示への追従が信頼対象になる。
  • auth_session、PKCE、DPoPはプロトコルの連続性をインスタンスと鍵へ結び付けられる。しかし、binaryが本当に第一者か、利用者が正しいchallengeを見たか、姉妹アプリの安全表示が同じか、必要時にfallbackしたか、外部結果が完了したかは証明しない。

銀行アプリの中でOTPを入力し、アプリがサーバーへ送り、authorization codeを受け取る。ブラウザは開かず、利用者の作業も途切れない。失われたのは画面切替であって、信頼の引き渡しではない。

OAuth 2.0 for First-Party Applications revision 04はAuthorization Challenge Endpointを定義する。login hint、署名済みpasskey challenge、MFA codeなどを受け、十分ならcodeを発行する。不足ならinsufficient_authorizationで継続を要求し、リスクや例外ではredirect_to_webでブラウザへ移す。

これはOAuth WGの活発なInternet-Draftで、2026年7月1日付、2027年1月2日失効、Standards Track予定である。RFCではない。IANA登録完了、実装、相互運用、配備、app-store attestationの網羅、phishing低減、業務結果は立証されていない。

表示権限がアプリへ移る

通常のcode flowでは、authorization serverがcredential入力ページを支配する。新方式では信頼されたnative clientが大部分のceremonyを担い、OAuth parametersとユーザーから得た情報をHTTPS POSTする。Web固有のextension parameterにはnativeで意味がないものもあり、その扱いは範囲外である。

サーバーはcode発行の可否を決め続けるが、promptの見せ方、秘密を読むcomponent、error説明、proprietary intermediate endpointはアプリ側に広がる。中間request format、challenge schema、step sequencingは標準化されず、完全なinteropにはdeployment profileが要る。

従ってreceiptにはHTTP結果だけでなく、app build、installed instance、challenge profile、入力class、scope、policy version、response、next instructionを残す。秘密値は残さない。codeが正しくても、利用者が何を見たかは再現できない。

第一者性は関係であって文字列ではない

草案は継続前にASがclientの“first-partyness”を検証するよう要求する。同じentityがアプリとASをcontrolし、利用者も同じentityのものと理解する必要がある。ただし検証手段は規定しない。

platform/app-store attestation、Attestation-Based Client Authentication、Dynamic Client Registrationは証拠を供給できる。それでもcorporate control、distribution custody、installed binary integrity、key possession、brand recognitionは別の事実である。

正しく署名されたpackageも古い、または侵害され得る。正規アプリも誤解を招くpromptを描ける。DPoP keyもenrollmentの粒度がなければ複製instanceに属し得る。見慣れた画面は模倣できる。

publisher、distribution、attestation issuer、freshness、nonce、policy result、instanceをclient_id、auth_session、codeから分けて保存する。“first-party verified”は依存関係を持つ判断であり、request fieldではない。

auth_sessionはアプリが運ぶcookie型文脈

auth_sessionは同じclient instanceの後続requestを関連付けるopaque valueで、browser cookieに似る。アプリ自身が保存・提示し、responseで新値が来れば更新し、code発行後も保持し、logoutで捨てる。

ASはuniqueにし、randomなら256-bit entropyを推奨する。device bindingを行い、別deviceを拒否すべきである。寿命は規定されず、time、security event、revocationで無効化でき、clientは期間を仮定できない。

監査はgeneration、predecessor、instance、user context、DPoP key、stage、rotation reason、logout、terminal stateを状態機械として残す。opaque value本体をanalyticsへ出してはならない。sessionの受理はcontext継続しか証明せず、過去画面の誠実さや同一人物を証明しない。

DPoPが結ぶのは鍵である

revision 04はchallenge、code、token、resource、auth_sessionをDPoP keyへ結ぶ方法を示す。最初のrequestから同じpublic keyを要求し、session提示時にprivate-key possessionを確認できる。

これは盗まれたsession/codeの別device replayを抑える。しかしkey continuityはapp provenanceではない。誰がkey enrollmentを承認したか、どのpackageが画面を描いたか、instanceが安全か、ASが今も信頼するか、利用者がscopeを望んだかは答えない。

dpop_key_match、app_attestation_accepted、registration_active、first_party_policy_passed、prompt_profile_matched、user_authorization_satisfiedを別々に示す必要がある。

redirect_to_webは安全状態の遷移である

ASはhigh-risk、未対応method、account recovery、exceptionでredirect_to_webを返し、external user agentで新しいcode flowを始めさせる。PAR request_uriを返す場合もある。

initial native requestにPKCE code_challengeがなければ、ASはrequest_uriを返してはならない。browser pathではRFC 8252/RFC 9700のnative-app practiceとRFC 9207のissuer identificationを保つ。

receiptにはtrigger、risk band、PKCE、issuer、request reference、external browser、return URI、state continuity、callback resultを保存する。browserを開いた事実は正しいserver到達を証明せず、native継続もriskが低かったことを証明しない。

redirect_to_webをnative retryへ変換したりembedded webviewで置換したりすればpolicyを越える。server responseからOS browser selection、issuer-bound callbackまで試験すべきだ。

複数アプリは信頼判断を複製する

草案は複数のfirst-party appでnative experienceを同一にするよう要求する。これはbrandingだけでない。合法なcredential入力面が増えるほど、偽画面を説明しにくくなる。実装ごとにparser、storage、accessibility、SDK、failureが増える。

共通SDKは差異を減らすが、共通依存にもなる。version、signature、rollout、emergency withdrawalがcontrol surfaceに入る。“同一”の試験はprompt、origin cue、secret handling、screenshot、accessibility、fallback、error、session storage、telemetry redactionを含める。

ASはclient/attestation policyをentity、publisher、channel、build、SDK、profile、retirementへ対応付ける。弱いsibling appがbrandだけで信頼を継承してはならない。

codeは外部効果ではない

authorization code、PKCE、DPoP、auth_session、step-up、access tokenは異なる座標である。codeはgrant、PKCEはverifier、DPoPはkey、sessionはcontext、step-upは追加認証、tokenはresourceへのauthorizationを担う。

resource serverは拒否・縮小でき、受理後も下流処理が完了しないことがある。利用者が閉じる、paymentがreverseされる、credentialが未installのままになる。OAuth receiptの後にresource decisionとobserved outcomeを別に残す必要がある。