Visual RFC.
ALL RFCs / RFC 8252
Read the RFC ↗
RFC 8252 / NATIVE-APP AUTHORIZATION

Fake browsers and client impersonation

08

A malicious app can mimic a browser or attempt to become the default HTTPS handler.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

DIAGRAM§ 8.7 ↗
RFC 8252 · § 8.7EXAMPLE
3 / 3
Fake browsers and client impersonationA malicious app can mimic a browser or attempt to become the default HTTPS handler. Current state: Authenticate in the intended trusted context..Fake browsers and client impersonationAppprocess boundary○ ○ ○browser-owned viewLogin · cookies · passwordopencode onlypassword remains in browser
03
Authenticate in the intended trusted context.

Keep the credential-handling boundary explicit.

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
KEY POINT

Browser appearance is not browser isolation.

  • An embedded page disguised as an external browser can capture credentials.
  • A malicious default URI handler is a device-wide risk, not only an OAuth issue (§ 8.8).
  • Do not silently reuse prior consent for a public client unless its identity can be assured (§ 8.6).
DETAILS

Browser-only authentication factors and platform app-identity capabilities can help. The RFC does not promise that OS dispatch defeats a compromised device.

Read the RFC section ↗

Diagrams simplify the RFC. Read the linked sections for complete requirements.

Privacy
All chapters in this RFC
  1. Leave login to the browser
  2. A browser round trip, protected by PKCE
  3. Private-use callback schemes
  4. Claimed HTTPS callbacks
  5. Loopback callbacks on desktop
  6. Register the full callback
  7. Bind the response to the app’s request
  8. Fake browsers and client impersonation
  9. Server support and implicit-flow limits
RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