OAuth for First-Party Apps: Native Sign-In Without Redirects, Done Safely

Product teams want native sign-in screens in their own mobile apps, and until now the only standard way to get one, the resource owner password grant, is a pattern that current OAuth security guidance says must no longer be used. The IETF OAuth working group's draft "OAuth 2.0 for First-Party Applications" fills that gap with an Authorization Challenge Endpoint that lets a trusted first-party app collect credentials and second factors itself, while the authorisation server keeps control and can push the user to a browser at any moment. This guide explains how the protocol works, what it costs in phishing exposure, credential stuffing and client trust, and how to decide whether to adopt it. It is for identity architects, mobile developers and authorisation server owners. It assumes you know the browser redirect model in the OAuth for Native and Mobile Apps Guide, which remains the default.

Source note: protocol details below are summarised from draft-ietf-oauth-first-party-apps-04 and the OWASP, NIST and MITRE sources listed in the references, as checked in November 2026. The draft can still change. Confirm against the official text before relying on it.

Key takeaways

• It is a draft, not yet an RFC. As checked on 12 November 2026, draft-ietf-oauth-first-party-apps-04 (1 July 2026) is an OAuth working group document in the "Waiting for Write-Up" state with an intended status of Standards Track. Details can still change.
• First-party only. The authorisation server must verify that the client is first-party before continuing. A third-party app collecting your users' passwords is exactly what OAuth exists to prevent.
• The browser is still the fallback. The server can answer any request with redirect_to_web, and should do so for risky sign-ins, unsupported methods and account recovery.
• Bind everything to a key. The draft recommends DPoP: the same key must be used across challenge requests and the token request, and the auth_session should be tied to it so a captured session cannot be replayed elsewhere.
• You take on the login page's defences. A credential-accepting API endpoint needs rate limiting per auth_session, anti-automation and client attestation, because it no longer sits behind your hardened web login.

Why first-party native sign-in needed a new protocol

RFC 8252 tells native apps to send users to the system browser for the authorisation request. That keeps credentials away from the app and lets the identity provider run phishing-resistant methods, but it also breaks the visual flow of a branded mobile app. Many organisations responded by embedding WebViews or by using the resource owner password credentials grant, which gives the app the password and gives the server no room to add a second step. OWASP ASVS 5.0 requirement V10.4.4 notes that the password grant must no longer be used, and the OAuth 2.0 Security Best Current Practice (RFC 9700) Guide explains why.

The first-party apps draft keeps the authorisation code model but moves the interaction from the browser to an API. The app collects input, posts it to the authorisation server, and receives either an authorisation code, a request for more input, or an instruction to switch to the browser. The authorisation server still decides which methods are acceptable and when.

How the Authorization Challenge Endpoint works

The authorisation server publishes the endpoint in its metadata as authorization_challenge_endpoint. The client sends form-encoded HTTPS POST requests to it.

1. Initial request. The app posts response_type=code (required), its client_id, an optional scope and, ideally, a PKCE code_challenge and code_challenge_method, along with whatever the server asks for first, such as a username.
2. Challenge or code. If more is needed, the server replies HTTP 403 with error=insufficient_authorization and an auth_session value. The app collects the next input (password, one-time code, passkey assertion) and posts again with the auth_session. The format of intermediate steps is left to the server and may use other endpoints.
3. Browser switch. At any point the server can reply HTTP 403 with error=redirect_to_web. If the original request carried a PKCE challenge, the server may include a request_uri so the app can continue in the browser without starting over.
4. Success. The server replies HTTP 200 with an authorization_code.
5. Token exchange. The app redeems the code at the token endpoint under normal RFC 6749 rules, with the PKCE verifier and no redirect_uri. The token response may include a new auth_session.

The token endpoint can also answer with insufficient_authorization instead of tokens, including on a refresh token request, so the server can require re-authentication when a refresh looks risky. A resource server can return a step-up challenge as defined in RFC 9470, and the app then starts a new first-party request carrying the requested acr_values and max_age. See the OAuth Step-Up Authentication Challenge Guide.

Error and state values

The draft treats auth_session like a cookie: it should carry at least 256 bits of entropy, be bound to the device, and clients must not depend on any particular lifetime.

Two practical consequences follow. First, the app should read the endpoint from server metadata rather than hard-coding it, so the identity team can move or disable it without an app release. Second, because the intermediate steps are server-defined, the app must handle unknown challenge types by falling back to the browser instead of failing the sign-in, which keeps old app versions working when the server adds a new method.

What it costs you: the security trade-offs

The draft's own security considerations are candid. Adopting it moves risk from the browser to your API and your app.

For attestation patterns see the OAuth Attestation-Based Client Authentication Guide, and for key binding the DPoP Guide.

