Identity for teams that read the docs first.

01 Overview

Algebrix Identity handles the parts of authentication that are expensive to build and dangerous to get wrong: credential storage, session management, multi-factor enrolment, token issuance, and an auditable record of administrative change.

The platform implements OAuth 2.0 and OpenID Connect as published. There is no proprietary SDK requirement and no custom handshake. Any conformant OIDC client library works against it, so integration effort is measured in configuration rather than in code, and migrating away is a matter of repointing an authority URL.

What this version covers

• Sign-in for single-page, native or mobile, and server-side web applications, using the authorization code flow
• Machine-to-machine access to your own services using the client credentials grant
• Single sign-on across every application in one organization
• Time-based one-time password (TOTP) multi-factor authentication, enforceable for administrators or for everyone
• Self-service applications created from four templates, with an integration view for each
• A management API for users, roles, required actions, password reset emails, invitations, CSV import and export, sessions, sign-in branding, the audit log, and sign-in activity
• Configurable sign-in security: password policy, brute-force protection, session and token lifetimes
• A hosted administration console for every organization, requiring no build effort of your own

The hosted console

There are two sign-in addresses for the console, one for each kind of administrator:

In the console, administrators can do the following:

• Manage users, roles, invitations, and sessions.
• Create and configure applications.
• Set authentication policy.
• Upload a sign-in logo.
• Review the audit log and sign-in activity.
• See usage against the plan.

The management API in section 08 covers user-facing operations programmatically. Automate what you want and leave the rest to the console.

02 Core concepts

Accounts, organizations, applications, users

Roles

Roles are exclusive: assigning one replaces the previous one.

Two surfaces

Algebrix Identity exposes two separate HTTP surfaces. They serve different purposes and are scoped differently. Confusing them is the most common cause of a failed first integration.

On the identity surface you state the organization, in the URL. On the management surface you do not: it is derived from the iss claim of the token you present, and every read and write is confined to that organization before any handler runs. There is no organization parameter to pass, and no way to reach another organization's data by changing one.

The same base URL, paths, and code serve every organization you run. Which organization you act on is decided entirely by which token you send.

One exception carries an identifier in the path: the anonymous public endpoint under /api/public/organizations/{organization}, which returns only a sign-in logo. It does not weaken the scoping guarantee, because it exposes nothing beyond a public image. See section 08.

Which credential reaches what

How a request flows

Your application never handles user credentials. The browser is redirected to the identity surface, the user authenticates there, and your application receives an authorization code, which it exchanges for tokens. Calls to the management surface carry the resulting access token as a bearer credential. The platform validates its signature against the organization's published key set before any handler runs.

03 Getting started

Signup

Signup at https://identity.algebrix.co/signup begins with the organization identifier. Because the identifier is permanent, decide on it before you start. There are two paths:

Payment details are handled entirely by Stripe. Card numbers never reach Algebrix systems.

Identifier format

Two behaviours to expect

Identifiers are case-sensitive. A request to /ACME-CORP/oauth2/keys returns 404, while /acme-corp/oauth2/keys succeeds. If a first attempt returns 404 on every endpoint, check the case of the identifier first.

An unknown identifier still returns a discovery document. Discovery for an organization that does not exist returns 200, because the platform does not confirm or deny which organizations exist. The endpoints inside that document return 404. If discovery succeeds but every later call fails, the identifier is misspelled.

What arrives with an organization

A new organization contains no customer applications. You create the applications you need from templates in the console (section 04).

The organization also holds one platform-managed application, which the hosted console uses to sign administrators in. It is not listed in the console, cannot be edited or deleted, and must not be used by your own applications.

Organizations created from this version onward enforce the Medium password policy and have brute-force protection off. Section 12 covers both settings.

More organizations, and deleting one

Account administrators can create further organizations from the console, up to the plan's organization allowance (section 11). At the allowance, creation is refused with a 409 that names the plan which lifts it.

Deletion is also driven from the console by an account administrator.

