How to Add Login to Your Unity Game

You've got a game and you want players to sign in — to save progress, show a name, gate a purchase. This is the practical version: enable one provider, write the handful of lines Unity needs, and test the whole thing in a browser before you ever make a build. No auth server, no password fields.

If you want the wider picture first — the three ways to do auth and why each provider behaves differently — the Unity authentication guide is the map. This page is the walk-through.

What "add login" actually involves

Adding login isn't one job, it's three, and most tutorials only show you the easy one.

1. The button and the code in your game. This is the part people expect, and it's genuinely small.
2. The OAuth exchange — trading the provider's authorization for a real player identity. This needs a client secret and a web redirect, which is the part a game can't safely do itself.
3. Getting the result back into the running game across the platform you ship on.

Roll your own and you own all three. With a hosted service, you write the first one and configure the other two. That's the trade this guide makes: you'll do step 1 in Unity and click through steps 2 and 3 in a dashboard.

Step 1: Create an app and enable a provider

In the Oathwall dashboard, create an app for your game. You get a public appKey — the only identifier your build carries, and safe to expose.

Then enable one provider. Google is the usual first choice: it returns a verified email on every platform, which keeps your account model simple to start. You'll paste your own Google Client ID and Client Secret into the dashboard — Oathwall uses your Google app so the consent screen shows your game's name, and that secret stays server-side. The full walk-through for the Google side is in Add Google Sign-In to Your Unity Game; every provider you might add later has its own guide with the exact fields.

The one value to get right is the redirect URI you register with the provider:

https://sso.oathwall.com/auth/callback

It has to match character for character — no trailing slash, https not http. Off by one and the provider returns redirect_uri_mismatch before login even starts. If you want to understand why that value is what it is, what a redirect URI is explains it in a few minutes.

Step 2: Test it in the browser first

Here's the step that saves you an hour of rebuilds. Before you touch Unity, confirm your provider credentials actually work by running the flow in sandbox mode. Append &sandbox=true to the start URL:

https://sso.oathwall.com/auth/google/start?appKey=YOUR_KEY&sandbox=true

Open that in a browser, sign in, and instead of deep-linking into a game the flow lands on sandbox.oathwall.com with a single-use ticket. POST the ticket to /auth/sandbox/consume and you get the resolved profile back — provider, email, name, picture — with no tokens issued and no game build required.

If that returns your profile, your credentials are correct end to end. If it errors, you're debugging a dashboard field, not your Unity code, which is a much shorter loop.

Step 3: Wire it up in Unity

Now the part you came for. Your login manager inherits from SsoClientBase, calls StartLogin with the provider name, and overrides OnLoginSuccess:

using PixitGames.SSOLoginKit;

public class LoginManager : SsoClientBase
{
    // Hook this to your UI button.
    public void OnLoginButton() => StartLogin("google");

    protected override void OnLoginSuccess(LoginResult user)
    {
        Debug.Log($"Signed in as {user.name}");
        // user.id · user.email · user.provider
        // Use user.id as the stable key for your save data.
    }
}

That's the whole client integration. StartLogin("google") opens Google's real sign-in page in the system browser, the SDK handles the deep link back into your game, exchanges the ticket for a session, and calls OnLoginSuccess with a LoginResult. You take user.id and hang your profile, cloud save, or entitlement off it.

Two more calls are worth knowing on day one. SilentLogin() in Start() resumes a saved session so returning players don't see a login screen every launch. And CreateProviderButtons() builds the login UI from whichever providers you enabled in the dashboard, so the screen updates when you flip one on without a code change.

Adding a second provider later

The payoff shows up when your first login works and you want another option. Adding Apple, Steam, or Discord isn't a second integration — it's the same class with a different string:

public void OnGoogleButton() => StartLogin("google");
public void OnAppleButton()  => StartLogin("apple");
public void OnSteamButton()  => StartLogin("steam");

The one thing to plan for: not every provider returns an email. Google does, Steam never does. If your account system assumes an email always exists, Steam breaks it — so key your accounts off user.id, not user.email, from the start.

FAQ

The common questions — testing before a build, starting with one provider, and what a login returns — are answered in the section below.

Ready to add it?

Oathwall gives your Unity game player login across Google, Apple, Steam, Discord, and more, with no backend and no client secret in the build. It's available on the Unity Asset Store.

From here, follow the Google setup guide for your first provider, see the whole landscape in the Unity authentication guide, or start with what single sign-on means for a game if the vocabulary is new.