five-on-it / apps/api/src/auth
apps/api/src/auth
Accounts (TECHNICAL_SPECS §9.6). Two providers behind one interface:
dev: accounts made on sight, for local development and the tests. A guest is its device id, a user is their e-mail (any password); the sessions are HS256 tokens this API signs.nakama: the accounts of a Nakama server, through its REST API (device sign-in for guests, e-mail sign-in for creators, the server key as basic auth); its session tokens are checked with the session encryption key the API shares with Nakama, so a request costs no round trip. Nakama's usernames are unique: a new account whose name is taken gets the name with a short random suffix.
Guests may play; creating needs a full account.
A Steam account (signed in with a ticket of the app or through Steam's OpenID, both checked by the API: steam-routes.ts) is an account of its own, keyed steam-<steamid64>: a dev account of that id, a Nakama account of that custom id (custom authentication, not Nakama's own Steam one, so the ticket and OpenID paths are one). An e-mail account may link a Steam account: signing in through it then lands in the e-mail account (Nakama links the custom id to it; the dev provider keeps no links, so the API names the account).
Both also issue the OAuth access tokens (oauth.ts): a session of their own kind for an account already signed in, an hour long, carrying the grant it belongs to (gid), so every route takes it as any session and the API refuses it once the grant is revoked. Nakama's are signed with the session key the API shares with Nakama, in Nakama's claims.