Applications
Applications represent pieces of software or services that are authorized to interact with the system (similar to OAuth clients).
They allow external or internal software components to authenticate and perform actions under controlled permissions.
This is an advanced topic and is only required for very custom use cases
The Applications view in the Admin Portal is where administrators can see and manage software identities that interact with the system.
Why Applications Matter
💻Applications act like clients in an OAuth/OpenID model.
🔐They authenticate to the system using credentials (e.g. client_id / client_secret) and then, with assigned policies, are allowed to perform actions or access data.
What This Means for You as a Technical User?
👩💻You usually won’t need to create applications — that is done during integrations or by developers.
❗However, understanding that applications exist helps you interpret logs, troubleshoot integrations, and understand how external systems connect.
👀If changes are needed (e.g. adding policies, unlocking an application), you’ll know where to look and what to expect.
What Can Applications Do?
While most users will not need to create or manage applications, the Admin Portal supports the following operations:
List / View Applications
See all registered applications and their details.
Create Application
Register a new software client with properties like name, vendor, version, and generate credentials.
Generate/Reset Secret
Create or reset the secret (password/key) for an application to authenticate.
Edit Application
Update application metadata (name, version, vendor, etc.).
Lock / Unlock / Reset Security State
Prevent an application from authenticating if it fails too often, or unlock it when needed.
Assign / Remove Policies
Customize which policies (grant, deny, elevate) the application holds.
Key Concepts & Fields for Applications
Here are some fields you’ll see when inspecting an application:
Client ID / Name
The unique identifier for the application (acts as client_id).
Software Name / Vendor / Version
Metadata that identifies the software owner, version, and vendor.
Secret / Secret Key
The credential (like a password) that the application uses to authenticate.
Lockout / Security State
Tracks failed authentication attempts; may lock the application if thresholds are exceeded.
Assigned Policies
The set of policies this application is allowed or denied; these control its access.
How Applications Get Permissions?
When a new application is created, by default it inherits policies from a general APPLICATIONS group.
After creation, those default policies can be overridden or customized via the Policies panel.
Policy permission types supported include:
Grant — the application is allowed to perform the action/data access.
Deny — the application is explicitly denied.
Elevate — requests are denied by default, but may prompt for override (e.g. ask for justification).
When a policy is removed from an application, if no explicit grant is assigned, the system falls back to default denial (unless a user’s group grants it).
References & Further Reading
(Refer back to Policies documentation when assigning permissions.)
Last updated