• It is a hard delete. The organization's users, applications, sessions, and settings are removed, and so are its audit records and sign-in activity. Its active-user figures for the current period are removed too. If you have retention obligations, export the audit log first (section 08).
• The last organization in an account cannot be deleted. To leave a paid plan, cancel the subscription instead.

04 Applications

An application is a client that signs users in, or that authenticates as itself. You create applications in the console from four templates. Each template fixes the grant, whether the application is confidential, and which addresses it accepts, so you choose a template rather than configuring raw client settings.

Sign-in redirect URIs

The redirect URI in an authorization request must match an address registered on the application, including scheme and port.

The same rules apply to every template:

• Wildcards may appear in the path only, never in the host. For example, https://app.example.com/* is accepted and https://*.example.com/cb is refused.
• The value + on its own is reserved and refused. A + inside a path is accepted.
• Empty values, values containing spaces, addresses with no host, and duplicates are refused.
• A list holds at most 20 addresses.
• There is no separate post-logout list. A post-logout redirect must be one of the application's sign-in redirect URIs. Register your signed-out landing page, for example your home page, as an additional sign-in redirect URI alongside your callback.

Each refusal names the rule, for example: Sign-in redirect URIs: 'https://*.example.com/cb' is not allowed. A wildcard may only appear in the path, never in the address itself.

Allowed origins

Only single-page applications have allowed origins, which are used for cross-origin requests to the identity surface. Each origin is a bare origin with no path, such as https://app.example.com. A list holds at most 20 origins. Server-side web and machine-to-machine applications do not accept origins.

Lifecycle

• The client ID is derived from the display name at creation and is permanent. For example, "Billing Portal" becomes billing-portal. The display name can be changed at any time; the client ID cannot. Always read the client ID from the console, not from a naming pattern.
• Secrets can be revealed and rotated in the console. Rotating a secret invalidates the previous one immediately. There is no period in which both are valid. Requests made with the old secret fail with unauthorized_client until every deployment uses the new one, so plan rotation for a maintenance window.
• An application can be deactivated.
• Deleting an application is permanent and ends its active sessions. The console shows the number of affected sessions before you confirm.
• Every application counts against the account's application allowance, machine-to-machine applications included (section 11).

Integration view

Each application has an integration view in the console. It shows the discovery URL, the exact issuer value to use as the authority, the client ID, and copy-ready curl and JavaScript snippets with your organization filled in. It is the quickest way to configure a client library.

05 Authentication and tokens

Grants

To reach the management API, a token must be a user token carrying the admin role in realm_access.roles. The user can be signed in through any application in your organization. The management API checks the issuer, signature, expiry, and role. It does not check which application the token was issued to. Machine tokens are refused with 403.

Configuring an OIDC client library

Most libraries need only an authority and a client ID, and discover everything else. The discovery document is at:

GET https://auth.algebrix.co/{organization}/.well-known/openid-configuration

Libraries that enforce strict OpenID Connect Discovery validation compare the issuer field of that document with the authority they were configured with, and refuse to start if the two differ. Configure these libraries with the exact published issuer value, which is also shown in each application's integration view:

// issuer value, use verbatim as the authority
https://auth.algebrix.co/realms/{organization}

Libraries differ here. Some accept the path form as an authority, and others, such as openid-client and angular-auth-oidc-client, refuse it with an issuer mismatch. The exact issuer value works with every library, so use it as the authority. Discovery returns the same document from either form, and the endpoints it lists are the documented /{organization}/oauth2/… paths.

Libraries in common use

The platform works with any conformant OIDC library. There is nothing to install from Algebrix. These are widely used and actively maintained:

Scopes

Request openid profile email. Other scopes advertised in the discovery document are not covered by support. See the note in section 07.

Client authentication

Confidential applications authenticate at the token endpoint with client_secret_basic (HTTP Basic) or client_secret_post (credentials in the form body). Both are accepted. Keep the secret server-side and out of source control.

