OAuth 2.0 - Managing Applications

Overview

An OAuth application allows a tool or integration to access Kion on a user's behalf. Creating an application does not grant it access on its own. Each user signs in to Kion with their own credentials and authorizes the application to act on their behalf. The application uses an access token to make requests without receiving the user's password.

An application's access is limited by both its authorized scopes and the permissions of the user who authorizes it. Registering an application does not give it independent permissions or allow it to perform actions the user cannot perform.

Applications can be created manually using the Create Application page or registered automatically by compatible tools through Dynamic Client Registration. See this page for more information.

Configuration

Name and Description

Enter an Application Name and, optionally, a Description. Choose wording that clearly identifies the tool requesting access and its intended use. These fields can use names and descriptions that suit your organization, but should be closely tied to the application's purpose so users can recognize what they are authorizing.

For example, use a name such as "Engineering CLI" with a description such as "Allows engineers to interact with Kion from the command line."

Application Type

Choose an application type based on who will use the application:

• Personal: Choose this when you plan to use the application yourself. Only you and authorized administrators can see and manage it.

• Global: Choose this when the application will be shared with multiple users. It is accessible to users with permission to browse or manage applications. Each user still authorizes access using their own credentials, and requests on their behalf are limited by their own permissions.

The application type selector is available to users with permission to manage global applications. Users limited to managing their own applications create personal applications.

Grant Types

Grant types determine how users authorize the application. Select at least one grant type, and enable only the flows the application supports and requires.

Authorization Code

Authorization Code is the standard flow for most use cases, including web applications and browser-based clients. The application redirects the user to Kion to sign in and authorize access, then sends the user back to the application with an authorization code. The application exchanges that code for an access token.

When selecting this flow, configure Redirect URIs with the callback addresses provided by the application, one URI per line. These are the locations where Kion sends users after authorization.

Device Code

Device Code is suited to command-line interfaces (CLIs), headless tools, and devices that cannot complete a browser redirect. The tool displays a code and a URL. The user opens the URL in a browser, signs in to Kion, and authorizes the request while the tool waits for approval.

This flow still requires a user to sign in and authorize access, even when the tool itself runs without a browser.

Scopes

Permission Scopes limit which Kion interfaces an application can access on a user's behalf. Effective access is the intersection of the scopes authorized for the application and the user's existing Kion permissions. Scopes do not grant additional user permissions.

For example, selecting API access does not allow an application to modify a resource that the authorizing user only has permission to view.

Select scopes based on the application's requirements:

• MCP access: Allows access to Kion's Model Context Protocol (MCP) endpoints. Select this for applications, such as compatible AI assistants, that interact with Kion through MCP.

• API access: Allows access to Kion's public and private API endpoints. Select this for tools and integrations that call Kion APIs directly.

Select both only if the application requires both interfaces. Leaving both unselected grants no Kion access.