X (Twitter) Login in Unity (OAuth, no backend)

X (Twitter) login fits games with a social pulse — titles where players share clips, brag about scores, or follow a community that lives on X. This guide wires it up with OAuth, no backend, and covers the single developer-portal setting that decides whether you ever see an email address.

When X login fits

X is a sharing-and-community identity. It fits games where players post highlights, follow creators, or belong to a fanbase that's active on X. If your loop involves sharing, "Sign in with X" connects naturally to that. For a general audience, though, X reaches fewer players than the mainstream providers, so offer it beside Google or Apple rather than alone.

Step 1: Create an X developer app

1. Go to the X Developer Portal and create a project and app.
2. In the app's User authentication settings, set the Callback URI to exactly:

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

3. Enable "Request email address from users." This is the setting people miss — without it, X never returns an email, no matter what your app requests later.
4. Copy the Consumer Key (API Key) and Consumer Secret (API Secret).

Step 2: Paste your credentials into Oathwall

In the Oathwall dashboard, add X (Twitter) as a provider and paste the Consumer Key and Consumer Secret. They stay server-side; Oathwall signs the request and reads the profile for you. Because the email depends on that portal setting, double-check step 1.3 is enabled before you test.

Step 3: Wire it up in Unity

Same base class, same single call as every other provider:

using PixitGames.SSOLoginKit;

public class LoginManager : SsoClientBase
{
    // Consumer Key/Secret stay on Oathwall's servers.
    // Email needs the portal setting enabled (see step 1).
    public void OnXButton() => StartLogin("twitter");

    protected override void OnLoginSuccess(LoginResult user)
    {
        // user.email may be empty even with the setting on.
        LinkPlayer(user.id, user.name);
    }
}

StartLogin("twitter") opens X's authorization page in the system browser. Oathwall signs the request, exchanges credentials, and reads the account — user.id is X's stable account id, user.name is the display name, and user.email is the verified address when the app is allowed to request it.

The gotchas worth knowing

The email setting is a hard gate. X only returns an email if "Request email address from users" is enabled in the developer portal and the account has a verified email. If that toggle is off, the email is always empty — this is a portal configuration issue, not a code one, and it's the single most common reason X login "loses" the email. Turn it on, then still write for the null case and key player records on user.id. That's the same discipline Facebook demands with its App Review email permission.

The classic flow is OAuth 1.0a, and that's fine. The email-returning path uses OAuth 1.0a with request signing (hence "Consumer Key" and "Consumer Secret"). Oathwall does the signing server-side, so from Unity it's the same one-line StartLogin call as every OAuth 2.0 provider. If you want the mental model of what's happening underneath, OAuth 2.0 explained covers the general flow, and the signing is just an older variant of the same idea.

It's a social add-on, not a primary login. X reaches the community that's active there and misses everyone else. The usual pattern is X beside a mainstream provider. The Unity authentication guide shows several providers sharing one login class, so adding X is one more StartLogin call.