Token claims

Access tokens are RS256-signed JWTs. Validate them against the key set published at the keys endpoint, and never trust an unverified token. Claims relevant to integration:

Validating tokens in your own API

When your service accepts Algebrix Identity tokens, it should:

1. Verify the signature against the keys endpoint. Select the key by the token's kid and accept only RS256 signatures; the key set also contains an encryption key, which is not for signature checks. Cache the keys and refresh them when you see an unknown kid.
2. Verify that iss equals your organization's issuer value exactly.
3. Verify exp.
4. If only certain applications may call your API, check azp against their client IDs. Because aud is the same on every token, it cannot do this job.

Validate tokens locally in this way. Token introspection is not available in this version. The resource-server/node-express sample (section 06) implements these checks.

Token lifetimes

Read expires_in from the token response rather than hardcoding a duration. An administrator can change the user token lifetime at any time.

Refresh tokens are not rotated. Each refresh returns a new refresh token value, and the previous one also stays valid until the session ends or is revoked. Store the latest one. Keep refresh tokens server-side, and never in browser-accessible storage.

Sign-out is shared across the organization. When a user signs out of any application in the organization, or the session reaches its idle or maximum limit, the next refresh in every application fails with invalid_grant and Session not active. Send the user back through sign-in.

Revocation

Know what each kind of revocation does before you rely on it:

• Revoking a refresh token through POST /oauth2/revoke stops it immediately. The next refresh fails with 400 invalid_grant.
• Revoking an access token does not stop the management API accepting it. The API validates tokens by signature and does not query the identity server on each request. A revoked access token stays usable until its exp.
• Revoking a session (section 08) signs the user out and stops their refresh token. An access token already issued from that session stays valid until it expires, which is at most the organization's access token lifetime.

06 Quickstarts

Every path starts the same way: create an application of the right type in the console, register its addresses, and copy its client ID from the integration view. These examples use the path form of the identity endpoints. Section 05 explains when to use the issuer value instead.

Sample applications

Runnable starter apps are published at github.com/algebrix/algebrix-identity-samples. They use the standard open-source OIDC libraries listed in section 05. They are not an SDK: there is nothing Algebrix-specific to install, and the code applies exactly the configuration this document describes. Each sample runs locally, uses placeholders for your organization and client ID, and states the documentation version it was tested against.

Download a single sample without cloning the whole repository:

npx degit algebrix/algebrix-identity-samples/<type>/<stack> my-app

# for example
npx degit algebrix/algebrix-identity-samples/spa/react my-app

Then follow the sample's README: create the matching application in the console, register the addresses it lists, and fill in your organization and client ID. Samples for further stacks and for native applications will be listed here as they become available.

Path A: sign a user in (single-page or native app)

GET https://auth.algebrix.co/{organization}/oauth2/authorize
  ?client_id={client_id}
  &redirect_uri=https://app.example.com/callback
  &response_type=code
  &scope=openid profile email
  &code_challenge={challenge}
  &code_challenge_method=S256
  &state={random_value}

POST https://auth.algebrix.co/{organization}/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id={client_id}
&code={code}
&redirect_uri=https://app.example.com/callback
&code_verifier={verifier}

{
  "access_token": "eyJhbGciOiJSUzI1NiIs...",
  "refresh_token": "eyJhbGciOiJIUzUxMiIs...",
  "id_token": "eyJhbGciOiJSUzI1NiIs...",
  "token_type": "Bearer",
  "expires_in": 300,
  "refresh_expires_in": 1800
}

Sample: spa/react and spa/angular implement this path end to end, including sign-out.

Path B: sign a user in (server-side web app)

Create a server-side web app and register its redirect URI. The flow is Path A, with two differences:

• The token exchange happens on your server and authenticates with the client secret, using either HTTP Basic or client_secret in the form body.
• PKCE is optional. Using it is recommended.

