CloudBase auth provider configuration and login-readiness guide. This skill should be used when users need to inspect, enable, disable, or configure auth providers, publishable-key prerequisites, login methods, SMS/email sender setup, or other provider-side readiness before implementing a client or backend auth flow.
CloudBase auth provider configuration and login-readiness guide. This skill should be used when users need to inspect, enable, disable, or configure auth providers, publishable-key prerequisites, login methods, SMS/email sender setup, or other provider-side readiness before implementing a client or backend auth flow.
version
2.23.11
alwaysApply
false
Standalone Install Note
If this environment only installed the current skill, start from the CloudBase main entry and use the published cloudbase/references/... paths for sibling skills.
CloudBase main entry: https://cnb.cool/tencent/cloud/cloudbase/cloudbase-skills/-/git/raw/main/skills/cloudbase/SKILL.md
Current skill raw source: https://cnb.cool/tencent/cloud/cloudbase/cloudbase-skills/-/git/raw/main/skills/cloudbase/references/auth-tool/SKILL.md
Keep local references/... paths for files that ship with the current skill directory. When this file points to a sibling skill such as auth-tool or web-development, use the standalone fallback URL shown next to that reference.
Activation Contract
Use this first when
The task is to inspect, enable, disable, or configure CloudBase auth providers, login methods, publishable key prerequisites, SMS/email delivery, or third-party login readiness.
An auth implementation cannot proceed until provider status and login configuration are confirmed.
A CloudBase Web auth flow needs provider verification before auth-web.
The task mixes provider configuration with Web, mini program, Node, or raw HTTP auth implementation.
Then also read
Web auth UI -> ../auth-web/SKILL.md (standalone fallback: https://cnb.cool/tencent/cloud/cloudbase/cloudbase-skills/-/git/raw/main/skills/cloudbase/references/auth-web/SKILL.md)
Mini program native auth -> ../auth-wechat/SKILL.md (standalone fallback: https://cnb.cool/tencent/cloud/cloudbase/cloudbase-skills/-/git/raw/main/skills/cloudbase/references/auth-wechat/SKILL.md)
The default implementation guide for every login or registration request.
A replacement for mini program native auth behavior when no provider change is involved.
A replacement for Node-side caller identity, user lookup, or custom login ticket flows.
A replacement for frontend integration, session handling, or client UX implementation.
Common mistakes / gotchas
Writing login UI before enabling the required provider.
Treating any mention of "auth" as a provider-management task.
Implementing Web login in cloud functions.
Routing native App auth to Web SDK flows.
Making configuration or code changes without first following the Change Safety Protocol (cloudbase-platform/references/protocols/change-safety-protocol.md).
In an existing application, looping on provider queries after readiness is already known instead of wiring the active login and register handlers.
Anonymous login is disabled by default. The SDK initialized with accessKey still creates a lightweight anonymous session for API access. If the app requires authentication (e.g. admin panels, personal dashboards), enforce access control through AuthGuard or RLS policies rather than relying on the login strategy toggle.
Overview
Configure CloudBase authentication providers: Anonymous, Username/Password, SMS, Email, WeChat, Google, and more.
Prerequisites: CloudBase environment ID (env)
MCP Tool Boundary
Keep these two auth domains separate:
auth: MCP / management-side login only. Use it for status, start_auth, set_env, logout, and get_temp_credentials.
queryAppAuth / manageAppAuth: app-side authentication configuration. Use them for login methods, provider settings, publishable key, static domain, client config, and custom login keys.
Preferred execution order for this skill:
Use queryAppAuth / manageAppAuth first when the needed action exists there.
Use callCloudApi only as a fallback or for debugging raw request shapes.
Do not route app-side provider configuration back to the MCP auth tool.
In existing projects with active login and register handlers, stop revisiting provider setup after the required login method and publishable key are confirmed. Move back to the active frontend handler and finish the actual user flow.
The underlying login strategy contains fields such as:
AnonymousLogin
UserNameLogin
PhoneNumberLogin
EmailLogin
SmsVerificationConfig
MfaConfig
PwdUpdateStrategy
Parameter mapping for downstream Web auth code:
queryAppAuth(action="getLoginConfig") and manageAppAuth(action="patchLoginStrategy") return sdkStyle: "supabase-like" plus sdkHints; treat that as the preferred frontend-auth calling guide
PhoneNumberLogin controls phone OTP flows used by auth-webauth.signInWithOtp({ phone }) and auth.signUp({ phone })
EmailLogin controls email OTP flows used by auth-webauth.signInWithOtp({ email }) and auth.signUp({ email })
UserNameLogin controls username/password Web login flows used by auth-webauth.signInWithPassword({ username, password }); direct username/password signUp support is SDK/provider dependent and must be verified before use
If the account identifier is a plain username string, do not route it through email-only helpers such as signInWithEmailAndPassword
UserNameLogin also enables the broader password-login surface exposed by auth.signInWithPassword({ username|email|phone, password })
SmsVerificationConfig.Type = "apis" requires both Name and Method
EnvId is always the CloudBase environment ID, not the publishable key
If the conversation only contains an environment alias, nickname, or other shorthand, resolve it to the canonical full EnvId first before generating auth config, SDK init examples, or console links
Internal behavior of manageAppAuth(action="patchLoginStrategy"):
Read the currently selected environment
Query the current login strategy
Merge the short patch into the writable strategy fields
Update through Manager SDK
Query again and return a short loginMethods result
2. Anonymous Login
⚠️ Anonymous login is disabled by default. The SDK initialized with accessKey still creates a lightweight anonymous session for API access. Only enable anonymous login when the application explicitly requires unauthenticated access and you accept the associated security trade-offs. Anonymous users are also denied AI model invocation permissions by default.
The tool handles read-merge-write internally. The model does not need to build a full ModifyLoginConfig payload.
Important: Even after enabling anonymous login, anonymous users cannot call AI models by default. This permission must be explicitly granted separately if needed.
Prefer MCP: queryAppAuth(action="getStaticDomain") — use cdnDomain / staticDomain from the tool response (first store’s CdnDomain). Raw rows are in staticStores.
Use provider lifecycle APIs when the identity source itself needs to be created, updated, or removed.
Preferred MCP tool path:
queryAppAuth(action="listProviders")
queryAppAuth(action="getProvider")
manageAppAuth(action="addProvider")
manageAppAuth(action="updateProvider")
manageAppAuth(action="deleteProvider")
Guidance:
Use addProvider when the provider record does not exist yet and you need to create it with providerType, optional providerId, displayName, and config.
Use updateProvider when the provider already exists and only its configuration or enablement state needs to change.
Use deleteProvider when the provider must be removed entirely instead of only disabling it.
9. Client Configuration Boundary
Use client APIs for client metadata and token/session settings. Do not use them as a replacement for login strategy or provider management.
Preferred MCP tool path:
queryAppAuth(action="getClientConfig")
manageAppAuth(action="updateClientConfig")
Both tools should default to the current selected environment's default client. Only pass clientId when you intentionally want to inspect or modify a non-default client record.
Use the shortcut pair getPublishableKey / ensurePublishableKey for the most common frontend-readiness flow.
Use the generic API key lifecycle actions when you need inventory, pagination, non-publishable keys, or explicit deletion.
queryAppAuth(action="getPublishableKey") should always force KeyType="publish_key" and return a short payload with publishableKey, keyId, keyName, expireAt, and createdAt.
manageAppAuth(action="ensurePublishableKey") should first query the existing publish_key; if one already exists, return it directly; otherwise create it and return the new key. This keeps the MCP interface short and avoids requiring the model to reason about KeyType or whether a key already exists.
