Skip to content
IntelliAuth

Applications overview

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

Section titled “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

Section titled “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.
  • Tabs:
    • Credentials — Integration Endpoints (OIDC Discovery URL, Issuer URL, client_id), client secret status and rotation, Quick Start code snippets.
    • Settings — General (name, description, type, audience, tags), Redirect URIs, Token Lifetimes.
    • Access — Login Methods for browser apps (which sign-in flows the application accepts), or Capabilities for M2M applications (Resource · Action picker).
  • 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

Section titled “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

Section titled “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

Section titled “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

Section titled “Linked guides”