curl -X POST https://auth.algebrix.co/{organization}/oauth2/token \
  -u "{client_id}:{client_secret}" \
  -d "grant_type=authorization_code" \
  -d "code={code}" \
  -d "redirect_uri=https://app.example.com/callback"

Sample: server-side-web/node-express.

Path C: authenticate a service to your own API

Create a machine-to-machine application and copy its client ID and secret from the console. No addresses need registering.

curl -X POST https://auth.algebrix.co/{organization}/oauth2/token \
  -d "grant_type=client_credentials" \
  -d "client_id={client_id}" \
  -d "client_secret={client_secret}"

The response carries an access token with expires_in: 3600 and no refresh token. Your API validates the token as described in section 05, checking azp if it should accept only this application.

• Machine tokens are metered per calendar month against the account's allowance (section 11).
• They cannot call the management API.
• The secret must never reach a browser or a mobile binary.

Samples: machine-to-machine/node obtains and uses a machine token, and resource-server/node-express is an API that validates it.

Path D: call the management API

Sign in a user who holds admin through any application in your organization, using Path A or B. Then call the management API from server-side code with the resulting access token:

curl https://api.algebrix.co/api/admin/users?page=1&size=25 \
  -H "Authorization: Bearer {access_token}"

How to read the response:

• 200 returns one page of users in your organization, and only yours. No organization parameter is sent; the platform reads it from the token.
• 403 means the token is valid but the user does not hold admin, or the token is a machine token.
• 401 means the token was rejected before authorization. Read the WWW-Authenticate header for the reason.

07 OIDC endpoints

All paths below are relative to https://auth.algebrix.co/{organization}. The organization segment is required on every one of them.

08 Management API

Base URL https://api.algebrix.co. Every endpoint under /api/admin requires a user access token carrying the admin role (section 05). Every operation is scoped to the organization the token was issued for. Paths carry no organization segment, and none should be added. An identifier belonging to another organization resolves to 404, never to someone else's record.

Authorization: Bearer {access_token}

Conventions

Users

Paged results are ordered by username, ascending. There is no filter for multi-factor state; read mfaEnabled on each user instead.

Required actions and password reset

Invitations

Inviting someone creates their user account immediately, with no password, and emails them a link to choose one. They appear in the users list from that moment. Following the link proves the email address, so the account is marked verified when they finish. An invitation's status is derived from the account: pending until the password is set, accepted after, and revoked if withdrawn. Invitation links are valid for 72 hours.

Import and export

Import file rules

Sessions

Revoking a session signs the user out and stops its refresh token immediately. An access token already issued from that session remains valid until it expires, which is at most the organization's access token lifetime (accessTokenLifespanSeconds in the list response). For a suspected compromise, revoke the sessions and disable the user.

Some further details:

• A session used across several applications appears once.
• Offline sessions are not included.
• A session's id equals the sid claim of tokens issued from it.

Branding

The logo appears on the organization's sign-in and multi-factor enrolment pages, at a fixed height. It does not appear in emails, which carry a text header only. Colours, backgrounds, and wording are configured by Algebrix on request.

Audit log and sign-in activity

Two separate trails are kept:

• The audit log records administrative actions, such as creating a user, changing a role, rotating a secret, or changing billing.
• Sign-in activity records authentication events.

Both are kept for the plan's retention window (section 11). Each response carries retentionDays, so read the window from there rather than hardcoding it.

More about both trails:

• Every entry names the person who acted. Refused or failed operations write no entry.
• Metadata keys are camelCase.
• A user's own activity (/api/admin/users/{id}/activity) deliberately shows both kinds together: their sign-ins alongside the actions taken on them.

09 Schemas

AdminUser

{
  "id": "a87a5de8-1ab3-4716-b86a-3104f3f277f2",
  "username": "david.lee",
  "email": "[email protected]",
  "firstName": "David",
  "lastName": "Lee",
  "enabled": true,
  "roles": ["end-user"],
  "mfaEnabled": false,
  "createdAt": "2026-09-18T08:15:54.42Z",
  "lastSignInAt": "2026-09-19T11:02:10.503Z"
}

