id_token vs access_token (for Game Developers)

id_token and access_token sound interchangeable and are not. One says who the player is; the other says what a request is allowed to do. Confusing them is behind a whole category of login bugs — and in the Oathwall model, one of these tokens never even reaches your game. Here's the distinction, and what your Unity code actually holds.

Identity vs permission

An id_token comes from OpenID Connect, the identity layer on top of OAuth. It's a signed statement — a JWT — that asserts who someone is: claims like a stable subject id, and often email and name. It's meant to be read once, by the app that asked for it, at the moment of login. Think of it as a signed ID card.

An access_token is pure OAuth. It's the credential you present to do something — call an API, fetch a resource. It answers "is this request allowed," not "who is the person." Think of it as a key card that opens certain doors.

The rule that follows: don't use an id_token as an API key, and don't try to read identity out of an access token. An access token may be opaque (just a random string with no readable contents), so parsing it for a user id is unreliable at best. Send the id card to prove identity; use the key card to open doors. Mixing them is the root of "my login works but my API calls 401," or worse, an API that accepts an id_token it should have rejected.

Where the confusion comes from

Both are often JWTs, both arrive around login, both are "tokens." So people grab whichever one is handy and send it everywhere. Two failure modes dominate:

1. Sending the id_token to an API. The API wants an access token as its bearer credential. A strict API rejects the id_token; a lax one accepts it, which is a security hole because id_tokens aren't scoped for that.
2. Reading identity from the access token. When the access token is opaque, there's nothing to read — and even when it's a JWT, its claims are about authorization, not a profile you should trust for display.

What Oathwall actually returns

Here's the part specific to Oathwall, and it removes the question entirely.

The provider's id_token — the one Google or Apple issues — is consumed on Oathwall's servers. When a player signs in with Google, Oathwall reads and verifies that id_token server-side to learn who they are. Your game never sees it.

What your game receives is Oathwall's own access_token (a short-lived signed JWT) plus a refresh_token. There is no separate id_token in the response — you don't get one and you don't need one. To read the player's identity, you send the access token as a bearer token to /auth/me, and Oathwall returns the profile:

GET https://sso.oathwall.com/auth/me
Authorization: Bearer <access_token>

→ { id, email, name, picture, provider, linkedProviders }

So the mental model collapses to: the access token both authorizes your calls to Oathwall and is how you look up the player (via /auth/me), while the identity-asserting id_token stays server-side where it's verified. In Unity, the SDK does the /auth/me step for you and hands you the result as a LoginResult:

using PixitGames.SSOLoginKit;

public class LoginManager : SsoClientBase
{
    public void OnLoginButton() => StartLogin("google");

    protected override void OnLoginSuccess(LoginResult user)
    {
        // Resolved profile — no id_token parsing on your side.
        Debug.Log($"{user.id} · {user.email} · {user.provider}");
    }
}

For the companion distinction — how the access token relates to the long-lived credential that renews it — read access tokens vs refresh tokens. To put the whole flow together, the Unity authentication guide is the hub.