Browserless OAuth

Browserless OAuth is a way for applications to avoid having to open the browser for an OAuth flow. It describes API-driven approaches for applications to interact directly with the user and forward information to the authorization server. It enables applications to own the user experience for authentication and authorization without compromising security.

This article discusses browserless OAuth for both first- and third-party applications. It reviews the draft specification OAuth for first-party applications, and highlights when it is safe to apply the same or a similar approach to third-party applications.

First, this article starts off with a brief historical background on why browser redirects are important in OAuth. This helps you to understand why the community distinguishes between first-party and third-party applications in the context of browserless OAuth.

The Importance of the Browser for OAuth

The main goal when designing the OAuth specification was to diminish a common bad practice, where users shared their credentials to access resources on websites through third-party applications. Sharing a credential with a third-party application gives that application all the permissions of the user whom the credential belongs to. The user cannot restrict the access for a given application, neither can they revoke such an access. To revoke access, users needed to change their credentials, i.e., password. Sharing passwords with third parties is comparable to a password leak, and an anti-pattern.

User Authentication for Delegated Access

Instead of having to enter credentials in third-party applications to access a service, OAuth allows users to delegate scoped access to such applications with the help of an authorization server. To delegate access, users have to authenticate at the authorization server and grant the application access.

The way users authenticate with the authorization server in OAuth is via the browser. When starting an OAuth flow, the application opens the browser with a link to the authorization server (this is the authorization request). There users enter their credentials (passwords) directly at the authorization server. Looking at the URL users can also verify that they really share their credentials with the authorization server and not a phishing site. This helps avoiding the aforementioned anti-pattern. Users can also confirm for the authorization server ("consent to") that they grant the application certain access ("scope" of access).

When using the browser to run an OAuth flow, users can also benefit from Single Sign On (SSO). The authorization server can automatically authenticate the user based on session cookies that it placed in the browser during previous authentication. Browser redirects are therefore both necessary to secure password-based logins and consent, and practical for SSO.

The authorization request in OAuth is an unauthenticated request. As a result, any application can start an OAuth flow in the name of any (other) application. At that point, the authorization server cannot validate neither the request nor application. Therefore, it needs to be careful when returning the authorization response and granting access.

Secure Delivery of the Authorization Response

The authorization server must ensure that it only ever returns the result of an authorization request to a list of known endpoints (redirect URIs) for a given application. For this the authorization server utilizes browser redirects where the browser forwards the authorization response (which typically includes the authorization grant) to the known redirect URI for an application. This redirect URI is specific for an application - no other application has access to it. If the authorization server received a malicious authorization request, it would at least not leak any response to a malicious application. Consequently, browser redirects play a crucial part in securing OAuth flows.

Side Effect of the Browser Dependency

Opening the browser to point to the authorization server for user interaction is considered best practice for OAuth. For websites, browser redirects are not an issue, because users are already within the browser. For other user applications, this behavior distracts users and draws their attention from the original application to the browser. Users need to manually close the browser window or tab, and navigate back to the application. The practice also prevents applications from owning the user experience during an authentication flow, like notifying the user before a redirect, or simply rendering the interfaces.

Making sure that the correct application receives the redirect can be challenging. Some platform-specific applications, like desktop applications, use local loopback addresses for their redirects that any other application can easily claim and thus impersonate a desktop application. The most effective mitigation for client impersonation are confidential clients, i.e. applications that can securely authenticate. Claimed HTTPS URls and attestations are another security control, primarily used for mobile applications.

With the security controls in place that enable an authorization server to trust an application, you can also trust applications with handling user credentials.

Trusting Applications with Credentials

While OAuth was designed with third-party applications in mind, it found its way into first-party use cases as well. First-party applications change the premises of the browser requirement.

First-Party Applications

A first-party application in the OAuth context is an application that is controlled by the same party that controls the authorization server. That is, they are the same entity.

Since the controller of the application is the same entity as the one controlling the authorization server, entering credentials into the application is effectively the same as furnishing them at the authorization server. This means a first-party application may take over user interaction, and broker information between the user and the authorization server. First-party applications may thus collect user input such as a password.

Users should not enter their credentials in third-party applications as mentioned before. For this reason the browser-based flow is the preferred and recommended way. However, with passwordless authentication methods, users do not have to enter or share any credentials which changes the premises.

Passwordless Authentication

Passwordless authentication methods utilize public-key cryptography. Public-key cryptography means there is a key pair with a private (secret) and a public part. It implies that two parties do not share a secret. Instead one party holds the private key that it keeps secret, and it shares with another party, the server, the public counterpart of that key.

When a user authenticates through an application using passwordless authentication, the application requests (e.g. via the operating system or browser) a tamper-proof, verifiable artifact based on the private key. The server can validate the artifact with the public key. The application never directly accesses the user's private key.

Using passwordless authentication, there is no secret that can leak, and you can be more relaxed on the security. Therefore, with passwordless authentication it is secure to have third-party applications interact with the user directly, collect the necessary credentials (e.g. via the operating system) and forward them to the authorization server, without having to open the browser. What's more, the user experience is the same for first-party and third-party applications as they both need to rely on comparable SDKs to implement the passwordless authentication.

