GGaming APIDashboard
Developer security center

Authentication

Authentication is the layer that establishes who is making a request. Authorization then determines what that identity is allowed to do. This guide explains the authentication model, credential types, session security and real-time connection patterns for Gaming API.

Important: Never place private API keys, service credentials or privileged tokens in browser JavaScript, public repositories or client-side HTML.
ID

Identity

Establish the identity of a user, developer or trusted application before protected operations are allowed.

AC

Authorization

Authentication alone does not grant permissions. Every sensitive operation should be authorized against the authenticated identity.

TK

Credentials

Use appropriately scoped credentials and keep their lifetime and exposure as small as practical.

AU

Auditability

Security-sensitive events should be observable through safe logs and operational monitoring without recording secret values.

02 · Credentials

API keys

API keys identify an integration. Treat them as secrets whenever the key grants access to protected resources or operations.

API KEY Server-side request pattern

Send credentials through an HTTPS authorization mechanism defined by your deployed API contract. The exact header name and endpoint should match the production API documentation.

Authorization: Bearer YOUR_API_KEY
Do not: hard-code a production key into frontend source code. Browser users can inspect it.
03 · Tokens

Access tokens

Short-lived access tokens are commonly used when an authenticated session needs temporary access to protected API resources.

01 · AuthenticateVerify the user or application.
02 · IssueCreate a short-lived access credential.
03 · AuthorizeValidate the token on protected requests.
04 · RefreshRenew through a protected refresh flow when supported.
fetch('/api/resource', {\n headers: {\n Authorization: 'Bearer ACCESS_TOKEN'\n }\n})
04 · Sessions

Session management

Expiration

Sessions should expire after an appropriate period and sensitive actions may require renewed authentication.

Revocation

Users should have a way to invalidate active sessions when a device is lost or suspicious activity is detected.

Device awareness

Where supported, display useful session metadata so users can recognize active devices and locations.

Cookie security

For cookie-based sessions, use secure server-side settings such as Secure, HttpOnly and an appropriate SameSite policy.

05 · Strong authentication

MFA & passkeys

A password or primary credential can be compromised. Additional authentication factors and phishing-resistant passkeys provide stronger account protection.

Multi-factor authentication

Use a second factor when available, especially before sensitive developer actions such as credential management.

Passkeys

Passkeys can provide a modern phishing-resistant sign-in experience using public-key cryptography.

Recovery

Recovery mechanisms should be protected carefully because a weak recovery path can undermine strong authentication.

Step-up authentication

Consider requesting stronger verification again before high-impact security or account operations.

06 · Real-time

WebSocket authentication

Real-time connections require their own authentication strategy. Never place long-lived privileged secrets in a public WebSocket URL.

const socket = new WebSocket(\n 'wss://YOUR-AUTHORIZED-HOST/realtime'\n);\n\n// Authenticate using the mechanism defined by\n// the production WebSocket contract.
Recommended principle: authenticate the connection using a short-lived or appropriately scoped credential and validate authorization for protected subscriptions or actions on the server.
07 · Troubleshooting

Authentication errors

401 · Unauthenticated

The request does not contain valid authentication credentials, or the credential has expired.

403 · Forbidden

The identity was recognized but is not authorized to perform the requested operation.

429 · Rate limited

Too many requests were received. Respect server-provided retry guidance and implement backoff.

5xx · Service error

A server-side failure occurred. Retry only when appropriate and avoid aggressive retry loops.

08 · Security checklist

Authentication best practices

Keep secrets server-side

Private credentials belong in secure server-side configuration, never in public frontend bundles.

Use HTTPS / WSS

Encrypt authentication traffic in production and never send credentials over plain HTTP.

Rotate credentials

Replace credentials periodically or immediately after suspected exposure.

Least privilege

Grant only the permissions required by each integration and separate credentials by environment.

Validate every request

Do not rely on the frontend to enforce permissions. Re-check authentication and authorization server-side.

Protect logs

Never log passwords, full API keys, access tokens or other secrets.

Production rule: if a credential can authorize a privileged server operation, assume that credential must remain inaccessible to ordinary browser users.
Service state

Authentication service monitor

Checking public site availability…

Last check: —

FAQ

Common questions

Should an API key be stored in frontend JavaScript?

No. A user can inspect browser source, network requests and bundled JavaScript. Privileged keys should be kept server-side.

Is authentication the same as authorization?

No. Authentication answers who you are. Authorization determines what that identity can access or do.

What should happen if an API key is exposed?

Revoke or rotate it immediately, investigate where it was exposed and issue a replacement with the minimum required permissions.

Can WebSocket connections be authenticated?

Yes. The production implementation should define how the connection is authenticated and how subscriptions or protected actions are authorized.