What it is

TessariDB OAuth signs people in to your own applications. Each tenant, called a company in the console, has an issuer of its own at <PUBLIC_URL>/<company>, with its own signing keys, clients, users and audit trail.

Status. 0.1.0, the first release. Image tessaridb/oauth:0.1.0.

What it serves

• The protocol. Discovery and the key set per company; authorization with pushed requests (PAR); the token endpoint for authorization codes, refresh tokens and client credentials; revocation; UserInfo; RP-initiated and back-channel logout. See Protocol.
• Sign-in. Passwords, authenticator apps (TOTP), recovery codes and passkeys; password resets, enrolment links, address verification and changes of sign-in address by mail; self-registration when a company allows it. See Signing in.
• The account portal. Users see and change their own profile, sign-in factors, sessions and the applications they gave access to. See The account portal.
• The admin console. Companies, users, groups, clients, operators, sign-in policy, branding, mail wording, signing keys and the audit trail, on a listener of its own. See The admin console.
• Regions. Each company lives in one home region; a request for it elsewhere is redirected there. See Regions.

The promises it keeps

Each of these is implemented and covered by tests in 0.1.0.

• One browser flow. Authorization code with PKCE S256 (RFC 7636). The implicit flow, token-returning hybrid flows and the password grant are not offered.
• Redirect URIs match exactly, with only the native-app loopback port exception (RFC 8252 §7.3).
• A code redeems once. Of any number of simultaneous redemptions exactly one succeeds; a code presented again revokes the refresh family it started.
• A reused refresh token revokes its family.
• Tokens bound to a key when the client asks: DPoP (RFC 9449), keys named by their JWK thumbprint (RFC 7638).
• No shared secrets. A confidential client authenticates with private_key_jwt; the console offers no way to make a client secret.
• Nothing secret in a log. A message never carries a token, code, verifier, assertion or proof.
• Every issuance is on the record, and one that cannot be recorded is not answered.
• A second factor that stays. Passkeys, authenticator apps and recovery codes, chosen by the user or required by the company, and never removed by a mail link alone.

Where its state lives

Everything the server keeps is a record in TessariDB: companies, users, credentials, clients, codes, grants, consents, refresh families, sessions, signing keys sealed under a key-encryption key, queued mail, replay and throttle counters, and the audit trail. There is no second store beside it, so a backup of the TessariDB node is a backup of the server, apart from two key files kept outside it (see Backup and restore).

The server needs TessariDB 0.38.2 or later.

What it leaves out

• Shared client secrets and the grants OAuth 2.1 removes.
• Federation. It does not sign users in through another identity provider.
• Contact claims. UserInfo releases a user's names and groups, not their address or phone number.
• A second approval for company-wide changes in the console: one operator makes them.

Licence

TessariDB OAuth is licensed under the Business Source License 1.1. Production use is free, including use by and within a commercial company. Offering it to others as a hosted or managed identity, authentication or authorization service, or selling, renting or sublicensing it, needs a commercial licence. Each version converts to the Apache License 2.0 on the change date in its LICENSE. Write to licensing@tessaridb.com for other arrangements.