AuthServer
Preregistration vs CIMD vs DCR
Pick the right client onboarding path without memorizing OAuth acronyms first.
SqlOS supports three client onboarding paths.
You do not need all three on day one.
Start here:
That gives SqlOS a simple default and a practical compatibility story.
Use preregistration when you already know the client.
Examples:
The client record lives in SqlOS and you seed it at startup or create it in the dashboard.
builder.AddSqlOS<AppDbContext>(options =>
{
options.AuthServer.SeedOwnedWebApp(
"todo-web",
"Todo Web",
"https://app.example.com/auth/callback");
});This is still the best first step for most product teams.
CIMD means the client_id is a stable HTTPS URL, and SqlOS fetches the client's metadata document from that URL.
Use it when:
builder.AddSqlOS<AppDbContext>(options =>
{
options.AuthServer.EnablePortableMcpClients(registration =>
{
registration.Cimd.TrustedHosts.Add("clients.example.com");
});
});That helper turns on:
CIMDDCR means the client calls POST /register and SqlOS creates a client record at runtime.
Use it when:
builder.AddSqlOS<AppDbContext>(options =>
{
options.AuthServer.EnableChatGptCompatibility(dcr =>
{
dcr.MaxRegistrationsPerWindow = 25;
});
});Keep it narrow:
token_endpoint_auth_method=none| Your situation | Best starting point |
|---|---|
| "I am building my own browser app." | Preregistration |
| "I am building my own mobile or native app." | Preregistration |
| "I want a portable public client with a stable HTTPS identity." | CIMD |
"A client still expects POST /register." | DCR |
| "I am just trying to get SqlOS running quickly." | Preregistration |
For most teams:
CIMD for portable public clientsDCR only when a real client still needs it