Skip to main content

Register an application

You have an MCP server running somewhere. Maybe a GitHub MCP at https://mcp.acme.example, maybe an internal tools API at https://api.acme.example. You want AuthSec to handle who can call what.

This page is the first step. Two minutes.

When to use this

You've stood up an MCP server (or any HTTP service that AI clients will call) and you want it protected before it sees real traffic.

What you get

A registered Application in AuthSec, an introspection secret, and a resource URI the SDK plugs into. You're then 5 minutes from launched.

Before you start​

You need:

  • An application to protect. An MCP server, an AI agent endpoint, or an HTTP API. Reachable over HTTPS in production. (For local dev against a service running on your laptop, AuthSec also accepts loopback addresses — see local development.)
  • Admin access to your AuthSec workspace.
  • Five minutes to install an SDK afterward. Python, Go, and TypeScript all ship a one-line wrapper.

In the admin UI​

  1. Go to Applications in the left nav.

  2. Click Create application.

  3. Fill in three fields:

    • Application name — anything you'll recognise later. "GitHub MCP", "Internal Reporting API". This is for humans; it doesn't affect runtime behaviour.
    • Public base URL — the externally-reachable origin of your application. For a hosted MCP server that might be https://mcp.acme.example. For an internal API it might be https://api.acme.example.
    • Protected path — the URL prefix you want AuthSec to guard. For MCP servers this is almost always /mcp (see why /mcp). For a REST API it might be /v1.

  4. Click Create and protect.

That's it. You land on the application detail view.

What you see next​

The detail view shows the Setup step with the pieces needed to protect the application:

  1. Copy the one-time introspection secret.
  2. Install the AuthSec SDK wrapper.
  3. Publish the tool manifest — the list of tools your application exposes, so AuthSec knows what to enforce policy on.
  4. Review tool access before launch — map each tool to the scopes that should be required to call it.

The introspection secret is shown once on this screen. Copy it, store it in your application's environment as AUTHSEC_INTROSPECTION_CLIENT_SECRET, and don't refresh the page before you've grabbed it. If you lose it, hit Rotate secret on the same screen.

Why these three fields​

Application name is cosmetic. Pick something operators will recognise in the audit log.

Public base URL is the origin token validators check against. AuthSec will mint tokens whose aud (audience) claim is composed from this URL plus the protected path. If your application's deployed URL doesn't match what you registered here, every token will be rejected with invalid_audience. (See troubleshoot OAuth tokens for the four-claim debug checklist.)

Protected path tells AuthSec which prefix to enforce. Everything under that path needs a valid bearer token; everything else is left alone. For MCP servers /mcp is the convention every AI client expects.

What's next​

Now install the SDK and let it pull the rest of the configuration automatically:

Once the SDK is mounted and your application restarts, the manifest publishes automatically and you'll see the discovered tools on the Tools tab of the Application detail page.

When you need the API​

This page is the product walkthrough. If you're scripting registration (e.g. as part of CI), see the API reference for the underlying endpoint, the full response schema, the state machine, and the auth scheme. You almost never need it — the admin UI and the SDK cover the whole flow.