For a mobile app, use a claimed HTTPS redirect URI where the platform supports it. RFC 8252 says native apps should prefer it, because the operating system guarantees the destination app's identity. Use a private use URI scheme as a fallback and a loopback address for desktop tools.
The three options
RFC 8252, the IETF guidance for OAuth in native apps, describes three ways to get the authorization response back into the app. All three start by opening the system browser, since native apps must not use embedded user agents for authorization requests.
| Option | Looks like | Suits | Main caveat |
|---|---|---|---|
| Claimed HTTPS | https://app.example.com/oauth2redirect/provider | Mobile apps | Needs the platform's app link or universal link setup |
| Private use URI scheme | com.example.app:/oauth2redirect/provider | Mobile apps where claimed links are not available | Other apps could register the same scheme |
| Loopback | http://127.0.0.1:port/path | Desktop apps that can open a local port | Needs a port, and may not suit all platforms |
Claimed HTTPS
An app claims an https URL on a domain it controls. When the browser meets that URL, the operating system launches the app instead of loading the page. The authorization server sees an ordinary https redirect URI.
RFC 8252 gives the reason it is preferred: the identity of the destination app is guaranteed to the authorization server by the operating system. Because the URI alone does not tell a public native client from a confidential web client, the specification also requires that the client type be recorded at registration.
Private use URI scheme
Many platforms let apps register a custom scheme. RFC 8252 sets rules for it. The scheme must be based on a domain name the developer controls, written in reverse order, so an app that controls app.example.com can use com.example.app. A scheme such as myapp does not qualify. Only a single slash follows the scheme. Where an app has an identifier in reverse domain form, that identifier can be reused.
The weakness is that nothing stops a second app registering the same scheme. That is why PKCE matters here, since it prevents a stolen authorization code from being exchanged.
Loopback
Desktop apps that can open a local port can receive the redirect at http://127.0.0.1 or http://[::1] with a port. The authorization server must allow any port to be specified at request time, because the app picks an available one. Clients should not assume a particular IP version and should try to bind both IPv4 and IPv6.
What applies to all three
- Use the authorization code flow with PKCE.
- Open the system browser. RFC 8252 says native apps must not use embedded user agents for authorization requests.
- Register exact redirect URIs for each app, and record the client type.
- Do not treat a client secret shipped in an app as a secret. RFC 8252 says such secrets should not be treated as confidential.
- Check the state parameter on return, since RFC 8252 covers cross app request forgery protections.
How to choose
| If | Then |
|---|---|
| The platform supports app links and you control a web domain | Claimed HTTPS |
| Not, or you need to support older systems | Private use scheme with PKCE |
| Desktop tool with local port access | Loopback with PKCE |
Safeguard's SBOM and dependency scanning shows the authentication libraries inside your app builds, and a free scan is available at gold.safeguard.sh/scan.
Related reading
Quick check
Is a custom scheme like myapp acceptable?
RFC 8252 says the scheme must be based on a domain name you control in reverse order, so a bare name like myapp does not meet the requirement.
Why prefer claimed HTTPS over a custom scheme?
The operating system verifies which app owns the link, so another app cannot simply register the same redirect.
Sources
Last reviewed: 19 October 2026.
