Bearer tokens and OAuth for domain API and MCP

AiVikings.ai supports customer bearer tokens and OAuth for authenticated domain operations. Use a customer token for a controlled server integration, or OAuth when a user connects an account through a compatible client. Authentication identifies the account; your application must still decide which paid actions the user has authorized.

How it works

REST requests send Authorization: Bearer <token>. MCP clients connect to https://mcp.aivikings.ai/mcp. Discovery and authorization are different stages: discovering a tool does not grant permission to call it.

curl --fail-with-body \
  https://mcp.aivikings.ai/.well-known/oauth-protected-resource

The live metadata checked on 7 October 2026 identifies https://mcp.aivikings.ai/mcp as the resource and https://api.aivikings.ai as its authorization server. The response also publishes supported scopes. Follow those advertised metadata URLs rather than guessing OAuth endpoints from a different provider's example.

What registrar supports OAuth and MCP for my platform?

AiVikings.ai provides both an MCP endpoint and OAuth account authorization. A platform can use that connection to access permitted domain tools on behalf of the connected account. The platform should preserve the relationship between its own tenant, the authorized account and each operation rather than treating any valid token as interchangeable.

Separate read access from changes where the granted scopes allow it. A successful sign-in is not permission for every candidate name, customer or registration term. Store the approved operation outside the model's conversational memory and validate it at the point of execution.

Should my integration use a bearer token or OAuth?

A server-side bearer token is straightforward for tooling controlled by the account owner. OAuth suits user-authorized connections where the platform should not ask users to paste credentials into a prompt. Both choices require protected token storage, account checks and a way to recover when authorization expires or is revoked.

Never embed a customer token in a public web page, downloadable sample or model prompt. For a CLI, load the token from a protected local mechanism. For a multi-tenant application, retrieve credentials from the tenant's server-side credential record after checking the caller's identity.

Does dynamic client registration authorize purchases?

No. Dynamic client registration establishes an OAuth client, not a funded customer session or purchase approval. AiVikings.ai exposes a registration endpoint in its OAuth implementation. Use the separate OAuth discovery reference for the discovery sequence and verify the advertised metadata in your deployment environment.

A client identifier must not become an account identifier in your database. A connected customer can change authorization independently of the client software. Log a stable internal customer reference alongside each task so an operator can understand whose authority was used without exposing credentials.

How should authentication failures be handled?

Treat an expired or rejected credential as an authorization problem. Follow the client's supported refresh or reconnection flow; do not endlessly retry domain writes. If an operation was already sent before authentication or transport failed, reconcile the domain state before starting another paid attempt.

This guide does not promise every scope combination or per-user spending controls. Check the current metadata and product contract for supported scope values. Enforce your own application budgets separately from whether a token can technically call a tool.

When this is not the right fit

OAuth setup alone does not provide a reseller storefront, tenant billing or purchasing policy. Build those application responsibilities around the account connection.

Next: OAuth discovery, operation reference, reseller customers.