# Transition to Claimed HTTPS URIs

**URL:** <https://community.auth0.com/t/transition-to-claimed-https-uris/199155>\
**Category:** Get Help\
**Tags:** new-universal-login-experience, login-experience\
**Created:** [April 20, 2026, 2:49pm UTC](https://community.auth0.com/t/transition-to-claimed-https-uris/199155 "2026-04-20T14:49:39Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![gluten](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/gluten/32/79093_2.png) [@gluten](https://community.auth0.com/u/gluten)\
**Post date:** [April 20, 2026, 2:49pm UTC](https://community.auth0.com/t/transition-to-claimed-https-uris/199155/1 "2026-04-20T14:49:39Z")

</div>

On Android, everything works as expected with https scheme. Unfortunately, we have some issues on iOS side. The logout process never closes the browser, it hangs on the callback site.

For the login, there are some cases when, after pressing “Continue”, the page remains on the “universal login”. Is there something wrong with the setup? Is there something wrong with the auth0 client?

I’m using Auth0.OidcClient.MAUI v1.4.0 and \*.auth0.com tenant.

There are no errors in dashboard, all operations are successful. My app is always opening when I’m tapping on the callback link from notes, so I don’t think this is related to universal link. I’ve tested this on iOS 18.7.7 and 26.4.

---

<div class="post-metadata">

**Author:** ![nik.baleca](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/nik.baleca/32/68749_2.png) [@nik.baleca](https://community.auth0.com/u/nik.baleca)\
**Post date:** [April 21, 2026, 4:18pm UTC](https://community.auth0.com/t/transition-to-claimed-https-uris/199155/3 "2026-04-21T16:18:12Z")

</div>

Hi @gluten

Welcome to the Auth0 Community!

I believe the issue is caused by an architectural clash between Apple’s underlying authentication API (`ASWebAuthenticationSession` ) and `https` Universal Links. **Apple explicitly designed `ASWebAuthenticationSession` to listen for a Custom URL Scheme (e.g., `myapp://` ) to know when to dismiss its modal window.**

When you use an `https` scheme for an OAuth callback, iOS successfully routes the link to your app, but it fails to notify the authentication session to close, leaving the browser window hanging permanently on the screen.

1. In your Auth0 Dashboard → Applications → [Your App] → Settings, add a custom scheme to your **Allowed Callback URLs** and **Allowed Logout URLs**. A reverse-DNS format is recommended (e.g., `com.yourcompany.app://callback` ).
2. Register your new custom scheme in your MAUI project’s Platforms/iOS/Info.plist file so the OS knows your app owns it:

```auto
<key>CFBundleURLTypes</key>
<array>
    <dict>
        <key>CFBundleURLName</key>
        <string>Auth0</string>
        <key>CFBundleURLSchemes</key>
        <array>
            <string>com.yourcompany.app</string>
        </array>
        <key>CFBundleTypeRole</key>
        <string>Editor</string>
    </dict>
</array>

```

1. Inside your MAUI code, you will need to conditionally use the Custom Scheme for iOS while retaining your `https` link for Android (if you prefer to keep Android on App Links):

```auto
#if IOS
    var redirectUri = "com.yourcompany.app://callback";
#else
    var redirectUri = "https://yourcompany.com/callback";
#endif

```

Let me know if that does the trick for you!

Kind Regards,  
Nik

---

<div class="post-metadata">

**Author:** ![gluten](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/gluten/32/79093_2.png) [@gluten](https://community.auth0.com/u/gluten)\
**Post date:** [April 21, 2026, 5:15pm UTC](https://community.auth0.com/t/transition-to-claimed-https-uris/199155/4 "2026-04-21T17:15:37Z")

</div>

Hi @nik.baleca , the only issue with your fix is the fact that we’ve been receiving warnings from Auth0 saying:

This notice reminds you of Auth0 changes to login flows that use custom URI schemes or loopback URIs as callbacks. Starting **April 28, 2026** , Auth0’s default behavior changes for these login flows, and a new login confirmation prompt may be displayed to users.  
Small Link  
How are you affected?  
Between February 26 and March 19, at least one of your tenants received login requests using a custom URI scheme or a loopback URI (localhost) callback.

> > What action do you need to take?  
> > Review Measures Against Application Impersonation and, before April 28, 2026, configure your tenant using one of the options below. Consider the security risks. Attackers can exploit custom URI schemes and loopback URIs for application impersonation and unauthorized access.
> > 
> > Option A - Skip the end-user confirmation prompt
> > 
> > This option preserves the original behavior. You do not need to change your applications, and the user experience stays the same.
> > 
> > Follow the steps in the Opt out of new login confirmation prompt section of the migration guide, specifically the steps to opt out at the tenant level.
> > 
> > Option B - Adopt the end-user confirmation prompt or transition to claimed HTTPS URIs
> > 
> > This option strengthens security but requires you to update your applications or change the user experience.
> > 
> > Follow the steps in the Opt in to new login confirmation prompt section of the migration guide to adopt the confirmation prompt and update applications to use a claimed HTTPS URI for callbacks.

Additionally, if the logout process is performed through the custom scheme, we’ll still receive the warning.

---

<div class="post-metadata">

**Author:** ![nik.baleca](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/nik.baleca/32/68749_2.png) [@nik.baleca](https://community.auth0.com/u/nik.baleca)\
**Post date:** [April 21, 2026, 5:44pm UTC](https://community.auth0.com/t/transition-to-claimed-https-uris/199155/5 "2026-04-21T17:44:18Z")

</div>

I see. Thanks for the update.

I have completely overlooked the fact that custom uri schemes are not recommended due to the risk of application impersonation. You can read more about that [here](https://auth0.com/docs/secure/security-guidance/measures-against-app-impersonation).

Otherwise, going back to the issue, to use the secure https Universal Links and completely resolve both the Auth0 warning and the hanging browser, try following these steps:

1. You must intercept the `NSUserActivity` (the Universal Link) and pass it to MAUI’s `WebAuthenticator` . Open your `Platforms/iOS/AppDelegate.cs` file and add the `ContinueUserActivity` method:

```auto
using Foundation;
using UIKit;
using Microsoft.Maui.Authentication; // Required for WebAuthenticator

namespace YourAppNamespace;

[Register("AppDelegate")]
public class AppDelegate : MauiUIApplicationDelegate
{
    protected override MauiApp CreateMauiApp() => MauiProgram.CreateMauiApp();

    [Export("application:continueUserActivity:restorationHandler:")]
    public override bool ContinueUserActivity(UIApplication application, NSUserActivity userActivity, UIApplicationRestorationHandler completionHandler)
    {
        if (userActivity.ActivityType == NSUserActivityTypeBrowsingWeb)
        {
            var url = userActivity.WebPageUrl;
            if (url != null)
            {
                WebAuthenticator.Default.OnResume(url);
            }
        }
        
        return base.ContinueUserActivity(application, userActivity, completionHandler);
    }
}

```

1. Revert Auth0 Configuration to HTTPS

- Change your `Auth0ClientOptions` Redirect URI and Post Logout URI back to your `https` domains.
- Ensure those `https` URLs are correctly listed in your Auth0 Dashboard \> Applications \> Allowed Callback / Logout URLs.

With this code in place, when Auth0 redirects to your `https` link, iOS should open the app, trigger `ContinueUserActivity` , pass the URL to `OnResume()` , and the browser will instantly vanish, completing the login/logout process.

Let me know if this works or not!

Kind Regards,  
Nik

---

<div class="post-metadata">

**Author:** ![gluten](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/gluten/32/79093_2.png) [@gluten](https://community.auth0.com/u/gluten)\
**Post date:** [April 21, 2026, 7:53pm UTC](https://community.auth0.com/t/transition-to-claimed-https-uris/199155/6 "2026-04-21T19:53:56Z")

</div>

@nik.baleca I’ve tried like this, as OnResume isn’t part of WebAuthentication. I’ve put a breakpoint into this and it never hits on logout, only on login

[Export(“application:continueUserActivity:restorationHandler:”)]

```
public override bool ContinueUserActivity(UIApplication application, NSUserActivity userActivity, UIApplicationRestorationHandler completionHandler)

{

    if (userActivity.ActivityType == NSUserActivityType.BrowsingWeb)

    {

        var url = userActivity.WebPageUrl;

        if (url != null)

        {

            return WebAuthenticator.Default.OpenUrl(url);

        }

    }

        

    return base.ContinueUserActivity(application, userActivity, completionHandler);

}

```

---

<div class="post-metadata">

**Author:** ![Ed156](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/ed156/32/72790_2.png) [@Ed156](https://community.auth0.com/u/Ed156)\
**Post date:** [April 23, 2026, 11:00am UTC](https://community.auth0.com/t/transition-to-claimed-https-uris/199155/7 "2026-04-23T11:00:05Z")

</div>

I have a similar situation. My app (android and ios) worked like the Maui quickstart documentation but we should now move away from the custom uri scheme. Android works with https now, but still strugling with iOS.

I tried the same as suggested here (also no Onresume in WebAuthentication) and see the same results (the browser stays open after logging in, saying ‘Not found‘, so not returning to the app.

The last two weeks i have had help with this through a support ticket (by Emil) where we doublechecked each setting in Auth0 and the Maui iOS code, but could not find a solution unfortunately.

I’ll be keeping an eye on any pointer you guys may have 🙂

---

<div class="post-metadata">

**Author:** ![nik.baleca](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/nik.baleca/32/68749_2.png) [@nik.baleca](https://community.auth0.com/u/nik.baleca)\
**Post date:** [April 24, 2026, 5:46pm UTC](https://community.auth0.com/t/transition-to-claimed-https-uris/199155/8 "2026-04-24T17:46:49Z")

</div>

Hi again!

Sorry for the delayed reply and thanks for providing more info on the matter!

When iOS refuses to trigger `ContinueUserActivity` for a specific URL, it means the OS routing engine decided to treat the logout redirect as a standard web page rather than a deep link into your app. This usually happens for one of two reasons: either the specific logout path is missing from your domain’s Apple App Site Association (AASA) file, or iOS WebKit is aggressively blocking the automatic HTTP 302 redirect issued by Auth0’s logout endpoint.

To force iOS to respect the Universal Link on logout and close the browser, try to follow these steps:

- Update your `AppDelegate.cs` to use MAUI’s dedicated auth callback manager. This is the specific method designed to close the `ASWebAuthenticationSession` modal:

```auto
[Export("application:continueUserActivity:restorationHandler:")]
public override bool ContinueUserActivity(UIApplication application, NSUserActivity userActivity, UIApplicationRestorationHandler completionHandler)
{
    if (userActivity.ActivityType == NSUserActivityType.BrowsingWeb)
    {
        var url = userActivity.WebPageUrl;
        if (url != null)
        {
            Microsoft.Maui.Authentication.WebAuthenticationCallbackManager.Authenticate(url);
            return true;
        }
    }
        
    return base.ContinueUserActivity(application, userActivity, completionHandler);
}

```

- If your AASA file is the culprit, the fastest way to test and fix this is to use the **exact same URL** for both login and logout.

- Since iOS has already proven it trusts your login URL and triggers the breakpoint, tell Auth0 to route the logout there as well:  
 → In your MAUI `Auth0ClientOptions` , set `PostLogoutRedirectUri = "https://yourdomain.com/callback"`  
-\>The OIDC client will simply drop the local session and close the browser when it hits this URL, regardless of whether it was a login or logout.

- If you unify the URLs and iOS _still_ ignores the Universal Link on logout, you have hit the WebKit 302 redirect bug.

- To bypass this, you must stop Auth0 from directly redirecting to your Universal Link. Instead, have Auth0’s `returnTo` parameter point to a standard, static HTML page hosted on your website (e.g., `https://yourdomain.com/logout-success.html` ).  
On that HTML page, include a tiny snippet of JavaScript:

```auto
<!DOCTYPE html>
<html>
<head><title>Logging out...</title></head>
<body>
  <p>Returning to app...</p>
  <script>
    window.location.href = "https://yourdomain.com/callback";
  </script>
</body>
</html>

```

- When Auth0 logs the user out, it safely redirects to this webpage. The webpage loads, the JavaScript executes, and iOS instantly recognizes the Universal Link, triggering your `ContinueUserActivity` breakpoint and closing the browser.

If the above does not fix the issue, let me know and I will dig deeper into the iOS MAUI implementation!

Kind Regards,  
Nik

---

<div class="post-metadata">

**Author:** ![gluten](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/gluten/32/79093_2.png) [@gluten](https://community.auth0.com/u/gluten)\
**Post date:** [April 24, 2026, 7:01pm UTC](https://community.auth0.com/t/transition-to-claimed-https-uris/199155/9 "2026-04-24T19:01:34Z")

</div>

@nik.baleca Hi, I couldn’t find anything related to Microsoft.Maui.Authentication.WebAuthenticationCallbackManager.Authenticate(url), also if ContinueUserActivity is never hit on logout, I think this will never be useful. On the other hand, my RedirectUri and PostLogoutRedirectUri were always the same. I’ve also tried the html hack, but the browser remains on /callback

---

<div class="post-metadata">

**Author:** ![Ed156](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/ed156/32/72790_2.png) [@Ed156](https://community.auth0.com/u/Ed156)\
**Post date:** [April 25, 2026, 8:19am UTC](https://community.auth0.com/t/transition-to-claimed-https-uris/199155/10 "2026-04-25T08:19:22Z")

</div>

Hi Nic, there is no WebAuthenticationCallbackManager in Microsoft.Maui.Authentication.

The RedirectUri and PostLogoutRedirectUri are the same.

I will not be able to test for the webkit redirect bug until tuesday. I assume the returnTo parameter is set by setting the PostLogoutRedirectUri in the wrapper client Auth0ClientOptions.

Kind regards, Ed

---

<div class="post-metadata">

**Author:** ![Ed156](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/ed156/32/72790_2.png) [@Ed156](https://community.auth0.com/u/Ed156)\
**Post date:** [April 28, 2026, 11:50am UTC](https://community.auth0.com/t/transition-to-claimed-https-uris/199155/11 "2026-04-28T11:50:51Z")

</div>

For completeness I just did the check with the static html page, redirecting to the logout url. I set the postLogoutRedirectUri to that page url, and added that page url to the allowed logout urls.  
This all made no difference. After logging in the browser stays open (saying ‘not found‘) without returning to the app.

---

<div class="post-metadata">

**Author:** ![nik.baleca](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/nik.baleca/32/68749_2.png) [@nik.baleca](https://community.auth0.com/u/nik.baleca)\
**Post date:** [April 29, 2026, 5:33pm UTC](https://community.auth0.com/t/transition-to-claimed-https-uris/199155/13 "2026-04-29T17:33:03Z")

</div>

Hi again.

I am sorry for the delayed response, I was still investigating the matter.

Could you let me know how did you `AppDelegate` file was looking like before attempting to transition to the claimed HTTPS URIs?

WAs it anything similar to what our documentation and sample applications provide?

```auto
using Auth0.OidcClient;
using Foundation;
using UIKit;

[Register("AppDelegate")]
public class AppDelegate : UIApplicationDelegate
{
    private Auth0Client auth0Client;

    public override bool FinishedLaunching(UIApplication application, NSDictionary launchOptions)
    {
        // Initialize Auth0 client
        auth0Client = new Auth0Client(new Auth0ClientOptions
        {
            Domain = "{yourDomain}",
            ClientId = "{yourClientId}"
        });

        return true;
    }

    public override bool OpenUrl(UIApplication application, NSUrl url,
        string sourceApplication, NSObject annotation)
    {
        ActivityMediator.Instance.Send(url.AbsoluteString);
        return true;
    }
}

```

OR

```auto
using Auth0.OidcClient;
using Foundation;
using UIKit;

namespace iOSTestApp
{
    [Register("AppDelegate")]
    public class AppDelegate : UIApplicationDelegate
    {
        public override UIWindow Window
        {
            get;
            set;
        }

        public override bool OpenUrl(UIApplication application, NSUrl url, string sourceApplication, NSObject annotation)
        {
            ActivityMediator.Instance.Send(url.AbsoluteString);
            return true;
        }
    }
}

```

For some referenced, you can visit:

- [MAUI Quickstart documentation](https://auth0.com/docs/quickstart/native/maui)
- [NuGet Package Page](https://www.nuget.org/packages/Auth0.OidcClient.MAUI)
- [Github sample application page](https://github.com/auth0/auth0-oidc-client-net)

Going back to the issue, it appears that the functions I have mentioned above are quite deprecated. After some investigation in regards to the [Microsoft MAUI documentation](https://learn.microsoft.com/en-us/dotnet/api/microsoft.maui.authentication.webauthenticator.authenticateasync?view=net-maui-10.0#microsoft-maui-authentication-webauthenticator-authenticateasync(system-uri-system-uri)), could you try using `WebAuthenticator.Default` OR `WebAuthenticator.AuthenticateAsync( {{URL}}, {{CALLBACK_URL}}` and let me know if you notice any change in behaviour?

As @Ed156 has mentioned regarding his opened ticket, this might be a limitation of the MAUI SDK not supporting claimed HTTPS URIs at this time and it should be under investigation. Whenever an update is given regarding the matter, I will let you know under this thread!

Looking forward to your replies.

Kind Regards,  
Nik

---

<div class="post-metadata">

**Author:** ![gluten](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/gluten/32/79093_2.png) [@gluten](https://community.auth0.com/u/gluten)\
**Post date:** [April 29, 2026, 7:23pm UTC](https://community.auth0.com/t/transition-to-claimed-https-uris/199155/14 "2026-04-29T19:23:36Z")

</div>

Hi @nik.baleca ,

There was only protected override MauiApp CreateMauiApp() in AppDelegate.

I’ve also tried with WebAuthenticator.AuthenticateAsync( {{URL}}, {{CALLBACK\_URL}} and there is no difference.

Thank you!

---

<div class="post-metadata">

**Author:** ![Ed156](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/ed156/32/72790_2.png) [@Ed156](https://community.auth0.com/u/Ed156)\
**Post date:** [April 30, 2026, 9:00am UTC](https://community.auth0.com/t/transition-to-claimed-https-uris/199155/15 "2026-04-30T09:00:14Z")

</div>

Hi Nic,

Note that Maui app ‘s iOS AppDelegate inherits from MauiUIApplicationDelegate, not UIApplicationDelegate. This below is from a recent Maui template made with VS2026, and is also the base of my code.

```auto
using Foundation;

namespace MauiApp1
{
[Register(“AppDelegate”)]
public class AppDelegate : MauiUIApplicationDelegate
{
protected override MauiApp CreateMauiApp() => MauiProgram.CreateMauiApp();
}
}

```

Kind regards, Ed

---

<div class="post-metadata">

**Author:** ![nathan044](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/nathan044/32/70993_2.png) [@nathan044](https://community.auth0.com/u/nathan044)\
**Post date:** [May 14, 2026, 3:23pm UTC](https://community.auth0.com/t/transition-to-claimed-https-uris/199155/16 "2026-05-14T15:23:11Z")

</div>

> [@gluten](#):
>
> On Android, everything works as expected with https scheme. Unfortunately, we have some issues on iOS side. The logout process never closes the browser, it hangs on the callback site.
> 
> For the login, there are some cases when, after pressing “Continue”, the page remains on the “universal login”. Is there something wrong with the setup? Is there something wrong with the auth0 client?
> 
> I’m using Auth0.OidcClient.MAUI v1.4.0 and \*.auth0.com tenant.
> 
> There are no errors in dashboard, all operations are successful. My app is always opening when I’m tapping on the callback link from notes, so I don’t think this is related to universal link. I’ve tested this on iOS 18.7.7 and 26.4.

This doesn’t look like an Auth0 server issue since everything is showing success in the dashboard.

On iOS this kind of behaviour usually happens when the system browser session doesn’t properly close after the redirect. That’s why logout stays stuck on the callback page and login sometimes hangs on Universal Login even after pressing continue.

Since Android works fine, it’s likely related to how iOS handles `ASWebAuthenticationSession` in `Auth0.OidcClient.MAUI v1.4.0`. I’d try updating the package first and also double-check the redirect URI setup for iOS.

---

<div class="post-metadata">

**Author:** ![nik.baleca](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/nik.baleca/32/68749_2.png) [@nik.baleca](https://community.auth0.com/u/nik.baleca)\
**Post date:** [September 1, 2026, 11:29pm UTC](https://community.auth0.com/t/transition-to-claimed-https-uris/199155/17 "2026-09-01T23:29:06Z")

</div>

Hi again everyone. I will be providing an updated and optimized solution regarding the current topic.

You are using Auth0.OidcClient.MAUI v1.4.0 for a .NET MAUI cross-platform mobile app. Login and logout work as expected on Android with the **https://** scheme, but on iOS you are experiencing two critical issues:

1. **Logout hangs on the callback site:** After initiating logout, the browser window never closes; instead, it remains open on the callback page.
2. **Login sometimes fails:** After pressing "Continue" on the Universal Login page, the page remains on the login screen instead of redirecting back to the app.

The Dashboard shows all operations as "successful," and your app correctly opens when you manually tap the callback link from notes, suggesting universal links are properly configured. You are testing on iOS 18.7.7 and iPadOS 16.4.

**This is a platform-specific callback routing issue on iOS caused by cookie-sharing behavior in the browser session. The solution requires proper HTTPS universal link configuration with associated domains, combined with ephemeral session handling to prevent shared cookies from interfering with callback dismissal.**

**[Root Cause]**

iOS uses **ASWebAuthenticationSession** to handle OAuth callbacks. By default, this API stores session cookies in the **shared Safari cookie jar** to enable Single Sign-On (SSO). However, this shared session can cause two problems:

1. **Logout hangs:** When logging out, the shared cookie persists, and the browser does not receive a clear dismissal signal. The logout callback is processed, but the browser window remains open because the session is still active.
2. **Login remains on Universal Login page:** If a previous session cookie exists, the browser may not properly route the callback back to your app, or the callback is processed but the browser modal does not dismiss because the session state is ambiguous.

Additionally, if your **[associated domain configuration](https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.developer.associated-domains) is incomplete or the AASA file is not properly cached**, the universal link may not be recognized during the automated OAuth flow, even though manual tapping works (manual tapping uses a different code path).

**[Solution]**

**Step 1: Verify and configure associated domains in your MAUI iOS project**

**Open** `Platforms/iOS/Info.plist` and add the associated domain entry:

```
<key>com.apple.developer.associated-domains</key>
<array>
    <string>webcredentials:yourcompany.com</string>
</array>
```

Replace `yourcompany.com` with your actual callback domain (the domain part of your callback URL, e.g., `https://yourcompany.com/callback` → `yourcompany.com`).

**Step 2: Verify the AASA file is properly hosted**

Auth0 automatically generates the `apple-app-site-association` (AASA) file at `https://your-auth0-domain/.well-known/apple-app-site-association`.

**Verify** that the file is accessible and contains your app's Team ID and Bundle ID:

```
curl https://your-auth0-domain/.well-known/apple-app-site-association
```

The response should look like:

```
{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "TEAM_ID.BUNDLE_ID",
        "paths": ["/ios/BUNDLE_ID/*"]
      }
    ]
  }
}
```

If the file is missing or incorrect, verify in the Auth0 Dashboard that you have configured your **Team ID** and **Bundle ID** under Applications → Your App → Settings → iOS.

**Step 3: Enable ephemeral sessions to isolate the browser session**

Ephemeral sessions prevent the browser from sharing cookies with Safari, eliminating the shared session interference. Update your MAUI authentication code:

```
var client = new Auth0Client(new Auth0ClientOptions
{
    Domain = "your-tenant.auth0.com",
    ClientId = "your-client-id",
    RedirectUri = "https://yourcompany.com/callback",
    PostLogoutRedirectUri = "https://yourcompany.com/logout"
});

// For iOS, enable ephemeral session
#if IOS
    var options = new WebAuthenticatorOptions
    {
        PrefersEphemeralWebBrowserSession = true
    };
    // Pass options to the Auth0Client or WebAuthenticator call
#endif
```

**Important:** With ephemeral sessions enabled, the shared Safari cookie is not used. This means:

- Users will not have SSO across your app and Safari
- After logout, you must include `prompt=login` in the next login request to force a fresh login (otherwise the user may still be authenticated in the ephemeral session)

**Step 4: Ensure logout callback URLs are configured separately**

**Navigate to** Auth0 Dashboard → Applications → Your Application → Settings.

**Verify** that you have added your logout callback URL to **Allowed Logout URLs** (separate from Allowed Callback URLs):

`https://yourcompany.com/logout`

If you only configured login callbacks, the logout flow will not know where to redirect after clearing the session.

**Step 5: Clear browser cache and test on a physical iOS device**

- **On your development machine,** clear Xcode's derived data: `rm -rf ~/Library/Developer/Xcode/DerivedData/*`
- **On the iOS device,** go to Settings → [Your App Name] → Clear Cache (if available) or reinstall the app
- **Test on a physical iOS device,** not the simulator (simulators have different AASA handling)

**Step 6: If issues persist, add prompt=login to force fresh authentication**

If you continue to see the login page remain after "Continue," add the `prompt=login` parameter to force a fresh authentication:

```
var authResult = await client.LoginAsync(new LoginRequest
{
    Parameters = new Dictionary<string, string>
    {
        { "prompt", "login" }
    }
});
```

**Why This Approach Is Secure:**

HTTPS universal links with associated domains are **cryptographically verified** by Apple. The AASA file is signed by Apple’s CDN, and the domain ownership is verified through the provisioning profile. This prevents [application impersonation attacks](https://auth0.com/docs/secure/security-guidance/measures-against-app-impersonation) that are possible with custom URI schemes, where any app can register the same scheme.

A similar issue regarding an [iOS application not recognizing Auth0 associated domains](https://community.auth0.com/t/ios-application-not-recognizing-auth0-associated-domain/134847/26) has been published in the past on the community and can be a good resource for investigating the matter further.

**Common Mistakes to Avoid:**

- **Associated domain not added to provisioning profile:** iOS cannot verify the domain ownership. Add `webcredentials:yourcompany.com` to the provisioning profile and re-sign the app.
- **AASA file not accessible or incorrectly formatted:** iOS cannot find the app-to-domain mapping. Verify the file is at `https://your-auth0-domain/.well-known/apple-app-site-association` and contains your Team ID and Bundle ID.
- **Team ID or Bundle ID mismatch in AASA file:** iOS rejects the domain association. Verify in Auth0 Dashboard that Team ID and Bundle ID match your app's configuration.
- **Not enabling ephemeral session on iOS:** Shared cookies cause logout hangs and login failures. Set `PrefersEphemeralWebBrowserSession = true` for iOS.
- **Not configuring logout URL separately:** Logout callback is not recognized. Add the logout URL to **Allowed Logout URLs** in the Dashboard.
- **Testing only on the simulator:** Simulator AASA handling differs from physical devices. Always test on a physical iOS device.
- **Not clearing cache after configuration changes:** Old AASA file is cached by iOS. Clear Xcode derived data and reinstall the app.

**If Issues Persist:**

1. **Check the iOS system logs** for AASA validation errors: Open Xcode → Window → Devices and Simulators → Select your device → View Device Logs
2. **Verify the callback URL exactly matches** the URL registered in the Dashboard (including protocol, domain, and path)
3. **Contact Auth0 Support** with: 
  - Your Auth0 tenant name
  - Your app's Bundle ID and Team ID
  - A HAR file of the callback flow (captured from Safari Developer Tools)
  - The exact iOS version and device model

Kind Regards,  
Nik

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/auth0/original/3X/b/5/b560f266932fcce5d57f09a6595bd50518cae3f3.jpeg) [@system](https://community.auth0.com/u/system)\
**Post date:** [September 3, 2026, 11:29pm UTC](https://community.auth0.com/t/transition-to-claimed-https-uris/199155/18 "2026-09-03T23:29:21Z")

</div>

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.