Both first-party and third-party applications may authenticate the user directly and own (part of) the user experience. To facilitate that, the authorization server needs to provide a dedicated API to inform the application what data to collect from the user, how to authenticate or interact with the user.

Eliminating the Browser with API-driven OAuth

The draft specification OAuth for first-party applications (FiPA) is an attempt to provide the corner stones for an API-driven OAuth flow. It defines a new endpoint, the Authorization Challenge Endpoint, and the bare minimum of common requests.

OAuth 2.0 for First-Party Applications (FiPA)

The Authorization Challenge Endpoint provides the API for the application to start an authorization flow, and to keep sending requests until the authorization server is satisfied with the challenge. The flow starts with an authorization challenge request which is a slim version of an authorization request using HTTP POST, and optional client authentication.

The draft specification defines the new error code insufficient_authorization that indicates to the application that the authorization server requires additional information from the user. The details regarding how to interact with the user to collect the necessary information and how to format intermediate requests are out of scope of the draft specification, and are thus proprietary. The Hypermedia Authentication API, for example, uses hypermedia responses to communicate the steps that the authorization server requires from the user and application.

Hypermedia Authentication API (HAAPI)

Curity implemented a Hypermedia Authentication API (HAAPI) to allow applications to interact with users directly. The API includes some advanced security mechanisms for public clients such as attestation and sender-constrained access tokens using DPoP to secure the communication with the authorization server. What's more the API recognizes authentication as a complex workflow and utilizes hypermedia to link the steps that are required to transform from an unauthenticated to an authenticated state. As HAAPI was created before FiPA was introduced, it is not strictly conformant with the draft specification, but serves the same purpose.

The HAAPI responses provide the application with data about the required step, the actions the user can take and links to related resources. Applications can use that data to dynamically render screens where necessary, and in this way guide the user through the authentication and authorization. At the end, the application receives the authorization code which it can redeem for tokens, just like with OAuth for first-party applications.

Browserless OAuth provides UX improvements especially for mobile and desktop applications. However, the approach is also significant for AI agents.

Browserless OAuth for AI Agents

API-driven user interaction, like HAAPI, represents an alternative to browser-based flows for first-party applications. Eliminating the browser is secure in such cases because first-party applications serve as a continuation of the authorization server. When working with AI agents, consider browserless OAuth if you can check the following boxes:

• You control the AI agent.
• You are confident, the AI agent can handle possibly sensitive user input.
• Users are aware of the first-party nature of the AI agent regarding your authorization server.

Browserless OAuth allows the AI agent to own the user experience and fulfill authentication or authorization challenges using built-in features without having to open the browser.

User Consent

Authentication is an important part of the user interaction with an authorization server but it is not the only one. User consent is another crucial concept in OAuth that allows users to confirm for the authorization server that they grant access to a given application.

In a first-party scenario, user consent as part of an OAuth flow is irrelevant because the application belongs to the same entity as the authorization server. The user already consented to the terms of use when signing up or downloading the application.

With AI agents that are third-party applications the authorization server should require the user to explicitly grant access ("user consent"). While such AI agents may collect data to authenticate users via passwordless authentication methods, they must not forward consent from the user unless the user can sign their consent. The authorization server must only trust data from AI agents that it can verify. That is especially true for sensitive data like consent.

Establish Trust

Before an authorization server can trust an AI agent to interact with the user in a secure manner, it needs to identify the AI agent and determine to what degree it can trust it. AI agents that can authenticate ("confidential clients" in OAuth), for example, are more trustworthy than those that can't ("public clients").

Some AI agents may have a pre-established trust and may have pre-registered with the authorization server. Some AI agents need to dynamically establish the trust. How an AI agent registers and authenticates, whether it is a first-party or third-party application impacts how trustworthy it is.

In the end, the authorization server remains responsible for establishing the trust and for challenging an authorization request. It may adapt its flow and API responses based on its policies and a risk profile. For example, it may enforce passwordless authentications for certain AI agents, demand additional factors, or require an AI agent to open a browser after all.

Summary

Browserless OAuth is API-driven OAuth where the application interacts with the user directly during an OAuth flow according to instructions it receives from the authorization server. It is suitable for first-party applications, and in certain cases even for third-party applications.

Browserless OAuth allows AI agents to provide built-in user experience for parts of an OAuth flow that traditionally the authorization server would provide. Combined with passwordless authentication and signed or out-of-band consent, browserless OAuth enables even third-party applications to deliver built-in user experience without compromising security and best practices.

Even with API-driven authentication, the authorization server remains responsible for presenting the challenges regarding authentication and authorization, and the AI agent is responsible for following the directives in the API responses. If designed carefully, browserless OAuth is a win-win situation where the authorization server can enforce its policies and the AI agent can own the user experience.

Published: 2026-02-17

Judith Kahrer

Product Marketing Engineer at Curity

Join our Newsletter

Get the latest on identity management, API Security and authentication straight to your inbox.

Email

Subscribe

I agree to Curity's Privacy Policy

Start Free Trial

Try the Curity Identity Server for Free. Get up and running in 10 minutes.

Start Free Trial