Authentication in Unity Without a Backend

"Do I need a backend to add login?" is one of the first questions a solo dev or small team asks, usually right after realizing an auth server is a real project on its own. The honest answer: you don't need your backend. A server still has to do the confidential part of OAuth — but it doesn't have to be one you build, deploy, or keep alive at 3 a.m. This explains what that server actually does and how to ship Unity login without running one yourself.

What a backend normally does for auth

Two very different jobs hide under "auth backend," and conflating them is why this feels bigger than it is.

The roll-your-own job. If you build email-and-password login, you need a server to store password hashes, verify them on sign-in, run "forgot password" emails, and issue sessions. That's a database, an email pipeline, and a security surface you're now responsible for. This is the job most people picture, and it's the one that scares them off.

The OAuth job. If you use "Sign in with Google" instead, there's no password to store — the provider verifies the player. But OAuth still requires a confidential client: a server that holds your client secret and performs the token exchange after the player approves. This part is small, but it can't run in the game, because a client secret can't ship in your build.

Social login deletes the first job. It does not delete the second — it relocates it. The whole "no backend" trick is letting someone else run the confidential client.

Why the game can't just do it itself

It's tempting to think a modern game could handle OAuth directly and skip the middle entirely. Two hard walls stop that.

The first is the secret. OAuth's authorization-code flow expects the code-for-token exchange to be authenticated with a client secret. Ship that secret in your build and it's extractable from the binary in minutes — public, and useless as a secret. There's PKCE to harden public clients, and it helps, but several providers still require a secret on the token exchange regardless.

The second is the redirect. OAuth is built around a web redirect to a URL the provider trusts. A game isn't a web server sitting at a stable https:// address, so you need a real endpoint to catch that callback and then a deep link to get the result back into the running app. That endpoint is server work by definition.

So a server is in the picture no matter what. The only question is whether it's yours.

The no-backend version

With a hosted OAuth service, the confidential client is the service's server, not yours. Concretely, the flow is three HTTPS calls and no infrastructure on your side:

1. Your game opens https://sso.oathwall.com/auth/{provider}/start?appKey=YOUR_KEY.
2. Oathwall runs the full OAuth exchange with the provider — secret, token swap, all of it — server-side.
3. Your game receives an access_token and refresh_token and reads the player from /auth/me.

Your build carries only the public appKey. The client secret lives in Oathwall's dashboard and never leaves its servers. There's nothing for you to deploy, scale, or patch.

On the Unity side the whole thing collapses to one class, and the SDK does the three calls for you:

using PixitGames.SSOLoginKit;

public class LoginManager : SsoClientBase
{
    // No server of yours is involved in this call.
    public void OnLoginButton() => StartLogin("google");

    protected override void OnLoginSuccess(LoginResult user)
    {
        Debug.Log($"Signed in: {user.name} ({user.email})");
        // user.id is your stable player key.
    }
}

StartLogin opens the system browser, the exchange happens on Oathwall's servers, the deep link brings the result home, and OnLoginSuccess fires with the player's identity. You never wrote a route, a token endpoint, or a session store.

When you do still want a backend

"No auth backend" doesn't mean "no backend ever." Plenty of games have a server for good reasons — authoritative multiplayer, an in-game economy, anti-cheat, cloud saves you won't trust the client to write. If that's you, you still skip the auth server. Let Oathwall verify who the player is, then have your game send the access_token to your own backend, which trusts Oathwall's identity and authorizes its own calls. You get identity for free and spend your server budget on the part that's actually your game.

That split — hosted identity, your own game logic — is the common shape for a studio that outgrows "just a login button." If you're not there yet, you don't need any of it.

FAQ

Whether "no backend" is real, what a server normally does, and when you'd still want your own are covered in the section below.

Ready to skip the server?

Oathwall runs the confidential OAuth work so your Unity game doesn't have to. No auth server, no client secret in the build — just a few HTTPS calls and a player identity back. It's available on the Unity Asset Store.

Next: see the full flow in the Unity authentication guide, understand the exchange in OAuth 2.0 explained for game developers, or read why client secrets can't ship in your build.