AdminUserPage

{
  "items": [ /* AdminUser */ ],
  "page": 1,
  "size": 25,
  "totalCount": 312,        // null when filtered by role
  "totalPages": 13,         // null when filtered by role
  "hasNextPage": true,
  "signInHistoryDays": 90   // the per-user activity window
}

CreateUserRequest

A new user holds no role until one is assigned with PUT /api/admin/users/{id}/role.

UpdateUserRequest

UserDetail

{
  "user": { /* AdminUser */ },
  "isLastAdministrator": false,
  "signInHistoryDays": 90,
  "applicationsInUse": ["billing-portal", "mobile-app"]
}

applicationsInUse lists client IDs. Check isLastAdministrator before disabling, deleting, or changing the role of an administrator, so the organization is not left without one.

Invitation

{
  "id": "7a5a5053-8d98-4909-bde7-d4e3e3dddc10",
  "email": "[email protected]",
  "role": "end-user",
  "status": "pending",
  "invitedBy": "[email protected]",
  "createdAt": "2026-09-25T08:18:18.7939597Z",
  "lastSentAt": "2026-09-25T08:18:18.7939601Z",
  "acceptedAt": null,
  "revokedAt": null,
  "emailDelivered": true
}

SessionList

{
  "sessions": [
    {
      "id": "w9rZQFadZ0Zyqo8_t7PJsLq_",
      "userId": "a87a5de8-1ab3-4716-b86a-3104f3f277f2",
      "username": "david.lee",
      "ipAddress": "203.0.113.10",
      "startedAt": "2026-09-25T08:16:14Z",
      "lastAccessAt": "2026-09-25T08:16:14Z",
      "applications": ["billing-portal"]
    }
  ],
  "accessTokenLifespanSeconds": 300,
  "truncated": false
}

applications lists client IDs.

AuditPage

This shape is returned by the audit log, sign-in activity, and per-user activity endpoints.

{
  "items": [
    {
      "id": "cd147816-…",
      "timestamp": "2026-09-25T08:21:11.764Z",
      "actorUserId": "a87a5de8-…",
      "actorUsername": "david.lee",
      "action": "LOGIN_FAILURE",
      "targetUserId": null,
      "targetUsername": null,
      "metadata": { "error": "invalid_user_credentials" }
    }
  ],
  "totalCount": 15,
  "page": 1,
  "pageSize": 20,
  "totalPages": 1,
  "retentionDays": 90,
  "ingestionIntervalSeconds": 30   // 0 on the administrative log, written synchronously
}

CsvPreview

{
  "fileName": "users.csv",
  "totalRows": 4,
  "validRows": 3,
  "remainingStoredUsers": 9992,
  "shortfall": null,
  "failures": [
    { "line": 3, "username": "g.two", "email": "not-an-email", "firstName": "G",
      "lastName": "Two", "role": "end-user", "reason": "'not-an-email' is not a valid email address." }
  ],
  "failureReportCsv": null
}

CsvCommit

{
  "fileName": "users.csv",
  "totalRows": 3,
  "created": 2,
  "failed": 1,
  "failures": [ /* as in CsvPreview */ ],
  "failureReportCsv": "username,email,firstName,lastName,role,error\r\n…"
}

LogoInfo

{
  "hasLogo": true,
  "contentType": "image/png",
  "width": 240,
  "height": 80,
  "byteSize": 296,
  "updatedAt": "2026-09-25T08:33:17.5027867Z"
}

10 Errors

Response bodies differ by failure type. Handle every shape below rather than assuming a single envelope, and branch on the status code and on the machine-readable fields, not on message text. Messages are written for people and may be reworded.

Message body

This shape is used for business-rule refusals with 400, 404, 409, and 502:

{
  "message": "Your plan (Free) includes 3 applications and you have 3. Starter includes 10.",
  "upgradeLifts": true
}

