I IntelliAuth Docs

An application is an OAuth/OIDC client registered against your tenant. Your web app, your mobile app, your backend job, your SAML integration — each is an application with its own client_id, redirect URIs, allowed scopes, and configuration.

You'll spend time here whenever:

  • A developer asks for a client_id for a new product they're building.

  • An application's client secret has leaked and needs rotation.

  • A redirect URI changed because your app moved hosts.

  • An app should no longer receive tokens (disable; later, delete).

  • Audit asks "what apps issue tokens against our tenant?"

The list view

Applications in the sidebar. The default view shows every application in the tenant: name, type, state (enabled / disabled), client_id (truncated), created-at.

Filters along the top:

  • Type — SPA / M2M / Native / Server-side / SAML. The full taxonomy is in Application types.

  • State — Enabled / Disabled.

  • Search — substring match against name + description + client_id.

Multi-select supports bulk operations — disable all selected, enable all selected, delete all selected. See Bulk operations.

Detail view

Click any row to open the application's detail page. You'll see:

  • Header — name, type, state, client_id (copyable). State chip is clickable to enable / disable.

  • Action menu (top right) — rotate secret (if applicable), disable, delete.

  • Settings tabs:

    • General — name, description, type, audience.

    • URLs — redirect URIs, allowed origins, logout URLs.

    • Scopes — the allowlist for what this client can request.

    • Tokens — access-token TTL, refresh-token TTL, rotation policy.

    • Secrets — current client secret status, rotation history.

    • Tags — free-form labels for your own organisation.

    • SAML (only for SAML apps) — entity ID, ACS URL, certificate, attribute statements.

  • Audit summary at the bottom — the last few configuration changes to this application, with actor + timestamp.

Every field on the detail page is in-place editable: click, edit, save. Each save is one audit-log entry.

Lifecycle

draft  →  enabled  →  disabled  →  deleted
                ↑           ↓
                └───────────┘   (toggle freely)

  • Draft — created but not yet published. Rare; happens if you start a registration and abandon it before save.

  • Enabled — the normal state. The client can request tokens.

  • Disabled — soft-stop. The client cannot request new tokens. Existing tokens it has already issued remain valid until expiry. Refresh attempts fail. Toggle back to Enabled at any time.

  • Deleted — hard removal. The client_id is never reused. Cannot be undone.

The transition between Enabled and Disabled is the operationally-useful toggle. Reach for Disabled before Delete when you're not sure something can be torn down.

Application vs user

Applications are NOT users. An application doesn't sign in; it requests tokens. Users sign in; applications authenticate them. Users live under Users.

A user can be associated with an application only in the sense of "this user signed into this application at this time" — captured in audit, not as a hard relation.

Application vs tenant

Each application belongs to exactly one tenant. There's no concept of a cross-tenant application. If you have a "production app" and a "staging app", each lives in its own tenant.

Linked guides

See also