ONE1 developer docs
A secure OpenID Connect integration for letting people use their ONE1 account on your website. This guide follows the same authorization-code and PKCE pattern used by major identity providers.
1. Register
Add exact HTTPS redirect URLs and request approval.
2. Build the flow
Send users to ONE1 with state, nonce and S256 PKCE.
3. Validate securely
Exchange the one-time code on your server and verify tokens.
Client ID: YOUR_CLIENT_ID
Client type: Web server (private client, secret required)
Registered callbacks: Add a callback in Settings before integrating.
ONE1 matches redirect URLs exactly, including scheme, hostname, path, port and trailing slash. Do not use wildcards.
Issuer / discovery: https://www.one1.gg/.well-known/openid-configuration
Authorization: https://www.one1.gg/oauth/authorize
Token: https://www.one1.gg/api/oauth/token
UserInfo: https://www.one1.gg/api/oauth/userinfo
Revoke: https://www.one1.gg/api/oauth/revokeUse the discovery document as the source of endpoint URLs. Do not hardcode a second issuer or assume that production and staging share clients.
Choose SPA when all code runs in the browser. Choose Web server when your backend can keep a client secret. Add one exact callback per environment, for example separate local, staging and production URLs. Request only the permissions your feature needs.
An application is not usable until it is active and approved. If a callback or scope is changed, update the registration and wait for the resulting approval state before testing.
Generate a cryptographically random verifier, state and nonce for every login attempt. Store state and the verifier in a short-lived, same-session store. Create the S256 challenge from the verifier, then redirect the browser:
GET https://www.one1.gg/oauth/authorize?client_id=YOUR_CLIENT_ID&redirect_uri=https%3A%2F%2Fyour-site.example%2Fauth%2Fcallback&response_type=code&scope=openid%20profile&state=RANDOM_STATE&nonce=RANDOM_NONCE&code_challenge=S256_CHALLENGE&code_challenge_method=S256Always include openid. Available ONE1 scopes are openid, profile, email, one1.profile.public, one1.vrfs.id, one1.discord.uid and any additional namespaced one1.* permission requested in the developer console, subject to admin approval. Never put a client secret in browser code.
If the ONE1 account has MFA enabled, ONE1 pauses authorization and requires the user to complete the authenticator step before consent can finish. Your app must wait for the normal callback; do not treat a pending or denied response as a successful login, and do not create a local session until the code exchange succeeds.
Do not build a second MFA system around ONE1. ONE1 owns the challenge, recovery and assurance decision.
On your callback endpoint, reject errors, verify state matches the value created before redirecting, and require a code. Exchange it once. For Web clients, send the secret only from your server. For SPAs, send the PKCE verifier.
POST https://www.one1.gg/api/oauth/token
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
client_id=YOUR_CLIENT_ID
redirect_uri=https%3A%2F%2Fyour-site.example%2Fauth%2Fcallback
code=ONE_TIME_CODE
code_verifier=ORIGINAL_VERIFIER
# Web clients also send client_secret server-sideCodes are short-lived and single-use. On success, validate the ID token before creating your app session: signature, issuer, audience, expiry, nonce and the stable sub claim. Use sub as the account key; never use email as the unique identifier.
openid enables OIDC identity. profile allows approved public profile fields. email allows the verified email claim. one1.profile.public is for the ONE1 public-profile contract. one1.vrfs.id returns the verified vrfs_id claim, and one1.discord.uidreturns the verified discord_uid claim. If an account has not linked that service, that claim is omitted. The user sees the consent screen, and ONE1 may return only approved scopes. For a new capability, request a descriptive namespaced scope such as one1.clips.publish and explain exactly why it is needed; approval grants the scope to the integration, not automatic access to unrelated ONE1 data. Common read-only data permissions include one1.fixtures.read, one1.matches.read, one1.leagues.read, one1.teams.read and one1.rankings.read.
{
"sub": "pairwise-id-for-your-app",
"name": "Member",
"email": "member@example.com",
"vrfs_id": "5528190",
"discord_uid": "123456789012345678"
}Ask for the smallest scope set possible, protect tokens like passwords, and never log authorization codes, access tokens, ID tokens or client secrets.
access_denied
The user cancelled or the application cannot proceed. Do not sign them in.
invalid_request
A required parameter is missing or malformed; inspect the request.
invalid_client
The client is unknown, inactive or not approved.
invalid_grant
The code, redirect URI or PKCE verifier is wrong, expired or already used.
redirect_uri_mismatch
The callback is not an exact registered URL.
invalid_scope
The scope is not approved for this application.
Show a useful local error, clear the one-time URL parameters, and let the user retry. Never display raw tokens or secret material.
The supplied test app builds its callback as window.location.origin + window.location.pathname, so its current Vercel deployment must register this exact URL:
https://testing-orpin-iota-12.vercel.app/If you later add a dedicated callback route, register that full route instead (for example https://testing-orpin-iota-12.vercel.app/auth/callback) and update the app to use the same value. The root URL is correct for the current test app because its callback handler runs on the root page.