OAuth 2.0 - Endpoints

Last updated: October 16, 2026

Overview

When you connect a tool or integration to Kion with OAuth 2.0, it needs Kion's authorization server endpoints, such as the authorization URL and the token URL. This article lists those endpoints and the settings an OAuth client needs.

To create the application that your integration authenticates as, see OAuth 2.0 - Managing Applications.

Endpoints

All OAuth endpoints are under /api/oauth2 on your Kion URL. Replace <your-kion-url> with the address you use to reach Kion, for example kion.example.com.

Endpoint

URL

Authorization

https://<your-kion-url>/api/oauth2/authorize

Token

https://<your-kion-url>/api/oauth2/token

Device authorization

https://<your-kion-url>/api/oauth2/device_authorization

Token revocation

https://<your-kion-url>/api/oauth2/revoke

Userinfo

https://<your-kion-url>/api/oauth2/userinfo

JSON Web Key Set (JWKS)

https://<your-kion-url>/api/oauth2/keys

The issuer identifier is https://<your-kion-url>/api.

Discovery

Clients that support automatic discovery can be configured with the metadata URL instead of entering each endpoint by hand. Kion publishes its metadata at both standard locations:

  • OpenID Connect discovery: https://<your-kion-url>/api/.well-known/openid-configuration

  • OAuth 2.0 Authorization Server Metadata (RFC 8414): https://<your-kion-url>/.well-known/oauth-authorization-server/api

Both URLs return the same document. It lists every endpoint, along with the supported scopes and client authentication methods.

Client Settings

Grant Types

Use the grant type that you enabled on the application in Kion:

  • Authorization Code: For web applications and browser-based clients. The redirect URI your client sends must exactly match one of the Redirect URIs configured on the application.

  • Device Code: For CLIs, headless tools, and devices that cannot complete a browser redirect. The client requests a code from the device authorization endpoint, and the user approves it in a browser.

Refresh tokens are available with either grant. See Scopes below.

PKCE

Kion supports Proof Key for Code Exchange (PKCE) with the S256 code challenge method. We recommend PKCE for all Authorization Code clients, and it should always be used by public clients that cannot keep a client secret.

Client Authentication

At the token endpoint, clients can authenticate with:

  • client_secret_basic: The client ID and secret in an HTTP Basic Authorization header.

  • client_secret_post: The client ID and secret in the request body.

  • none: For public clients, which send only the client ID. Use PKCE with public clients.

Scopes

Scope

Purpose

api

Access to Kion's public and private API endpoints.

mcp

Access to Kion's Model Context Protocol (MCP) endpoints.

offline_access

Issues a refresh token so the client can get new access tokens without the user signing in again.

openid, profile, email

Standard OpenID Connect scopes for identifying the signed-in user.

Request only the scopes the integration needs. An application's access is always limited to the scopes it was authorized for and the permissions of the user who authorized it.

Example: Authorization Code Flow

  1. Send the user to the authorization endpoint:

    https://<your-kion-url>/api/oauth2/authorize?response_type=code&client_id=<client-id>&redirect_uri=<redirect-uri>&scope=api%20offline_access&state=<state>&code_challenge=<challenge>&code_challenge_method=S256

  2. The user signs in to Kion and approves the request. Kion redirects to your redirect URI with a code parameter.

  3. Exchange the code for tokens:

    curl -X POST "https://<your-kion-url>/api/oauth2/token" \

    -u "<client-id>:<client-secret>" \

    -d grant_type=authorization_code \

    -d code=<code> \

    -d redirect_uri=<redirect-uri> \

    -d code_verifier=<verifier>

  4. Use the returned access token as a bearer token on Kion API requests:

    curl -H "Authorization: Bearer <access-token>" "https://<your-kion-url>/api/v3/..."