Decision guidance: when to adopt it

• Stay with the browser redirect if you have third-party clients, if your sign-in already uses passkeys smoothly through the system browser, or if you cannot implement attestation and DPoP. The redirect model keeps credentials out of the app and is a finished standard.
• Consider the first-party flow for a large consumer app where redirect drop-off is measurable, where all clients are your own and attested, and where your authorisation server already supports DPoP, risk scoring and rate limiting per session.
• Replace the password grant as a priority. If an app uses the resource owner password grant today, the first-party flow gives the server back control over methods and step-up while keeping a native screen.
• Small organisations: rely on your identity provider. Only adopt this when your provider supports the endpoint and attestation out of the box; building it yourself means building a login security stack.
• Limited-input devices: the draft points to the device authorisation grant (RFC 8628) instead, with its own cross-device phishing considerations.

Implementing it safely: a phased approach

1. Confirm eligibility. List every client that would use the endpoint and confirm each is owned and released by you. Mark them first-party in the authorisation server and refuse the endpoint to every other client.
2. Put trust and binding in place first. Turn on client attestation for the mobile apps and require DPoP on challenge and token requests, with the server checking the same key across all steps.
3. Design the server policy. Decide which methods the app may collect natively (for example username, passkey assertion, one-time code) and which always trigger redirect_to_web (account recovery, new device enrolment, high-risk scores, admin roles).
4. Build the client once. Ship one SDK used by every first-party app so the screens and behaviour are identical, which helps users spot fakes. Always implement the browser fallback with PKCE so request_uri continuation works.
5. Pilot behind a flag. Release to internal users, then a small percentage of customers. Compare sign-in success, abandonment, failure ratios and fraud signals with the redirect cohort.
6. Roll back cleanly. Rollback is a server switch: return redirect_to_web for every request, and the apps fall back to the browser without a new release.
7. Track the draft. Watch the working group for changes before final publication and plan a review once it becomes an RFC.

Where identity fits: the app is now part of your credential boundary

With the browser flow, the app's identity mattered at the token endpoint. With the first-party flow, it matters at every step because the app sees credentials. Treat each first-party app as a privileged client: register it explicitly, sign and attest releases, keep signing keys in a protected pipeline, and revoke trust in old app versions when they no longer meet policy. Refresh tokens issued to the app should be sender-constrained, as ASVS V10.4.5 recommends for public clients. See the OAuth Client Registration Checklist.

Detection and measurement

Log every challenge request with client_id, attestation result, DPoP key thumbprint, auth_session identifier (hashed), method attempted and outcome. Watch for:

• Requests to the endpoint from clients not marked first-party, or failing attestation.
• One auth_session presented with more than one DPoP key, or from widely separated networks.
• High failure ratios per account, per IP range or per client version, which suggest stuffing.
• Spikes in redirect_to_web for a single app version, which may show a broken or tampered build.
• Refresh requests answered with insufficient_authorization that never complete.

Framework mapping

Common failure patterns

• Opening the endpoint to every client. Without a first-party check and attestation, a cloned app or script can drive the full sign-in.
• Passwords only, natively. Teams build the password screen and never the passkey or browser fallback, so the server cannot raise assurance.
• Unbound auth_session. A session value without a DPoP key binding can be lifted from logs or a proxy and replayed.
• No rate limits. The endpoint becomes a faster credential stuffing target than the web login, which has years of bot defences.
• Recovery inside the app. Account recovery and new device enrolment handled natively, where they should always go to the browser.
• Treating the draft as final. Shipping without a plan to revisit when the RFC is published.

Practitioner checklist

• Retire any use of the resource owner password grant.
• Limit the Authorization Challenge Endpoint to registered first-party clients.
• Require app attestation for every client that uses the endpoint.
• Require PKCE on the initial request so browser continuation works.
• Require DPoP and enforce the same key across challenges and the token request.
• Rate limit per auth_session, account and network, with anti-automation.
• Send recovery, enrolment and high-risk sign-ins to the browser with redirect_to_web.
• Ship one shared SDK so every first-party app presents the same sign-in.
• Log challenge outcomes and alert on attestation failures and key mismatches.
• Review the implementation when the draft is published as an RFC.

Standards and references

• IETF: OAuth 2.0 for First-Party Applications (draft-ietf-oauth-first-party-apps)
• OWASP: Application Security Verification Standard 5.0
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Credential Stuffing (T1110.004)
• MITRE ATT&CK: Steal Application Access Token (T1528)

Related NHI Mgmt Group resources: OAuth for Native and Mobile Apps Guide · OAuth Attestation-Based Client Authentication Guide · DPoP Guide · OAuth Step-Up Authentication Challenge Guide