Skip to main content
Xquik supports OAuth 2.1 Authorization Code with S256 PKCE for remote MCP authentication. Modern clients discover the flow automatically from https://xquik.com/mcp, open Xquik login and consent in a browser, then store and refresh Bearer tokens.
Prefer OAuth for Claude, ChatGPT, Cursor, VS Code, Windsurf, OpenCode, Gemini CLI, GitHub Copilot CLI, Cline, Qwen Code, and other compatible remote MCP clients. Use the client compatibility matrix for Codex, Goose, Roo Code, and Pi. Xquik accepts API keys only when the client documents secure header storage.
Affected Codex releases discard the RFC 9207 iss value before token exchange. Xquik already returns that value. If Codex reports Authorization server response missing required issuer: expected https://xquik.com, use the Codex API-key fallback while the upstream issue remains open.
Xquik supports both MCP client registration paths:
  • Client ID Metadata Documents (CIMD): Recommended for modern clients. The client’s HTTPS metadata URL becomes its client_id. No registration request or client secret is required.
  • Dynamic Client Registration (DCR): Compatibility fallback for clients that do not publish CIMD. The client registers itself once at /api/oauth/register.
Normal users do not create either configuration manually. Enter https://xquik.com/mcp in the client and follow its authentication prompt.

How it works

OAuth 2.1 Authorization Code with PKCE follows this sequence:

Discovery

Xquik publishes standard OAuth discovery documents so MCP clients can auto-configure endpoints.

Authorization server metadata

Response
agent_auth is a Xquik discovery extension, not an RFC 8414 or MCP core field. Generic OAuth clients may ignore it.

Protected resource metadata

Response
The MCP endpoint also returns this metadata URL in its unauthenticated WWW-Authenticate challenge:

Client registration choices

Client ID Metadata Document

Publish a JSON document at a stable HTTPS URL with a non-root path and use that exact URL as the client_id:
The HTTPS client_id URL must have a non-root path and no user information, query, fragment, or dot path segments. Xquik requires a direct 200 JSON response without redirects. The document must remain at or below 5 KiB, repeat the exact client_id, and include client_name, redirect_uris, and token_endpoint_auth_method: "none". List every allowed redirect URI.

Dynamic Client Registration

Clients without CIMD may register at POST /api/oauth/register. DCR supports public clients with none and confidential clients with client_secret_post. The manual flow below uses a DCR-issued UUID so each step can show a concrete client_id.

Manual implementation

1

Register a DCR client

Skip this step when the client uses CIMD. For DCR, register once to get a UUID client_id.
Response
Redirect URI requirements:
  • Production web callbacks: HTTPS only
  • Development: HTTP loopback callbacks may use localhost, 127.0.0.1, or ::1
  • HTTPS and supported native callbacks require exact matching
  • HTTP loopback callbacks may change only the ephemeral port. Scheme, host, path, and query must match
  • Wildcards and subpath matching are not supported
Client types:
  • Public (token_endpoint_auth_method: "none"): Default. No client secret. Used by browser apps and MCP clients.
  • Confidential (token_endpoint_auth_method: "client_secret_post"): Returns a client_secret in the registration response. Used by server-side apps.
If you register a confidential client, the client_secret is returned once in the registration response. Store it securely.
2

Generate PKCE parameters

Generate a cryptographically random code_verifier and derive the code_challenge from it.
The code_verifier must have sufficient entropy. Use at least 32 cryptographically random bytes (64 hex characters). Store the verifier securely on the client. You need it for the token exchange in step 5.
3

Redirect to authorization

Redirect the user to the Xquik authorization endpoint with the required query parameters.
Required parameters:Optional parameters:Xquik defaults resource to https://xquik.com/mcp for compatibility, but MCP clients must send it in authorization and token requests.The user sees a login page (Google OAuth or email magic link) followed by a consent screen. After approval, Xquik redirects back to your redirect_uri.
4

Receive the authorization code

After the user approves, Xquik redirects to your redirect_uri with a code parameter:
Verify state against the value sent in step 3. Verify iss exactly equals the discovered issuer, https://xquik.com, before exchanging the code. The authorization code expires in 60 seconds and is single-use.
5

Exchange code for tokens

Exchange the authorization code and your code_verifier for an access token and refresh token.
Response
6

Use the access token

Pass the access token as a Bearer token in the Authorization header when connecting to the MCP server.

Token lifetimes

Refresh tokens

Access tokens expire after 1 hour. Use the refresh token to get a new access token without requiring the user to log in again.
Response
Refresh tokens are single-use. Each refresh request revokes the old refresh token and returns a new one. Always store the latest refresh token from each response.

Token revocation

Revoke an access or refresh token when a user disconnects or your application no longer needs access.
Returns 200 with an empty body on success. If the token is already revoked or invalid, the server still returns 200 (per RFC 7009). Revocation errors:

Scopes

Only mcp:tools is supported. No partial scopes or scope combinations are available.

Client registration

Request

Response

Error responses

Token, registration, and revocation endpoint errors use the standard OAuth JSON format:
Authorization errors use 2 transports. Xquik returns an HTML error page when it cannot safely trust the client or redirect URI. After validating both, Xquik redirects errors to the registered callback with error, error_description, optional state, and iss=https://xquik.com query parameters.

Authorization errors

Token errors

Registration errors

Read error_description for the specific validation failure. Missing or blank client_name values default to MCP Client.

Full example

A complete Node.js implementation of the OAuth 2.1 flow:
Node.js

Where to go next

MCP Server

Connect AI agents to Xquik via MCP.

MCP Tools Reference

All MCP tools with input/output schemas.

API Key Auth

API key authentication for REST API and MCP.

Quickstart

Get your API key and make your first request.
Last modified on July 16, 2026