]> Raiffeisen Bank International

yaron.zehavi@rbinternational.com

Security Web Authorization Protocol native-apps oauth app2app browserless This document describes a protocol connecting 2 native apps via the OAuth pattern, to achieve native user navigation (no web browser required), regardless of any number of OAuth brokers federating the request across trust domains. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This document, OAuth 2.0 App2App Browserless Flow (Native App2App), presents a protocol enabling native OAuth browser-less navigation across apps. It addresses the challenges presented when using a web browser to navigate through one or more Brokering Authorization Servers:

• Such OAuth Brokers are required when Client App is not an OAuth client of the User-Interacting Authorization Server and so they federate the flow across trust domains.
• Since no app owns OAuth Brokers' urls, App2App flows involving brokers require a web browser, which degrades the user experience.

This document specifies:

• A new parameter to the authorization endpoint: native_callback_uri.
• A new scope value: app2app.
• A new error_description value: native_callback_uri_not_claimed.

Difference from OpenID.Native-SSO also offers a native SSO flow across apps. However, it is limited to apps:

• Published by the same issuer, therefore can securely share information.
• Using the same Authorization Server.

Terminology In addition to the terms defined in referenced specifications, this document uses the following terms:

"OAuth":

In this document, "OAuth" refers to OAuth 2.0, and as well as , both in their authorization code flow.

"PKCE":

Proof Key for Code Exchange (PKCE) , a mechanism to prevent various attacks on OAuth authorization codes.

"OAuth Broker":

A component acting as an Authorization Server for its clients, as well as an OAuth Client towards Downstream Authorization Servers. Brokers are used to facilitate a trust relationship when there is no direct relation between an OAuth Client and the final Authorization Server where end-user authenticates and authorizes. This pattern is in current use to establish trust in federation use cases in Academia and in the business world, across corporations. Note: It is possible OAuth Brokers will be superseded in the future by , offering dynamic trust establishment.

"Client App":

A Native app implementing "OAuth 2.0 for Native Apps" as an OAuth client of Initial Authorization Server. Client's redirect_uri is claimed by the app.

"Initial Authorization Server":

The Authorization Server of Client App which acts as an OAuth Broker as an OAuth client of a Downstream Authorization Server.

"Downstream Authorization Server":

An Authorization Server which may be an OAuth Broker or a User-Interacting Authorization Server.

"User-Interacting Authorization Server":

An Authorization Server which interacts with end-user. The interaction may be interim navigation (e.g: user input guides where to redirect), or user authentication and request authorization.

"User-Interacting App":

Native App of User-Interacting Authorization Server.

"Deep Link":

A url claimed by a native application.

"Native Callback uri":

Client App's redirect_uri, claimed as a deep link. This deep link is invoked by User-Interacting App to natively return to Client App.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Challenge of App2App with OAuth Brokers

App2App with OAuth Brokers requires a web browser

App2App with brokers and browser (redirects back to Client not depicted) | Initial |------>| Authorization|------>| Authenticating | | | | Authorization| | Broker | Auth. | Servers | Auth. | Authorization | | | | Request | +---------+ Req. +--------------+ Req. | Server | | | | | +---------+----------+ | | | +----------------------------------------------------|-------------+ | | +--------------+ | | | | User- | | | | |Authenticating|<--------------------------------------------------+ | | | App | Deep Link | | +--------------+ | +------------------------------------------------------------------------------------+ Mobile Device ]]>

Since no native app claims OAuth Brokers' urls, OAuth requests and redirect_uri responses to and from OAuth Brokers are handled by a web browser as the User Agent.

Impact of using a web browser Using a web browser may degrade the user experience in several ways:

• Some browser's support for deep links is limited by design, or by the settings used.
• The browser may prompt end-user for consent before opening deep links, introducing additional friction.
• Browser's loading of urls and redirecting may be noticeable by end-user, rendering the UX less smooth.
• App developers cannot control which browser will handle the response redirect_uri. This poses a risk that necessary cookies used to bind session identifiers to the user agent (nonce, state or PKCE verifier) will be unavailable, which may break the flow.
• After the flow is complete, "orphan" browser tabs might remain. While they do not directly impact the flow, they can be regarded as unnecessary "clutter".

