RFC 8252 says OAuth requests from native apps should only go through external user agents, mainly the user's browser. An embedded web view lets the host app capture usernames, passwords and session cookies, and gives users no address bar to check. The browser also keeps the user's existing sign in.
The two options
A native app can show the authorization page in two ways:
- Embedded user agent: a web view inside the app. The app shares the page's security domain and can access cookie storage and inspect or change page content.
- External user agent: the device's browser, or an in app browser tab, which the RFC defines as a programmatic instance of the browser shown inside the host app that keeps the full security properties and authentication state of the browser. The app gets control back through a redirect.
RFC 8252 is IETF guidance that calls for external user agents for OAuth in native apps.
Why embedded web views are risky
The RFC lists the drawbacks:
- The host app can copy credentials and cookies. It can inject script, read form fields to capture usernames and passwords, auto submit forms to bypass user consent, and copy session cookies to act as the user.
- It breaks least privilege. Even when the app and the authorization server belong to the same company, the app gets more powerful credentials than it needs.
- Users cannot verify the page. There is no address bar or visible certificate checks, so they cannot tell whether they are on the real site, and the habit of typing credentials into such windows is harmful.
- No shared sign in. An embedded view does not share the authentication state with the browser or other apps, so users sign in again every time, which the RFC describes as inferior user experience.
Native apps using the system browser, by contrast, can take advantage of the user's existing sign in, including a passkey or password manager that is already set up.
How to implement it
- Use the authorization code flow with PKCE. Native apps are public clients.
- Open the authorization URL in the system browser or a platform provided secure browser session.
- Register a redirect URI the operating system routes back to your app. RFC 8252 describes private use schemes, claimed https links and loopback redirects as options.
- On return, validate the state value and exchange the code with the verifier.
- Store tokens in the platform's secure storage, such as the keychain or keystore.
- Never read or intercept the browser's page content.
Redirect choices
| Option | Notes |
|---|---|
| Claimed https link | The RFC says native apps should use it over the other options where possible |
| Private use URI scheme | Works widely, but another app might register the same scheme |
| Loopback address | Common for desktop and command line tools |
The RFC discusses each in detail. Use a claimed https link where your platforms support it, and rely on PKCE to protect the code if a redirect is intercepted.
For authorization server owners
Do not treat the embedded view as a trusted channel. Some servers block sign in from web views. If you support third party native apps, publish clear guidance that they should use the browser.
Quick check
Is an embedded web view acceptable if I own both the app and the server?
The RFC says even trusted first party apps break least privilege by using an embedded view, because the app gets access to more powerful credentials than it needs.
Do native apps need a client secret?
No. RFC 6749 assumes secrets inside native apps can be extracted. Use PKCE instead.
Safeguard's SBOM and dependency scanning shows which OAuth and sign in libraries your mobile and desktop apps ship. There is a free scan.
Sources
Last reviewed: 19 October 2026.