upgradeLifts is true only when moving to a higher plan removes the refusal, and false for every other refusal. Use it to decide whether to route a person to upgrading.

Validation Problem Details

This shape is returned for malformed input, such as an invalid email format, a missing required field, a missing upload, or malformed JSON:

{
  "type": "https://tools.ietf.org/html/rfc9110#section-15.5.1",
  "title": "One or more validation errors occurred.",
  "status": 400,
  "errors": { "Email": ["The Email field is not a valid e-mail address."] },
  "traceId": "00-cdb2562e8941de77...-86ee0d1ec5ff51e3-00"
}

404 Not Found

Most not-found responses use the message body, for example {"message": "User not found.", "upgradeLifts": false}. GET /api/admin/users/{id} returns an RFC 9457 Problem Details object instead:

{
  "type": "https://tools.ietf.org/html/rfc9110#section-15.5.5",
  "title": "Not Found",
  "status": 404,
  "traceId": "00-df7c6aa7...-00"
}

Handle both shapes by status code.

401 Unauthorized

The body is empty. The diagnostic is in the response header, per RFC 6750:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="invalid_token",
  error_description="The issuer '...' is invalid"

With no token at all, the header is simply Bearer. An empty body here is expected behaviour, not a fault.

402 Payment Required

{
  "message": "A payment failed and the grace period has ended, so administrative changes are paused. Update your payment details in Billing to resume, or contact [email protected].",
  "billingState": "grace_expired"
}

billingState is one of trial_failed, grace_expired, or canceled. See section 11.

Diagnosing a failed call

11 Plans, limits, and billing

Allowances belong to the account and are shared across all of its organizations. Current usage against every allowance is shown in the console.

Scale is a negotiated plan: its figures are included amounts, not ceilings, and never block.

How each allowance is measured and enforced

Plan changes

Plan changes are made in the console by an account administrator. You can move between paid plans and switch between monthly and annual billing.

• A downgrade is refused if current usage exceeds the target plan, and the refusal names the dimension.
• Moving from a paid plan to Free is not possible. Cancelling is the exit from a paid plan.

Billing restrictions

If a subscription goes unpaid, administrative changes are paused. Nothing else is. Understand this before you build, because it determines what your integration can and cannot do in that state.

What pauses is every write under /api/admin: creating, updating, disabling, or deleting users; roles and required actions; password reset emails; invitations; CSV import, including the dry run; session revocation; logo changes; and clearing multi-factor enrolment. Each returns 402. Writes resume automatically, within about a minute of a successful payment.

• The restriction is account-wide. One unpaid subscription pauses writes in every organization of the account.
• A trial that ends without a successful payment restricts writes immediately, reported as trial_failed.
• When an established subscription's payment fails, there is a seven-day grace period from the first failure, during which everything works normally. After that, it is reported as grace_expired. Retries do not extend the grace period.
• A cancelled subscription is reported as canceled.
• Organizations on an invoiced agreement, including Enterprise, are billed separately and are never restricted.

Administrators see the current state, and the date on which access will be restricted, in the console. If your operations team monitors integrations rather than the console, treat a 402 as the signal to check billing.

12 Security settings and the end-user experience

Administrators configure these settings per organization in the console. Changes take effect immediately and are recorded in the audit log. They are not available through the API in this version, but they change what your users and your integration experience, so they are documented here.

Password policy

• New organizations use Medium. Organizations created before this default was introduced have no password policy until an administrator selects one, and the console says so.
• A policy applies when a password is next set or changed. Existing passwords are not re-checked, and nobody is forced to change theirs.
• Rules beyond the three levels, such as a longer minimum or a blocklist, are configured by Algebrix on request.

Brute-force protection

Brute-force protection is off by default. When it is on, an account is locked temporarily after a number of consecutive failed sign-ins, and while it is locked even the correct password is refused. Each further failure doubles the lockout, up to the maximum. Administrators see locked accounts in the console and can unlock them. The list can lag by up to 30 seconds.

