If you've used Auth0, Okta, or any modern auth platform, most of this vocabulary will feel familiar. IntelliAuth's names are mostly the standard ones with one or two house-style choices noted below.
Organisation, tenant, application
Section titled “Organisation, tenant, application”The three-layer hierarchy that frames everything.
- Organisation — your company in IntelliAuth. One per IntelliAuth customer. Lives in the IntelliAuth admin console (
https://manage.<domain>), operated by your platform administrator. - Tenant — a sub-unit of your organisation. Usually one tenant per environment (production / staging / uat) or per product line. The tenant admin console you're using is a tenant's admin surface.
- Application — an OAuth/OIDC client registered against a tenant. Your team's web app, your iOS app, your nightly backend job — each is an application.
Pattern: one organisation → multiple tenants → multiple applications per tenant.
User and identity
Section titled “User and identity”- User — a person or service account that signs into one of this tenant's applications. Has an email, optionally a name, password (if your tenant accepts password auth), MFA factors, group memberships, attributes.
- Identity — how the user proves it's them. Could be a password, a Google / GitHub / Microsoft / Apple federated identity, a SAML assertion from an enterprise IdP, or a passwordless mechanism (passkey + email magic link).
A user can have multiple identities — for example, "signed up with password, later linked their Google account."
Group and role
Section titled “Group and role”The two ways to grant permissions in bulk.
- Group — a set of users. "Engineering", "Finance Admins", "Beta Testers". Membership is direct (a user is or isn't in the group); IntelliAuth doesn't support nested groups today.
- Role — a named bundle of capabilities. A role can be assigned to a group; everyone in the group inherits the role's capabilities.
Convention: define roles ("Treasurer", "Auditor", "Engineering Lead"). Define groups for the social structure ("Finance team"). Assign roles to groups. Membership of the group is what changes day-to-day.
Scope and capability
Section titled “Scope and capability”A small but important distinction.
- Capability — what a user / role / group can DO. "Read transactions", "Approve payments", "Manage applications". The conceptual model you reason with.
- Scope — the wire format. A short string (
payments:approve) included in the access token your applications receive. At runtime, your API checks "does this token's scope claim includepayments:approve?"
In the admin console you mostly work with capabilities. The scope strings appear in the JSON view + advanced fields; they're what the platform actually carries on the token.
MFA, factor, AAL
Section titled “MFA, factor, AAL”- MFA (multi-factor authentication) — the user proves two things instead of one. Password + something else.
- Factor — a specific second thing. WebAuthn / passkey, TOTP code, SMS code, backup code, custom factor.
- AAL (Authentication Assurance Level) — how strongly the platform thinks "this is actually the user". AAL1 = password alone; AAL2 = password + a second factor; AAL3 = strong phishing-resistant factor (WebAuthn / hardware key) on recent timestamp. Some sensitive actions in your apps may demand AAL2 or AAL3 — see step-up authentication on the developer side.
Session and token
Section titled “Session and token”- Session — a server-side record that says "this user is currently signed in to this tenant". Visible to the user in their own profile + to admins in the user detail page. Sessions can be revoked.
- Token — what the user's application actually carries on each API call. There are three kinds: access tokens (short-lived, prove identity to APIs), refresh tokens (longer-lived, used to mint new access tokens), id tokens (carry user claims, used at the OIDC sign-in moment).
Revoking a session kills the refresh token immediately; access tokens expire on their own within minutes.
Application and audience
Section titled “Application and audience”- Application — already defined above; OAuth/OIDC client.
- Audience — what the access token is "for". A logical identifier of the API the token will be presented to.
https://api.cymmetri.comis a typical audience.
The token's aud claim must match what the receiving API expects.
Flow, Action, pipeline
Section titled “Flow, Action, pipeline”- Flow — the sequence of steps that runs when a sign-in (or sign-up, or password reset) is initiated. Ships with sensible defaults; you customise by adding Actions.
- Action — a piece of JavaScript that you write, runs at a specific trigger point inside a Flow, and decides to continue / block / redirect / demand MFA.
- Pipeline — the platform-internal term for what a Flow runs on. You'll see it occasionally in audit events; you don't configure pipelines directly.
The classic examples: "Block sign-in for emails outside our domain" is an Action on the login flow's pre-credential-check trigger. "Sync new sign-ups to Salesforce" is a webhook subscription on user.signed_up (not an Action — webhooks fire after, Actions fire during).
Audit and event
Section titled “Audit and event”- Audit — the immutable record of every meaningful action in this tenant. Sign-ins, admin operations, configuration changes, security events.
- Event — one entry in the audit log. Has an actor, a target, an action, an outcome, a timestamp. Closed taxonomy of event types — your code can match on type strings.
Webhook
Section titled “Webhook”- Webhook — an HTTP push from the platform to a URL you control, fired when specific events happen. Your code receives the payload, verifies the signature, processes asynchronously. The integration surface for "react to things that happen in this tenant from your downstream systems."
Threat feed and risk
Section titled “Threat feed and risk”- Threat feed — an external (or custom) list of IP addresses + indicators the platform consults when scoring sign-in risk. FireHOL, Tor exit nodes, AbuseIPDB, plus any URL feed you point at.
- Risk score — what the platform computes per sign-in attempt. Drives adaptive policies — e.g., demand MFA if the score crosses a threshold even when policy is normally "MFA optional".
What you'll see most days
Section titled “What you'll see most days”Realistically, 80% of admin work happens in:
- Users (looking up a user, resetting their MFA, disabling a leaver)
- Applications (registering, rotating secrets, fixing redirect URI mismatches)
- Audit (investigating a failed sign-in spike)
- Authentication settings (tightening or relaxing MFA enforcement as your population evolves)
The rest you visit a few times a quarter.