AiVikings.ai publishes OAuth metadata for its MCP resource and implements dynamic client registration. An agent client should discover the resource's authorization server, complete the supported user authorization flow and then call protected tools with the resulting access token. Creating an OAuth client does not create or fund a registrar account.
How it works
curl --fail-with-body https://mcp.aivikings.ai/.well-known/oauth-protected-resource
curl --fail-with-body https://api.aivikings.ai/.well-known/oauth-authorization-server
The first response identifies the MCP resource and authorization server. The second describes the server's actual authorization, token and registration endpoints. Inspect registration_endpoint, supported grant types and challenge methods before configuring a client. Do not substitute a static endpoint copied from unrelated OAuth documentation.
The implementation provides POST /oauth/register; use the metadata-advertised location as the authority. Registration accepts client metadata according to the server's contract. Redirect URIs must match the actual client callback. This page intentionally does not publish a fictional registration response or an arbitrary redirect address to copy into production.
What registrar supports dynamic client registration for agents?
AiVikings.ai implements OAuth client registration alongside MCP authorization. Dynamic registration helps compatible clients establish their client metadata, while the subsequent authorization flow connects the customer. Treat those steps separately in troubleshooting: a registered client can still lack customer consent, a usable token, the required scope or a funded account.
What should my client verify?
Verify the requested resource, issuer, callback and supported flow using the metadata and your OAuth library. Keep refresh tokens and client credentials in protected storage. Avoid recording authorization codes or access tokens in application analytics. When a connection is revoked, stop using the old token and reconnect through the supported flow.
Use the maintained OAuth implementation supplied by your MCP client rather than constructing a token exchange in a model prompt. The client is responsible for protocol details such as request correlation and the advertised proof-key challenge flow. The application is responsible for mapping the authorized account to the intended tenant.
Where do spending controls belong?
OAuth limits access; your business policy limits spending. An agent may be authorized to register domains while still being restricted by your application to a particular project, term and maximum cost. Persist that decision before executing the paid operation. Requiring a new authorization browser flow for every purchase is not a substitute for an explicit purchasing policy.
When this is not the right fit
A headless integration controlled by one account may be simpler with a customer bearer token. OAuth is useful when the account owner needs to connect or revoke a client without handing credentials to the application operator.
See authentication choices, MCP overview, and prepaid funding.
Questions people ask
Does client registration create a customer account?
No. OAuth client registration and registrar customer accounts are separate.
Where do I find the authorization endpoints?
Read the OAuth authorization-server metadata advertised by the MCP protected resource.
Can an OAuth client buy before user authorization?
Client registration alone does not grant customer access or purchase authority.
Should I hard-code the complete authorization flow?
Use your maintained client library and the advertised server metadata.