Authentication

Aigon accepts three kinds of credential. Which one you hold depends on how you connect:

Type	Lifetime	Used by
OAuth access token	Short-lived (~1 hour), auto-refreshed	MCP Server (the normal way in)
Short-lived MCP token	10 minutes by default, 1 hour at most	MCP clients that cannot do OAuth themselves
API token (existing only)	Permanent — never expires, no refresh	CLI, REST API

OAuth tokens are issued automatically during the browser consent flow. New API tokens are not currently issued. The Telegram Auth Bot no longer hands one out and the AigonOne web app no longer has a Generate button. API tokens that were issued earlier keep working.

API tokens

An API token is a permanent credential for the CLI and the REST API. They are no longer issued to users: sending /get or /reset to the Telegram Auth Bot, or /auth reset on WhatsApp, does not produce one, and the AigonOne web app can no longer generate one.

If you already hold an API token it keeps working, and you can still manage it:

Open a1.aigon.ai, click your profile icon and select API Token to see whether you have one and to delete it.
Or send /accounts unlink apitoken yes to any Aigon bot to remove it.

Treat an API token as you would a password: anyone who has it has full access to your account.

MCP clients without OAuth

If your MCP client cannot run the OAuth browser flow, sign in with an OAuth-capable client first (Claude Code or Claude Desktop, for example) and call admin.mint_curl_token there. It returns a short-lived bearer token (10 minutes by default; ask for up to 3600 seconds) that you hand to the other client or script. It expires by itself, and admin.revoke_curl_tokens kills every live one at once.

The token carries no more access than the session that minted it, it cannot mint another, and it is valid on the MCP server (mcp.aigon.ai) only — the REST API at api.aigon.ai refuses it. See Connecting MCP servers for the full steps.

OAuth

The REST API (api.aigon.ai) implements a full OAuth 2.1 authorization server. The AigonOne web app (a1.aigon.ai) acts as the browser-facing rendering proxy — it handles login and consent UI, but all OAuth logic and state lives in the REST API.

This is used by the MCP Server. When an MCP client first connects, it opens a browser window for login and consent — no manual token handling required. Every MCP consumer (Claude Code, Claude Desktop, or any other MCP-compatible client) runs the same flow.

How it works

The MCP client discovers the OAuth metadata from a1.aigon.ai
It registers dynamically with api.aigon.ai/oauth/register
A browser window opens at a1.aigon.ai/oauth/authorize for login + consent
A1 proxies the authorization to api.aigon.ai, which issues the code
The client exchanges the code for tokens at api.aigon.ai/oauth/token

Endpoints

Endpoint	Host	Purpose
`/.well-known/oauth-authorization-server`	a1.aigon.ai	Metadata discovery
`/oauth/authorize`	a1.aigon.ai	Browser login + consent
`/oauth/register`	api.aigon.ai	Dynamic client registration
`/oauth/token`	api.aigon.ai	Token exchange
`/oauth/revoke`	api.aigon.ai	Token revocation

Standards

OAuth 2.1 with Authorization Code + PKCE (RFC 7636)
Dynamic client registration (RFC 7591)
Authorization server metadata (RFC 8414)
Access tokens are short-lived (~1 hour), refresh tokens ~30 days

Using a Token You Already Have

A token is sent as a Bearer token in the Authorization header:

Authorization: Bearer YOUR_TOKEN

CLI

If you already hold an API token:

aigon config set api.token YOUR_TOKEN

New API tokens are not currently issued, so there is at present no way for a new user to obtain one for the CLI.

REST API

An API token you already hold works as a Bearer token. A short-lived MCP token does not: the REST API refuses it.

curl -H "Authorization: Bearer YOUR_TOKEN" \
  https://api.aigon.ai/health

MCP Server

OAuth handles this automatically — no manual token configuration needed.