Skip to main content
Xquik supports 2 MCP authorization paths. Interactive clients use OAuth 2.1 Authorization Code with S256 PKCE. Agents can use claimed service_auth registration. Both paths require the user to sign in and approve access.
Prefer OAuth for compatible remote MCP clients. Check the client compatibility matrix before using an API key fallback.
Codex CLI 0.147.0 fixes Authorization server response missing required issuer: expected https://xquik.com. If you cannot upgrade, use the temporary API key workaround. See issue #31573.
  • 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.

Discovery

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

Authorization server metadata

Response
The endpoint fields follow the current Auth.md profile. The URI fields are working compatibility aliases. Generic OAuth clients may ignore this object.

Protected resource metadata

Response
Localized site resources publish the same RFC 9728 contract under /.well-known/oauth-protected-resource/en, /es, and /tr. Request https://xquik.com for direct REST calls. Use /mcp tokens only with MCP. The MCP endpoint also returns this metadata URL in its unauthenticated WWW-Authenticate challenge:

Client registration choices

Client ID metadata document

Publish JSON at a stable HTTPS URL with an explicit path. A trailing / is sufficient. Use that exact URL as the client_id:
The HTTPS client_id must include an explicit path. Exclude user information, queries, fragments, and dot segments. Xquik requires a direct 200 JSON response. Redirects fail. Keep the document within 5 KiB. Repeat the exact client_id. 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.These examples use /mcp. Direct REST clients use https://xquik.com. Send the same value in every authorization, token, and refresh request.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 token as a Bearer credential to its selected resource. This example calls MCP.

Token lifetimes

Claimed agent registration

Use service_auth when an agent knows the user’s verified email. Xquik never issues anonymous agent credentials.
1

Register the service identity

Send the verified email as login_hint.
The response includes claim_token, registration_id, and a claim object. Show claim.verification_uri and claim.user_code to the user. Keep every token secret.
2

Complete the claim

The user opens claim.verification_uri, signs in, and enters the code. The signed-in email must match login_hint.If the code expires, refresh it before the claim token expires:
3

Poll for tokens

Honor the returned claim.interval. Poll the token endpoint with the static public client ID.
Handle authorization_pending, slow_down, access_denied, and expired_token. Success returns an access token and identity_assertion. It never returns a refresh token.
4

Exchange an identity assertion

Reuse a current assertion when a fresh access token is required.
Xquik accepts service-signed assertions for active registrations. Restart registration after expiry or invalid_grant.

Refresh tokens

Interactive access tokens expire after 1 hour. Use their refresh token without another login.
Response
Refresh tokens are single-use. Always store the latest returned token.

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). Revoke a claimed agent with its identity_assertion, client_id=urn:xquik:agent-auth, and token_type_hint=urn:ietf:params:oauth:token-type:id-jag. This revokes the registration and every access token. Revoking one access token leaves the registration active. 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.

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.