Branded sign-in experience
Control the player-facing login, account recovery and launcher navigation without moving password handling into gameplay code.
Game launcher authentication
Authenticate in the launcher and pass a validated session into the game.
Keep credentials, login, recovery and account UX in the launcher. When a player starts a game, LauncherForge provides a short-lived launch token that the runtime integration validates before exposing the minimal player session.
- ✓Short-lived launch tokens
- ✓Credentials stay in the launcher
- ✓Runtime fields: id, email, valid
Secure Access
LauncherForge
Do not rebuild the complete account system inside every game.
Launcher authentication and game runtime identity solve different problems. LauncherForge keeps the credential flow in the launcher and gives the packaged game a narrow validation contract for each launch.
Authentication boundary
Do not rebuild the complete account system inside every game.
Launcher authentication and game runtime identity solve different problems. LauncherForge keeps the credential flow in the launcher and gives the packaged game a narrow validation contract for each launch.
Short-lived launch token
Generate a temporary launch session when the player starts the selected game rather than handing the game reusable account credentials.
Runtime validation
Validate the launch token from the packaged game through the LauncherForge integration before initializing authenticated gameplay state.
Minimal player contract
Expose only the runtime values currently required by the game session: id, email and valid.
Engine integrations
Use dedicated integration paths for Unreal Engine and Unity while keeping the authentication concept compatible with other runtimes.
Launcher-scoped access
Keep player access connected to the launcher, selected game and release workflow instead of treating authentication as an unrelated website login.
Launch session
Four steps from player login to validated game identity.
The handoff is deliberately small so launcher credentials never need to become permanent secrets inside the packaged game.
- 01SIGN IN
The player authenticates in the launcher.
The launcher owns credentials, recovery and account-facing UI.
- 02REQUEST
A launch token is issued for the game start.
The session is temporary and associated with the launch context.
- 03START
The launcher starts the packaged game.
The token travels with the startup flow rather than a password or permanent account secret.
- 04VALIDATE
The game validates and reads the session.
The integration confirms the token and exposes id, email and valid to runtime code.
Small runtime contract
Give the game identity, not credentials.
A short-lived launch token reduces the amount of account state the packaged game needs to understand and keeps sign-in UX centralized in the launcher.
Launch session response
POST /launch/validate
token: <short-lived>
response: 200
id: usr_01J8M6GQ
email: player@example.com
valid: true ✓
Connect auth to distribution
Authentication becomes more useful when it shares the launcher workflow.
The same launcher can resolve player access, the release branch, installation state and the game session that starts afterward.
Launcher authentication FAQ
Questions about launch tokens and player sessions.
The goal is to keep account credentials out of the packaged game while still giving runtime code a validated player identity.
Does the game receive the player password?+
No. Password handling stays in the launcher. The packaged game receives a short-lived launch token for validation.
What does the game receive after validation?+
The current minimal runtime contract exposes id, email and valid.
Why use a short-lived launch token?+
It limits the session handoff to a specific launch flow instead of giving the packaged game a reusable account credential.
Can this work with Unreal Engine?+
Yes. LauncherForge provides an Unreal integration path for validating the launch token after the runtime initializes.
Can this work with Unity?+
Yes. Unity can use the runtime session integration pattern while the player-facing login remains in the launcher.
// Centralize player sign-in
Let the launcher own authentication and the game own gameplay.
Use a small validated launch session to connect player identity to the packaged game without duplicating credential flows.