Troubleshooting Game Hub login deep links and Game App / QR login flows

This article explains how Aghanim login behaves when using player_id deep links, token-based authorization, mobile Sign in via Game App, and desktop QR-code login.

player_id deep links require the Player ID login method

If you send players to the Hub with a URL like https://<GAME_HUB_DOMAIN>/go/login?player_id=<UNIQUE_PLAYER_ID>, that flow depends on the Player ID login method being enabled for the game.

If Player ID is disabled and only Game App / QR code is enabled, the Hub cannot complete the auto-login. In that case, the user may see an authentication error or be sent to the standard login screen instead.

Options

• Quick fix: enable Player ID in the Dashboard under Game → Settings → Customization → Login.
• Recommended approach: use the token-based authorization flow described in the Auth via Game guide. This is the native mechanism behind the Game App / QR code login method and works without enabling Player ID.

Is nonce required?

For a direct server-to-server authorization flow, nonce is optional.

nonce is used by the desktop QR-code flow so the waiting desktop session can detect when authorization has completed. If you are authorizing a user directly from your backend and do not need that desktop-session tracking behavior, you can omit nonce.

Mobile browser: why does “Sign in via Game App” open a new tab?

In the mobile flow, after the player authenticates in the game app, the returned authorization_url may open in a new browser tab. This is expected behavior of the flow.

In that case:

• the new tab becomes the signed-in Hub session, and
• the original tab that started the login request may remain on its loading screen until it is refreshed manually.

The original tab does not currently auto-complete in the same way as the desktop QR flow.

Desktop QR login behavior

In the desktop QR-code flow, the desktop browser completes login separately from the phone. Once the game calls authorize, the desktop session is updated over its waiting connection.

At the same time, the phone may also open the Hub after authentication because the shared return handler opens the authorization_url there as well. As a result, both the desktop and mobile browser can end up opening the Hub.

Can I distinguish desktop QR from same-device mobile login?

Today, one possible implementation detail is to inspect the nonce value:

• desktop / QR requests use a nonce shaped like base64 of uuid:d
• same-device mobile requests use a nonce shaped like base64 of uuid:m

If you rely on this, note that:

• you should distinguish specifically between :d and :m, not just whether a nonce exists, and
• generated nonces may omit trailing = padding, so you may need to restore padding before base64-decoding.

Also consider keeping a fallback path in case the desktop login did not finish successfully (for example, if the desktop tab was closed or its connection dropped).

If you need a stable product-level signal for flow type in the authorize response, contact support.