| Internet-Draft | Native OAuth App2App | May 2025 |
| Zehavi, et al. | Expires 10 November 2025 | [Page] |
This document describes a protocol enabling native apps from any app publisher, using the [App2App] pattern, to achieve native user navigation without requiring a web browser.¶
The native navigation is retained also when the Client uses any number of OAuth brokers to federate across trust domains, while offering highest levels of security.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://yaron-zehavi.github.io/oauth-app2app-browserless/draft-zehavi-oauth-app2app-browserless.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-zehavi-oauth-app2app-browserless/.¶
Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (mailto:oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Subscribe at https://www.ietf.org/mailman/listinfo/oauth/.¶
Source for this draft and an issue tracker can be found at https://github.com/yaron-zehavi/oauth-app2app-browserless.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 10 November 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document, OAuth 2.0 App2App Browserless Flow (Native App2App), presents a protocol enabling native [App2App] 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 needed when Client App is not an OAuth client of the User-Interacting Authorization Server.¶
Since no app owns OAuth Brokers' urls, App2App flows involving brokers require using a web browser, which degrades the user experience.¶
This document specifies a new scope.¶
[OpenID.Native-SSO] also offers a native SSO flow across apps. However, it is limited to apps published by the same issuer which can therefore securely share information.¶
In addition to the terms defined in referenced specifications, this document uses the following terms:¶
In this document, "OAuth" refers to OAuth 2.0, [RFC6749] and [RFC6750] as well as [OpenID], both in their authorization code flow.¶
Proof Key for Code Exchange (PKCE) [RFC7636], a mechanism to prevent various attacks on OAuth authorization codes.¶
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 currently employed to establish trust in federation use cases, such as in Academia and in the business world across corporations. Brokers may be replaced in the future with dynamic trust establishment leveraging [OpenID.Federation].¶
A Native app implementing "OAuth 2.0 for Native Apps" [RFC8252] as an OAuth client of Initial Broker. Client's redirect_uri is claimed by the app.¶
An OAuth Broker serving as the Authorization Server of Client App. Is an OAuth client of a Downstream Authorization Server.¶
An Authorization Server which may be an OAuth Broker or a User-Interacting Authorization Server.¶
The Authorization Server which interacts with end-user to perform authentication and authorization.¶
A url claimed by a native application.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Since OAuth Brokers url's are not claimed by any native app, requests targeting them (OAuth requests and redirect_uri responses) are handled by a web browser.¶
Using a web browser downgrades the user experience in several ways:¶
Some browsers do not support deep links at all. Others may not support deep links depending on the settings used.¶
The browser may prompt end-user for consent before opening deep links, introducing additional friction.¶
Even if the browser supports deep links and does not prompt the end-user, browser loading of urls and redirecting may be noticeable.¶
The browser may be left after the flow ends with "orphan" browser tabs used for redirection. While these do not impact the process directly, they can be seen as clutter which degrades the overall UX's cleanliness.¶
In addition, app developers cannot control which browser will be used to handle the response redirect_uri, which risks losing of cookies used to bind session identifiers (nonce, state or PKCE verifier) to the user agent, which may break the flow.¶
When the user's device does not have an app owning the User-Authenticating Authorization Server's urls, the flow requires the help of a browser.¶
This is the case when the User-Authenticating Authorization Server offers no native app, or when such an app exists but is not installed on the end-user's device.¶
This is similar to the flow described in "OAuth 2.0 for Native Apps" [RFC8252], and referred to in [App2App] as App2Web.¶
(1) Client App uses HTTP to call Initial Broker's authorization endpoint with an authorization request including app2app scope.¶
(2) Initial Broker returns an authorization request for Downstream Authorization Server including scope app2app:client_app_deep_link¶
(3) If the authorization request url is owned by an app on the device this step is skipped. Otherwise Client App loops through Downstream Authorization Servers, using HTTP to call their authorization endpoint and process their HTTP 3xx redirect responses, until a url owned by an app on the device is reached.¶
(4) Client App natively invokes User-Authenticating App.¶
(5) User-Authenticating App authenticates user and authorizes the request. It identifies app2app mode and overrides the request's redirect_uri, using client_app_deep_link instead.¶
(6) User-Authenticating App natively invokes Client App using client_app_deep_link, handing it the redirect_uri.¶
(7) Client App loops through Authorization Servers in reverse order, starting from the redirect_uri it received from the User-Authenticating App. It uses HTTP to call the first redirect_uri and any subsequent uri obtained as 3xx redirect directive, until it obtains a redirect to its own redirect_uri.¶
(8) Client App exchanges code for tokens.¶
Client App calls Initial Broker's authorization_endpoint to initiate an authorization code flow, it SHALL indicate App2App flow using the dedicated scope app2app.¶
Client App's redirect_uri SHALL be claimed by the app and will be referred to as client_app_deep_link.¶
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:¶
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.¶
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.¶
App SHALL invoke Android [android.method.intent] method with FLAG_ACTIVITY_REQUIRE_NON_BROWSER, which throws ActivityNotFoundException if no matching app is found.¶
App SHALL invoke iOS [iOS.method.openUrl] method with options [iOS.option.universalLinksOnly] which ensures URLs must be universal links and have an app configured to open them. Otherwise the method returns false in completion.success¶
It is RECOMMENDED that Client App acts as a confidential OAuth client.¶
If Client App uses a Backend it is RECOMMENDED to communicate with it securely:¶
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.¶
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.¶
This document has no IANA actions.¶
The authors would like to thank the attendees of the OAuth Security Workshop 2025 session in which this was discussed, as well as the following individuals who contributed ideas, feedback, and wording that shaped and formed the final specification:¶