App2Web with brokers

App2Web with brokers (redirects back to Client not depicted) | Initial |------>| Authorization|------>| Authenticating | | | | Authorization| | Broker | Auth. | Servers | Auth. | Authorization | | | | Request | +---------+ Req. +--------------+ Req. | Server | | | | | +-+----------------+-+ | | | | | User- | | | | | | Authenticating | | | | | | Web UI | | | | | +----------------+ | | | +------------------------------------------------------------------+ | +------------------------------------------------------------------------------------+ Mobile Device ]]>

End-user's device may not have an app claiming User-Interacting Authorization Server's urls, when:

• User-Interacting Authorization Server offers no native app.
• Or such an app is offered, but is not installed on the end-user's device.

In such case interacting with User-Interacting Authorization Server's MUST use the browser as user agent. This is similar to the flow described in "OAuth 2.0 for Native Apps" , and referred to in as App2Web, and is therefore not discussed further in this document.

Browser-less App2App with OAuth Brokers

Flow Diagram

Browser-less App2App with Brokers | Initial | | | | | Authorization | | | +--------------+ (1) | Server | | | | Client |------------->| | | | | App |<-------------| (OAuth Broker)| | | | | (2) +---------------+ | | +--------------+ | | ^ | ^ ^ | | | | | | (3) +---------------+ | | | | | +---------------->| | | | | | +------------------>| Downstream | | | | | (7) | Authorization | | | | | | Servers | | | | | | | | |(6)| |(4) +---------------+ | | | v | | +----------------+ +---------------+ | | | | | User- | | | | User- |<---------->| Authenticating| | | | Authenticating | (5) | Authorization | | | | App | | Server | | | +----------------+ +---------------+ | +--------------------------------------------------+ Mobile Device ]]>

