OathWall

Unity Authentication Guides

Step-by-step guides for adding social login to your Unity game — Google, Apple, Steam, Discord, and more — with real code and no backend.

These guides cover one job end to end: adding real player login to a Unity game without standing up your own auth backend. Each one starts from the problem, walks through the actual provider setup (the console screens, the redirect URI, the scopes that trip people up), and shows the C# you'll really write — the same SsoClientBase / StartLogin / OnLoginSuccess pattern across every provider.

Start here

If you're new to this, read Player Authentication in Unity: The Complete Guide first. It maps out the three ways to add login to a game, where the tokens come from, and how the deep-link return trip back into your build works — so the per-provider guides make sense before you open a provider console.

Pick a provider

The provider guides each go deep on one login: real setup steps plus the quirks that aren't in the marketing copy. Sign in with Apple generates its client secret as a signed JWT and only sends the player's name on the very first authorization. Steam uses OpenID 2.0 and never returns an email. Facebook needs App Review before its email scope works outside your test accounts. Ten providers are covered, so most games find the two or three their players actually use.

Solve a specific problem

Some guides aren't about a single provider at all. Add login to your Unity game is the start-to-finish tutorial. Ship without a backend explains what the hosted service does for you and where a server still helps. Don't ship client secrets is worth reading before you release, and cross-platform login covers the per-platform deep-link differences on iOS, Android, desktop, and WebGL.

Beyond Unity

The packaged SDK is Unity's, but the login flow underneath is plain HTTP, so it isn't Unity-only. OAuth login without an SDK documents every endpoint — start, consume, refresh, and the deep-link return — so you can add the same social login to any engine. Godot OAuth login turns that contract into real GDScript with HTTPRequest and OS.shell_open.

Frequently asked questions

Do I need a backend server to follow these guides?
No. Every guide is written for the no-backend case — the player signs in through Oathwall's hosted flow and your game receives an access token, a refresh token, and a profile. If you already run a game server, the guides also show where to hand it the access token so it can authorize its own calls, but that's optional.
Will I have to ship a client secret in my Unity build?
No, and that's the point of most of these guides. Your build only carries a public appKey. The OAuth client secrets that providers like Google and Facebook require stay server-side in Oathwall, so decompiling your APK or IL2CPP build doesn't leak anything that lets someone impersonate your app.
Which provider guide should I start with?
Start with the one your players already use. Mobile-first games usually begin with Google (and Apple, which is mandatory on iOS if you offer any other social login). PC and storefront games lean toward Steam and Discord. If you're not sure how the pieces fit together first, read the pillar guide on Unity authentication before picking a provider.
Do these guides only work for Unity?
The code samples are Unity C#, but the login flow underneath is plain HTTP and works from any engine. The 'OAuth login without an SDK' guide documents every endpoint, and there's a Godot walkthrough in real GDScript. The packaged SDK is Unity-only; the service itself is engine-independent.