Dynamic Client Registration

DCR is the compatibility path in SqlOS.

It exists for real clients that still expect runtime registration at POST /register.

When to use it#

Enable DCR when:

• a client expects to register itself before starting OAuth
• you need compatibility with a DCR-first client
• preregistration would be too manual for that client's flow

Keep it off when:

• your own app already has a known client id
• CIMD is available and fits the client

Turn it on#

builder.AddSqlOS<AppDbContext>(options =>
{
    options.AuthServer.EnableChatGptCompatibility(dcr =>
    {
        dcr.MaxRegistrationsPerWindow = 25;
    });
});

Or enable it directly:

builder.AddSqlOS<AppDbContext>(options =>
{
    options.AuthServer.ClientRegistration.Dcr.Enabled = true;
});

SqlOS then advertises registration_endpoint in auth-server metadata.

What SqlOS accepts in v1#

SqlOS intentionally keeps DCR narrow:

• public clients only
• authorization_code
• response_types=code
• PKCE required
• token_endpoint_auth_method=none
• HTTPS redirects or loopback localhost redirects
• optional scope, persisted as the client's allow-list and echoed on the registration response

SqlOS does not use DCR for:

• confidential client secrets
• RFC 7592 self-service management APIs

Scope#

Honor the RFC 7591 scope member. SqlOS persists the registered set as AllowedScopesJson and always echoes scope on the 201 response so the client can predict later grants from that response alone.

• When scope is omitted, SqlOS registers an empty allow-list and echoes scope as an empty string. Later authorize, device, and client_credentials grants then intersect to nothing.
• When ClientRegistration.Dcr.AllowedScopes is non-empty, it is the operator ceiling. Requested scopes outside that set are invalid_client_metadata.
• When the ceiling list is empty, requested scopes are registered as-is, still bounded by MaxScopeCount (default 32) and MaxScopeLength (default 128). Exceeding those limits is a registration error.

builder.AddSqlOS<AppDbContext>(options =>
{
    options.AuthServer.EnableChatGptCompatibility(dcr =>
    {
        dcr.AllowedScopes.Add("openid");
        dcr.AllowedScopes.Add("profile");
        dcr.AllowedScopes.Add("offline_access");
        dcr.MaxScopeCount = 16;
    });
});

openid is stored and granted as an ordinary allow-listed string. It is never always-allowed, and because a registration without scope stores an empty allow-list, a dynamically registered client must be granted openid deliberately — in the registration request or by an operator afterward. With OpenID Provider mode enabled (the default), a granted openid mints an id_token at the token endpoint; the warning when an OIDC-capable client omits openid is on the admin, dashboard, hosted, and headless surfaces.

Operational controls#

DCR creates real client rows in the existing store, so lifecycle controls matter.

SqlOS includes:

• rate limiting
• an optional AllowedScopes ceiling plus count/length bounds
• audit logs for accepted and rejected attempts
• disable and re-enable actions
• revoke active sessions
• automatic cleanup for stale registered clients

Policy hook#

Use a policy hook when redirect rules alone are not enough:

builder.AddSqlOS<AppDbContext>(options =>
{
    options.AuthServer.ClientRegistration.Dcr.Policy = async (context, cancellationToken) =>
    {
        if (context.RedirectUris.Count == 0)
        {
            return SqlOSClientRegistrationPolicyDecision.Deny("At least one redirect URI is required.");
        }
 
        return SqlOSClientRegistrationPolicyDecision.Allow();
    };
});

This is the right place for:

• extra redirect checks
• network or environment restrictions
• known-client compatibility rules

Related guides#

• Preregistration vs CIMD vs DCR
• Client ID Metadata Documents
• Todo Sample