Cross-Platform Login in Unity (iOS, Android, PC, WebGL)

Shipping to one platform is a login. Shipping to iOS, Android, PC, and WebGL is four platforms with four different ideas about how a browser hands control back to your game. The good news: the game-side code doesn't change. The gotchas live in the return trip, and they're per-platform. This is what differs across targets and how to keep it to a single login manager.

The part that stays the same

Start with the reassuring bit. Your login code is identical on every platform:

using PixitGames.SSOLoginKit;

public class LoginManager : SsoClientBase
{
    // Same call on iOS, Android, desktop, and WebGL.
    public void OnLoginButton() => StartLogin("google");

    protected override void OnLoginSuccess(LoginResult user)
    {
        Debug.Log($"Signed in as {user.name} on {Application.platform}");
        // user.id is your stable cross-platform player key.
    }
}

StartLogin behaves the same to your code everywhere. What changes underneath is how the result gets back to that OnLoginSuccess — and the provider-facing side never changes at all. Every provider redirects to the one fixed redirect URI, https://sso.oathwall.com/auth/callback, regardless of which platform the player is on. You register that once per provider and you're done. Everything platform-specific happens between that callback and your game.

Where the platforms diverge

Login opens in the system browser on native targets and has to come home. How it comes home is the difference.

iOS

The browser returns to your app through a deep link. The simplest mechanism is a custom URL scheme (mygame://), which works but isn't owned — another app can claim the same scheme. iOS Universal Links are the stronger option: ordinary https:// links tied to a domain you control, verified against an apple-app-site-association file, so they can't be hijacked. There's also the platform rule to remember here — if your game offers any other social login on iOS, Sign in with Apple is required by App Store review.

Android

Same idea, Android's vocabulary. A custom scheme works everywhere; App Links are the verified https:// equivalent, backed by an assetlinks.json file on your domain so only your app can claim them. The return jump is an intent filter on your activity.

Desktop (Windows / macOS / Linux)

Standalone builds also open the system browser and deep-link back via a registered custom URI scheme, so the pattern matches mobile. The thing to be honest about on desktop is storage, not the redirect: a local user has full access to the machine, so keep the refresh token in an OS credential store where available, keep access tokens short, and keep sessions revocable.

WebGL

WebGL is the odd one out, in a good way. Your game already runs in the browser, so there's no separate app to jump into and no deep link at all — the OAuth redirect just returns to your page like any web app. The catch moves to storage: you can't keep a secret in a browser, since anything in local or session storage is readable by page scripts. For WebGL, lean on short-lived sessions and httpOnly cookies handled server-side rather than a client-held refresh token. Oathwall uses httpOnly Secure cookies on the web side for exactly this reason.

The one setup step that covers native platforms

The reason all of this stays manageable is that you configure the deep link once, not per platform by hand. In the Oathwall dashboard you set your app's scheme, path, package, and a fallback URL. After the token exchange, Oathwall's redirect page carries a single-use login ticket and launches the deep link into your game — and if the app can't open (not installed, wrong platform), it uses the fallback instead of dead-ending.

On the Unity side, the SSO Login Kit injects the intent filter into the Android manifest and the URL scheme into the iOS Info.plist at build time. You don't hand-edit platform files for each target; you build for the platform and the registration is already there. That's what lets one login manager compile and work across all of them.

A checklist before you ship everywhere

• Key accounts off user.id, not user.email. Some providers (Steam) never return an email, and a cross-platform player expects the same account regardless of where they signed in.
• Set the fallback URL. It's the difference between a graceful "open the app" page and a silent dead end when the deep link can't fire.
• Test each target's return path. The code is shared, but a missing verified-links file or an unregistered scheme fails quietly — confirm the round trip on every platform you ship.
• Match storage to the platform. Secure store on native, httpOnly cookies on web. Don't put a refresh token in PlayerPrefs anywhere.

FAQ

Shared code, why WebGL skips deep links, staying signed in on the web, and scheme support are covered in the section below.

Ready to ship everywhere?

Oathwall gives your Unity game one login manager that works on iOS, Android, desktop, and WebGL — deep links and web redirects handled for you, no client secret in any build. It's available on the Unity Asset Store.

Keep going: the Unity authentication guide for the full picture, deep linking in Unity for the return trip on mobile, and storing auth tokens in Unity for the per-platform storage rules.