Production readiness checklist

A focused checklist for launching your MCP server authentication, with emphasis on custom domain and branding for a production-grade OAuth consent experience.

As you prepare to launch MCP server authentication to production, verify these items before going live.

Production environment

Verify production environment configuration

Confirm that your environment URL (SCALEKIT_ENVIRONMENT_URL), client ID (SCALEKIT_CLIENT_ID), and client secret (SCALEKIT_CLIENT_SECRET) are correctly set for production, not dev or staging.

Custom domain (CNAME)

Configuring a custom domain is the highest-impact step for MCP auth. Without it, the OAuth consent screen your users see during authorization displays yourapp.scalekit.com (Scalekit’s default domain) instead of your own brand. Complete this section before you test any end-to-end auth flows in production.

Configure a custom domain in the Scalekit dashboard

Go to Dashboard > Auth for SaaS > Customization > Custom Domain and follow the CNAME setup instructions. CNAME configuration is available only in production environments. See Branded custom domains for step-by-step instructions.

Verify SSL certificate provisioning

After CNAME verification, Scalekit automatically provisions an SSL certificate. Click Check in Dashboard > Auth for SaaS > Customization > Custom Domain to confirm status. Provisioning can take up to 24 hours. Contact support@scalekit.com if it takes longer.

Update customer-facing authorization URLs to use your custom domain

Backend API calls work with either URL, but the authorization URL and any other endpoints your users interact with must use your custom domain (for example, mcp.yourapp.com) for branding to take effect. Update those URLs in your application code after CNAME setup is complete.

Confirm the consent screen shows your branded domain

Open an incognito window, trigger an authorization flow, and verify the OAuth consent screen shows your custom domain (for example, mcp.yourapp.com) and not the default Scalekit URL.

Upload your logo and set brand colors

Go to Dashboard > Auth for SaaS > Customization > Branding to upload your logo, set a favicon, and configure background colors. This is what users see during the OAuth authorization flow.

Set a recognizable MCP server name

When registering your MCP server in Dashboard > MCP Servers, provide a name that users will recognize (for example, Acme Calendar, not mcp-prod-v2). This name appears on the consent page that MCP hosts display to users when they authorize access.

Bring your own auth (if applicable)

If you are using a federated authentication setup where Scalekit acts as the OAuth 2.1 layer but delegates user authentication to your existing system, verify these additional items.

Configure your login endpoint URL in the Scalekit dashboard

Scalekit redirects users to your login endpoint with a login_request_id and state parameter. Confirm the endpoint URL is correctly set for your production environment.

Verify your login endpoint handles the login_request_id and state parameters

Your login page must capture both parameters from the redirect and pass them through the authentication flow. Missing either parameter breaks the callback handshake.

Test the backend-to-backend user handoff

After authenticating a user, your system POSTs user attributes to Scalekit at /api/v1/connections/<connection_id>/auth-requests/<login_request_id>/user. Verify this call succeeds with production credentials and that the connection_id (starts with conn_) is correct for your production MCP server.

Verify the state parameter in your callback redirect

After the user handoff, your system redirects back to Scalekit’s callback URL with the state value from step 1. Confirm the values match exactly. Mismatched state is silently rejected and breaks the flow.

Test the complete federated flow end-to-end

Trigger a full authorization flow from an MCP client through your login page, the user handoff API call, and the callback redirect, and verify the MCP client receives a valid access token at the end. See Bring your own auth for implementation details.

Core auth flows

Test the human → MCP authorization flow end-to-end

After CNAME and branding are configured, trigger a complete authorization code flow: from the initial tool call through the 401 challenge, consent screen, token exchange, and authorized response. Run this in production with your live credentials.

Test the agent → MCP client credentials flow

Verify that API clients can obtain tokens and call MCP tools successfully. Confirm that client credentials are stored in environment variables or a secrets manager, not hardcoded.

Monitoring

Enable auth logs and set up alerts

Monitor Dashboard > Auth Logs for repeated 401 errors, invalid scope requests, and token failures after launch. Set up alerts for unusual activity patterns.

After launch, use Auth logs to debug authentication issues and review the MCP auth troubleshooting guide for common problems.