• (1) Client App presents an authorization request to Initial Authorization Server, indicating app2app flow using new scope value app2app.
• (2) Initial Authorization Server returns an authorization request for Downstream Authorization Server, including Client App's redirect_uri as native_callback_uri.
• (3) Client App checks if the returned authorization request url is claimed by an app on the device and if so proceeds to the next step. Otherwise it loops through Downstream Authorization Servers, calling their authorization endpoints and processing their HTTP 3xx redirect responses, until a url claimed by an app on the device is reached.
• (4) Client App natively invokes User-Interacting App.
• (5) User-Interacting App authenticates user and authorizes the request.
• (6) User-Interacting App natively invokes native_callback_uri (overriding the request's redirect_uri), providing as a parameter the redirect_uri with its response parameters.
• (7) Client App loops through Authorization Servers in reverse order, starting from the redirect_uri it received from the User-Interacting App. It calls the first redirect_uri and any subsequent uri obtained as 3xx redirect directive, until it obtains a location header indicating its own redirect_uri.
• (8) Client App exchanges code for tokens and the flow is complete.

New Parameters and Values The protocol described in this document requires User-Interacting App to natively navigate end-user back to Client App, for which it requires Client App's native_callback_uri. Therefore this document defines new parameters and values.

"app2app":

New scope value, used by Client App to request an app2app flow from Initial Authorization Server.

Initial Authorization Server, processing an app2app flow according to this document, MUST provide Client App's redirect_uri as Native Callback uri to Downstream Authorization Server using one of the following options:

"native_callback_uri":

OPTIONAL. New authorization endpoint request parameter. When native_callback_uri is provided, structured scope app2app:native_callback_uri MUST NOT be provided.

"app2app:{native_callback_uri}":

OPTIONAL. New structured scope value including the app2app flag as well as the Client's native_callback_uri, separated by a colon. When structured scope app2app:{native_callback_uri} is provided, native_callback_uri MUST NOT be provided.

native_callback_uri accepts the following query parameter when invoked by User-Interacting Authorization Server's App:

"redirect_uri":

url-encoded OAuth redirect_uri with its response parameters.

Downstream Authorization Server, processing an app2app flow according to this document:

• MUST retain the native_callback_uri in downstream authorization requests created.
• MAY validate native_callback_uri.

Note: A simplification is considered, to replace these options and the validation logic by Initial Authorization Server, by having Client App provide the native_callback_uri through a rich authorization details type, which is expected to be passed on by Downstream Authorization Servers:

Validation of native_callback_uri Validation of native_callback_uri by User-Interacting Authorization Server and its App is RECOMMENDED, to mitiagte open redirection attacks. A validating Authorization Server MAY use various mechanisms outside the scope of this document. For example, validation using is possible:

• Strip url path from native_callback_uri (retaining the DNS domain).
• Add the url path /.well-known/openid-federation and perform trust chain resolution.
• Inspect Client's metadata for redirect_uri's and validate native_callback_uri is included.

Protocol Flow

Client App calls Initial Authorization Server Client App calls Initial Authorization Server's authorization_endpoint to initiate an authorization code flow and indicates App2App flow using the scope: app2app.

Initial Authorization Server returns authorization request to Downstream Authorization Server Initial Authorization Server SHALL process Client's request and return an HTTP 3xx response with a Location header containing an authorization request url towards Downstream Authorization Server's authorization_endpoint. The request SHALL include Client's redirect_uri as native_callback_uri in one of the methods specified in this document.

Client App invokes app of User-Interacting Authorization Server Client App SHALL use OS mechanisms to attempt to locate an app installed on the device claiming the authorization request url. If such app is found, Client App SHALL natively invoke the app claiming the url to process the authorization request. This achieves the desired native navigation across applications. If a suitable app is not found, Client App SHALL use HTTP to call the authorization request url and process the response:

• If the response code is HTTP 2xx, Client App cannot accomplish the browser-less flow and MUST fallback to using the browser. The reason is that it reached a User-Interacting Authorization Server, perhaps aiming to authenticate the user and authorize the request, or prompt the user for a routing decision or perhaps to redirect through HTTP Form-Post or Javascript. All of these are not compliant with the browser-less flow.
• If the response is a redirect instruction (HTTP Code 3xx + Location header), Client App SHALL repeat the logic previously described:
  • Check if an app claims the url in the Location header, and if so natively invoke it.
  • Otherwise use HTTP to call the url and analyze the response.
• Client App SHALL handle error responses (HTTP 4xx / 5xx), for example display the error.

As the Client App traverses through Brokers, it SHALL maintain a list of all the DNS domains it traverses, to be used as Allowlist for response handling traversal. As Authorization Servers MAY use Cookies to bind security elements (state, nonce, PKCE) to the user agent, causing the flow to break if said cookies are not present in subsequent HTTP requests, Client App MUST act as a browser would:

• Store Cookies it obtains in HTTP responses.
• Send Cookies in subsequent HTTP requests.

Fallback to using the browser If Client App obtains an HTTP 2xx response, a new flow MUST be initiated using the browser. It is NOT RECOMMENDED to relaunch the current flow's last authorization request on the browser as:

• Single-use elements such as request_uri might have been used in the request, and if so relaunching the request on the browser will fail.
• Authorization Servers previously engaged may have returned cookies to Client App, which would be unavailable to the browser and cause the flow to fail.

Therefore Client App MUST start a new flow by launching on the browser a new authorization request without the app2app scope, which then follows "OAuth 2.0 for Native Apps" and does not require further elaboration in this document. Note - In future interactions Client App MAY retry the browser-less App2App flow because past usage of the browser might have resulted from lack of User-Interacting App on the user's device. Since in the meantime the app may have been installed, retrying may achieve the desired browser-less App2App flow.

Processing by User-Interacting Authorization Server's App: The User-Interacting Authorization Server SHALL handle the authorization request using its native app:

• Authenticates end-user and authorizes the request.
• SHALL use native_callback_uri to override the request's original redirect_uri:
  • User-Interacting Authorization Server's app validates that an app claiming native_callback_uri is on the device
  • If so it natively invokes native_callback_uri with the redirect url and its response parameters as the url-encoded query parameter redirect_uri.
  • If such an app does not exist on the device, the flow terminates and User-Interacting Authorization Server's app redirects to redirect_uri with:
    • error=invalid_request.
    • error_description=native_callback_uri_not_claimed.

Client App traverses OAuth Brokers in reverse order Client App is natively invoked by User-Interacting Authorization Server App, with the request's redirect_uri. Client App MUST validate this url, and any url subsequently obtained via a 3xx redirect instruction, against the Allowlist it previously generated, and MUST fail if any url is not included in the Allowlist. Client App SHALL invoke the url it received using HTTP GET:

• If the response is a redirect instruction (HTTP Code 3xx + Location header), Client App SHALL repeat the logic and proceed to call obtained urls until reaching its own redirect_uri (native_callback_uri).
• SHALL handle any other HTTP code (2xx / 4xx / 5xx) as a failure.

Client App obtains response Once Client App's own redirect_uri is returned in a redirect 3xx directive, the traversal of OAuth Brokers is complete. Client App SHALL proceed according to OAuth to exchange code for tokens, or handle error responses.

Detecting Presence of Native Apps claiming Urls Native Apps on iOS and Android MAY use OS SDK's to detect if an app owns a url. The general method is the same - App calls an SDK to open the url as deep link and handles an exception thrown if no matching app is found.

Android App SHALL invoke Android method with FLAG_ACTIVITY_REQUIRE_NON_BROWSER, which throws ActivityNotFoundException if no matching app is found.

iOS App SHALL invoke iOS method with options which ensures URLs must be universal links and have an app configured to open them. Otherwise the method returns false in completion.success.

Security Considerations

Embedded User Agents Security Considerations advises against using embedded user agents. The main concern is preventing theft through keystroke recording of end-user's credentials such as usernames and passwords. This risk does not apply to this draft as Client App acts as User Agent only for the purpose of flow redirection, and does not interact with end-user's credentials in any way.

OAuth request forgery and manipulation It is RECOMMENDED that Client App acts as a confidential OAuth client.

Secure Native application communication If Client App uses a Backend it is RECOMMENDED to communicate with it securely:

• Use TLS in up to date versions and ciphers.
• Use DNSSEC.
• Perform certificate pinning.

Deep link hijacking It is RECOMMENDED that all apps in this specification shall use https-scheme deep links (Android App Links / iOS universal links). Apps SHOULD implement the most specific package identifiers mitigating deep link hijacking by malicious apps.

Open redirection by Client App Client App SHALL construct an Allowlist of DNS domains it traverses while processing the request, used to enforce all urls it later traverses during response processing. This mitigates open redirection attacks as urls not in this Allowlist SHALL be rejected. In addition Client App MUST ignore any invocation for response processing which is not in the context of a request it initiated. It is RECOMMENDED the Allowlist be managed as a single-use object, destructed after each protocol flow ends. It is RECOMMENDED Client App allows only one OAuth request processing at a time.

Open redirection by User-Interacting Authorization Server's App It is RECOMMENDED that User-Interacting Authorization Server's App establishes trust in native_callback_uri to mitigate open redirection attacks and reject untrusted urls.

Authorization code theft and injection It is RECOMMENDED that PKCE is used and that the code_verifier is tied to the Client App instance, as mitigation to authorization code theft and injection attacks.

IANA Considerations This document has no IANA actions.

References Normative References The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK] OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy"). OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case and how native apps and authorization servers can implement this best practice. This document defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint. This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References n.d. n.d. n.d.

Acknowledgments The authors would like to thank the following individuals who contributed ideas, feedback, and wording that shaped and formed the final specification: George Fletcher, Arndt Schwenkschuster, Henrik Kroll, Grese Hyseni. As well as the attendees of the OAuth Security Workshop 2025 session in which this topic was discussed for their ideas and feedback.

Document History [[ To be removed from the final specification ]] -latest

• Phrased the challenge in Trust Domain terminology
• Discussed interim Authorization Server interacting the end-user, which is not the User-Authenticating Authorization Server
• Moved Cookies topic to Protocol Flow
• Mentioned that Authorization Servers redirecting not through HTTP 3xx force the use of a browser
• Discussed Embedded user agents security consideration
• Starting to consider using a rich authorization details type as simpler container for native_callback_uri

-03

• Defined parameters and values
• Added error native_callback_uri_not_claimed

-02

• Clarified wording
• Improved figures

-01

• Better defined terms
• Explained deep link claiming detection on iOS and android

-00

• initial working group version (previously draft-zehavi-oauth-app2app-browserless)