Introduction

A redirect URI is the callback location an OAuth authorization server uses to send the user, and the authorization result, back to the client application. In an iOS app, that callback is usually a custom URL scheme or a universal link that returns the user from the system browser to the app after sign-in.

Where It Fits in OAuth

In the authorization code flow, the user is sent to the authorization server first. After login and consent, the server redirects to the registered redirect URI with an authorization code.

For a native app, that means the redirect URI is not just a web concept. It is how the operating system knows which app should receive the callback.

The typical flow is:

1. app opens the authorization URL in the browser
2. user signs in
3. authorization server redirects to the registered callback
4. app receives the code
5. app exchanges the code for tokens, usually with PKCE

Redirect URI on iOS

Two common patterns are:

• custom URL scheme, such as myapp://oauth/callback
• universal link, such as https://app.example.com/oauth/callback

Custom schemes are simple to set up, but universal links are generally stronger because they are tied to a domain you control.

Custom URL Scheme Example

In the app's Info.plist, register a URL type:

1<key>CFBundleURLTypes</key>
2<array>
3  <dict>
4    <key>CFBundleURLSchemes</key>
5    <array>
6      <string>myapp</string>
7    </array>
8  </dict>
9</array>

Then the redirect URI registered with the OAuth provider can be:

myapp://oauth/callback

When the system opens that URI, the app can parse the authorization code from the callback URL.

Handling the Callback

1func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
2    guard let url = URLContexts.first?.url else { return }
3    guard url.scheme == "myapp" else { return }
4
5    let components = URLComponents(url: url, resolvingAgainstBaseURL: false)
6    let code = components?.queryItems?.first(where: { $0.name == "code" })?.value
7
8    print(code ?? "missing code")
9}

The exact app lifecycle hook depends on the app structure, but the idea is the same: receive the redirect and extract the code or error fields.

Security Implications

The redirect URI is a major security boundary. The authorization server should only redirect to pre-registered URIs. If the server accepts arbitrary redirect targets, an attacker may be able to steal codes or tokens.

For iOS apps, the other crucial rule is: do not rely on a client secret embedded in the app. Native apps are public clients. The recommended protection is PKCE, not a hard-coded secret.

What Makes a Redirect URI "Correct"

A valid redirect URI must match what the provider has registered. Many providers require an exact match, including:

• scheme
• host
• path

Sometimes even a trailing slash mismatch is enough to fail the flow.

That is why "redirect URI mismatch" is such a common OAuth error. The app, the provider configuration, and the callback handler must all agree exactly.

Common Pitfalls

The biggest mistake is thinking the redirect URI is where tokens are stored permanently. It is only the callback location used to deliver the authorization result.

Another mistake is registering a custom scheme that is too generic. If another app can plausibly claim the same scheme, callback routing becomes less trustworthy.

A third issue is using a native app like a confidential web client. On iOS, use authorization code flow with PKCE rather than shipping a client secret.

Summary

• A redirect URI is the callback destination used by the OAuth authorization server.
• In iOS, it is usually a custom URL scheme or a universal link.
• The callback returns an authorization code that the app exchanges for tokens.
• Redirect URIs must exactly match provider registration.
• For native apps, pair the redirect URI with PKCE, not an embedded client secret.