Authentication presets

Presets describe authorization, token exchange, response mapping, account identity, request signing and refresh. The engine executes the recipe; provider documentation and real tests establish whether it matches a provider.

Use an official or personal preset

1. Choose Provider Presets / Custom OAuth in the app builder.
2. Select a provider, version and environment. Enter its declared credentials and provider parameters.
3. Add the optional read-only starter tools, or define your own API tools.
4. Save a draft, register its exact callback URL in the provider console and connect your test account.
5. Open the saved app, test a read-only tool and use Verify API and refresh to record version-specific evidence.

Authorization Code connections follow your account plan limits. Switching provider, version or environment clears credential inputs. Existing apps retain their saved recipe when a preset is revised.

Create your own preset

Open Authentication presets. Start from an official preset or create a new definition. Declare input names and labels, configure each environment, and edit the recipe using the schema editor. Named secret inputs may use text or JSON. Validate, then save a private version.

Use client_id, client_secret, signing_secret, secrets.name or parameters.name as input bindings. Values entered when using the preset are stored with the app, encrypted separately from recipe metadata. Preset definitions contain no credential values. Import/export uses a credential-free definition; exporting a configured app extracts recognized sensitive literals into empty named bindings.

Agent workflow

1. Call get_auth_recipe_schema to discover the canonical contract and engine capabilities.
2. Use list_auth_presets and get_auth_preset, or read provider docs and author a definition.
3. Call validate_auth_recipe, then create_auth_preset. Supply a fresh UUID for idempotent creation.
4. Create a draft app with create_and_deploy_server and deploy_now=false, using the pinned config and starter tools returned by get_auth_preset.
5. Call connect_upstream_oauth_for_test and let the user register the callback and complete provider consent.
6. Check get_upstream_oauth_test_status, then test_mcp_tool or verify_auth_preset. Retrieve evidence with get_auth_preset_checks.

Use update_auth_preset with expected_version to create a new revision. Archive/restore affects catalog visibility and preserves existing apps. Manager tokens use the existing MCP read, write and test scopes.

Canonical API

GET /api/mcp/auth-presets/schema returns both recipe and definition JSON schemas. UI, backend validation and Manager MCP use this same versioned contract. Structural validation performs no provider requests. Verification checks exact recipe/version/environment and returns statuses without tokens or provider response data.

Schema-valid and live-tested are different states. Official Shopee sandbox and TikTok Vietnam Development Shop flows were tested. A cloned or revised personal preset starts with schema validation only. Read-only starter templates and verification currently use GET API tools. Unsupported cryptographic protocols or multi-stage token flows need engine extensions or an adapter.