Session and token lifetimes

Some constraints link these settings:

• The maximum session length cannot be shorter than the idle sign-out.
• An access token never outlives its session.
• The access token lifetime is also how long a revoked session's last access token remains usable, which is why it is capped at one hour.

Multi-factor authentication

• Turning enforcement off does not remove anyone's authenticator.
• Enforcement is independent of the per-user CONFIGURE_TOTP required action, which works in every mode.
• A TOTP code is single-use. The code used to enrol cannot also be used to sign in within the same 30-second window, which can look like a failed sign-in during testing.

Self-registration

Self-registration is off by default. When it is on, a Register link appears on the organization's sign-in page, and people who register count towards the plan's user allowances. Email verification can be required for people who register. Invited people already prove their address by following the emailed link.

What your users see

• Sign-in and enrolment pages carry the organization's logo, if one is uploaded.
• There is no end-user account page. https://auth.algebrix.co/realms/{organization}/account returns 404. Users change their password through the "Forgot password?" link, a password reset email, or an UPDATE_PASSWORD required action.
• Users enrol an authenticator only when enforcement or a CONFIGURE_TOTP required action asks them to. They cannot enrol or remove one on their own initiative; an administrator clears an authenticator for recovery. Managing your own authenticator in Account settings is available to account administrators only.
• The set-password page lists the organization's rules before the person types.
• A dead, expired, or revoked link shows a plain message asking for a new link. A mistyped password at sign-in shows the same message.
• After setting a password, the person sees a Back to the application link. It goes to one of the organization's applications that has a concrete, non-wildcard redirect URI registered. Without one, it goes to the organization's console address, which a non-administrator cannot use. Register at least one concrete redirect URI so that invited and reset users land in your application.
• A person invited with an email address only is asked for their name before finishing. They are not signed in automatically; they sign in afterwards.

Emails your users receive

• The sender name is the organization's display name, from [email protected], with replies going to [email protected].
• Every body names the organization, but subjects cannot include it, which is a platform constraint.
• The set-password email includes the full sign-in address for the user's organization and their username, as they will type it.
• Emails carry no remote images.
• Signup verification and account administrator emails are sent by Algebrix Identity and do not name an organization.

13 Scope and behaviour

What the platform does and does not do, stated plainly so that evaluation does not turn up surprises.

Not available in this version

Operational notes

• HTTPS only. Plaintext HTTP is not served on any endpoint.
• Organizations share nothing. Users, credentials, sessions, roles, signing keys, and audit records belong to exactly one organization.
• User identifiers are stable. The id field and the sub claim are the same value and never change. Usernames and email addresses can change, so do not key on them.
• Client IDs are permanent. Display names can change.
• Disable rather than delete where the audit trail must keep resolving an account. User deletion is permanent, and there is no undelete.
• Deleting an application ends its sessions. Deleting an organization destroys its audit trail, so export first.
• Authentication is never gated on billing or on machine token allowances. User sign-in continues in every subscription and quota state.
• Sign-in activity arrives within 30 seconds, not in real time.

Standards implemented

OAuth 2.0 (RFC 6749), Bearer Token Usage (RFC 6750), PKCE (RFC 7636), Token Revocation (RFC 7009), JSON Web Token (RFC 7519), OpenID Connect Core 1.0, and OpenID Connect Discovery 1.0. The authorization core is Apache-2.0 licensed and standards-conformant. No proprietary protocol extension is required for integration, and there is no lock-in at the protocol layer.

Versioning and support

API paths carry no version segment, and this document is versioned instead. Version 2.1 describes the platform as of September 2026. Changes that would break an existing integration are published as a new major version of this document; minor versions add guidance and clarifications.

Version 2.1 adds the sample applications and clarifies secret rotation, post-logout redirects, the roles claim, refresh token behaviour, signing key selection, and common error responses. Token introspection is no longer listed as available.

For support, write to [email protected]. For a specific failed call, include the traceId where one is returned.