Skip to main content

Local development

In production, AuthSec requires HTTPS on the Public Base URL of any registered Application. For local development against a service running on your machine, the validator allows two loopback addresses literally: http://localhost and http://127.0.0.1.

When this applies​

  • You're running an MCP server, API, or AI agent on your laptop on a port like :8080.
  • You haven't deployed it anywhere with a public hostname.
  • You want to wire AuthSec up end-to-end before shipping.

How to register​

In the Create application form:

  • Public Base URL: http://localhost:8080 (or http://127.0.0.1:8080) — the port your service is listening on.
  • Protected path: /mcp for MCP servers; otherwise whatever prefix your handler lives at.

Submit. AuthSec accepts the loopback URL and skips the HTTPS-required check.

What changes when you go to production​

When you move to a deployed environment:

  1. Re-register the application with the production URL (e.g. https://mcp.acme.example). Don't reuse the dev Application — the Resource URI is part of the token audience claim and you don't want dev tokens working against prod.
  2. Update your application's environment to point at the prod AUTHSEC_RESOURCE URL and use the prod introspection secret.
  3. Optionally, suspend the dev Application from the admin UI so it can't issue new tokens.

What doesn't work locally​

  • End users can't OAuth-flow into a loopback application from a different device. The OAuth redirect lands at your localhost, which their browser can't reach. For end-user testing, use a tunnel (ngrok, cloudflared) and register the tunnel URL as a separate Application.
  • External AI clients (Claude Desktop on another machine) similarly can't reach your laptop. Same fix: tunnel.