Accounts and SSO

.sso ports the old PHP .back API to Node.js. New service source does not automatically disable PHP. Legacy wire compatibility, a redesigned login flow and client migration are separate stages.

Browser login without application keys

The fetched SSO development branch implements a separate cookie-auth router. Browsers send no client ID, application key or application secret:

Route	Request/purpose
POST /auth/login	JSON login/password; sets an HttpOnly cookie, returns account, access_token and csrf_token
GET /auth/session	Cookie; restores account and short-lived access token
POST /auth/logout	Cookie and X-CSRF-Token; revokes session and clears cookie
GET /auth/profile	Cookie; self profile
GET /auth/projects	Cookie; accessible projects/servers, with v2 DTO under additional security review
POST /auth/network-token	Cookie, X-CSRF-Token, project_id/server_id; scoped personal token
GET /auth/steam/start	mode=login or link; Steam redirect, link requires a session
GET /auth/steam/callback	Validated Steam callback only; redirects to configured done URL

Every POST requires an allowed Origin; logout/network-token also require a session-bound CSRF token. Use credentials: include and restore through /auth/session. JavaScript cannot read the HttpOnly cookie; keep access tokens in memory, not passwords or session credentials in localStorage.

Outside explicit HTTP loopback development, the cookie is __Host-ozsso with Secure, HttpOnly, SameSite=Lax and Path=/. Loopback development uses ozsso. Shared database state holds sessions and rate limits. Logout prevents session refresh; issued access tokens retain their bounded lifetime. Password recovery changes auth hash and invalidates the account version.

SSO issues RS256 personal tokens for at most five minutes, with issuer/audience, sub, scope account/panel, ver, iat, exp, jti; panel scope includes pid/sid. Network acceptance needs its own verifier and configured trusted public key. Network commit 50e0478 adds common/SsoAuth.js, HTTP Bearer and personal Socket.IO account/panel scope. It validates a configured local public PEM, algorithm, issuer/audience/kid, expiry, claim types and fresh account version. Source and focused fixtures exist; complete browser and production acceptance remain separate.

Registration, recovery and Steam

Keyless routes: POST /auth/register/send-code, /auth/register/confirm, /auth/register, /auth/restore/send-code, /auth/restore/confirm, /auth/restore/find, /auth/restore. See OpenAPI for fields; key identifies the existing contact/confirmation flow, not a browser application secret. SSO supplies registration application credentials on the server.

Steam login requires an already linked account. Linking requires the current session and does not merge unrelated accounts. Source checks the fixed provider, exact return_to/claimed_id, server-side check_authentication, expiring one-use state and nonce. These are reviewable controls, not a guarantee of no vulnerabilities or a fixture proving login to a person's actual Steam account.

At this snapshot, review found remaining hardening: the v2 projects DTO needs a dedicated allowlist rather than removing one field, and concurrent Steam linking needs a shared atomic invariant. The SSO owner is implementing these fixes. Routes and checks above do not establish completed security acceptance.

Implemented surface

The user flow covers sign-in, registration, account recovery, profile and selecting an available project. Permitted browser routes are listed in SSO HTTP API; internal integrations and legacy aliases are not public APIs.

Current protocol

Routes accept /methods/group.method with JSON/urlencoded/form-data. Query and body merge, with body taking precedence. Responses retain PHP shapes:

{"status":"success","response":{}}

{"status":"error","error_name":"token_invalid","error_msg":"..."}

This differs from Network error: {name, message}. Prefer translated backend names/messages over an uninformative unknown_error.

Compatible /methods/front.Auth requires client_id, user_login, user_password, client_key. With api_v=2, application fields are plain over HTTPS and keys are checked without the old XXXX-XXXX format rule. Without api_v, legacy ApiEncrypt remains. Both are compatibility APIs for existing applications; new browser login uses /auth without application keys.

Security and migration

The service checks application access, account/auth hash, blocked/deleted state and method permissions. Separate PHP golden tests check crypto/name compatibility; HTTP/MySQL scenarios have their own fixtures. Tests existing in a repository do not establish a complete system migration.

Fixes over PHP include restricting private fields to the account owner, verified-contact registration, rejecting account deletion after exhausted code attempts and consuming recovery codes. Application secrets stay in environment configuration. Unsupported third-party token IDs fail closed.

Before switching clients, verify login → profile → Network token → panel connection, logout, recovery and expiry. Central accounts and Network's project subscription are not one table or one token.

Sources: .sso/src/app.js, src/methods, src/legacy/validator.js, response.js, docs/legacy-route-coverage.md, README. Source version snapshot.