# AppInChina Login Documentation > This file contains the AppInChina Login documentation concatenated into > a single document. You can paste it into an AI assistant (ChatGPT, Gemini, > Claude, etc.) to ask questions about your Login integration. > > Generated automatically at build time. --- Most apps and services need a login system to reliably identify users and associate their data, access, and history with a single account over time. This page explains what a login system needs to do, what legal requirements apply in China, which solutions are available, and what to confirm before choosing one. :::important Before beginning any implementation work on your login solution, confirm your plan with the AppInChina team first. This gives us time to align on account setup, compliance requirements, pricing, and any platform-specific considerations. Reaching out early avoids rework. ::: ## What a login system needs to do A login system is not just a sign-in screen. It is the foundation for everything that ties a user to their account over time. At minimum, a login system needs to: * Allow users to create an account * Allow returning users to authenticate and regain access to the same account * Allow users to recover access if they lose their credentials * Maintain a stable user identity that persists across sessions and devices * Manage sessions or tokens so users stay signed in reliably These are baseline requirements regardless of which solution is used. ### The stable internal user ID Every user should be represented by a stable internal user ID in the application's own database. This ID should not change over time, should not be editable by the user, and should not be derived from a device identifier or external provider identifier. The stable internal user ID is what the application should use for customer records, permissions, order history, entitlements, and any data tied to the user. External identifiers from login providers should be linked to this internal ID, not used in place of it. ## Legal requirement: real-name authentication If the application includes any social or interactive features — such as posting content, commenting, messaging, or uploading media — Chinese law requires real-name authentication before users can access those features. In practice, this means verifying the user's identity through a Chinese mobile phone number at registration or before enabling social features. All Chinese mobile phone numbers are tied to a national ID card, which satisfies this requirement. Email-only registration is not sufficient for applications with user-generated content. If this applies to your application, it should be confirmed as a requirement before choosing a login solution. ## Choosing a login solution The right solution depends on the application's requirements, the team's capacity, and the infrastructure already in place. | Solution | Consider this when | Main trade-off | |---|---|---| | [Authing](./solutions/authing) | You want a managed identity platform with low implementation overhead | Vendor dependency | | [WeChat Login](./solutions/wechat-login) | Users are WeChat-native and you want a China-local login method | Needs backend integration; does not replace a full identity system | | [China cloud identity (CIAM/IDaaS)](./solutions/china-cloud-identity) | Your infrastructure is on Alibaba Cloud or Tencent Cloud and you want a China-first managed identity platform | Tighter cloud vendor coupling | | [Custom backend login](./solutions/custom-backend) | You have a backend team and specific requirements a managed platform cannot meet | Highest engineering and security maintenance burden | For most clients starting from scratch, Authing is the recommended default. It covers the baseline requirements with low implementation overhead and includes an admin console for user management. ## Questions to confirm before choosing a solution Before selecting a login solution, the following questions should be confirmed: 1. What login methods are required — password, SMS OTP, WeChat Login, or others? 2. Does the application include social or interactive features that require real-name authentication? 3. Should user registration be open, or should users be pre-approved before accessing the service? 4. Does the application need customer accounts, organizations, roles, or permissions? 5. Who can approve, suspend, or remove users? 6. Is there a backend team available to integrate the login system? 7. Does the application need to link multiple login methods to a single user identity? 8. Is there an existing backend or user database the login system needs to integrate with? 9. Is the application hosted on Alibaba Cloud, Tencent Cloud, AWS China, or another platform? 10. Does the application serve users outside Mainland China, and if so, how will login work across regions? ## What AppInChina can help with Depending on the project scope, AppInChina can help clients understand: * Which login solution is most appropriate for the application's requirements * What compliance or legal requirements apply * What account setup or platform configuration is needed * What work is required from the client's backend, mobile, or web teams * How the login solution fits into the broader China launch or localization plan * What risks or limitations should be considered before implementation ## Related pages - [Authing](./solutions/authing) - [WeChat Login](./solutions/wechat-login) - [China Cloud Identity](./solutions/china-cloud-identity) - [Custom Backend Login](./solutions/custom-backend) - [Login → Payments integration](/payments/guides/login-identity) --- Authing is a managed identity platform commonly used in China-facing applications. It provides user registration, login, account recovery, session and token management, and an admin console for user management out of the box. This page explains what Authing does, where it fits, what it does not provide by itself, and what clients should consider before deciding whether to use it. For detailed SDK integration, API references, and platform-specific implementation steps, clients and developers should refer to the official Authing documentation linked at the end of this page. ## What Authing is Authing is a managed identity-as-a-service platform. It handles the infrastructure layer of user authentication so that teams do not need to build and maintain registration flows, login flows, password reset flows, session management, and token issuance from scratch. In simple terms, Authing helps answer this question: > Who is this user, and are their credentials valid? After that, the application still needs to decide what that user is allowed to do. For example, if a customer portal uses Authing for login, Authing can verify the user's identity and return a token. The portal still needs its own backend logic to decide whether that user is an approved customer, which company or account they belong to, and which files or features they can access. ## Where Authing fits Authing can be used as the authentication and identity management layer in an application. It can provide: * User registration and login * Password reset and account recovery * SMS or email OTP verification * MFA (multi-factor authentication) * Social login integration, including WeChat * Session and token management * Admin console for user management and troubleshooting However, Authing does not provide the full application-side authorization and access control layer by itself. If your application requires any of the following, they must be handled separately by your backend or application layer: * Customer verification and approval workflows * User-to-customer or user-to-organization mapping * Roles and permissions beyond basic user authentication * File or resource access control * User suspension logic tied to business rules * Audit logs for compliance or download tracking * Order history or transactional records * Enterprise SSO, SAML federation, or organization-level identity governance beyond what Authing's plan supports In these cases, Authing can still be used, but it should be treated as the authentication layer connected to your own user management and authorization system. ## When Authing is a good fit Authing may be a good fit when: * You want to avoid building and maintaining registration, login, and recovery flows from scratch. * You want common auth features available quickly without significant backend development. * You want an admin console for managing and troubleshooting user accounts. * You want to support multiple login methods, such as password login, SMS OTP, and WeChat Login, under one identity platform. * You have, or plan to build, a backend system that handles permissions, customer records, and access control. * You want Authing to manage the authentication layer while your application manages everything above it. ## What Authing should be paired with Authing handles authentication. It should be paired with the application's own backend, user database, and authorization logic for everything beyond confirming who the user is. For example: * If users need to be approved before accessing the service, the approval workflow should be handled by the application. * If users belong to specific customers, companies, or organizations, that mapping should be handled by the application. * If users have different roles or permissions, those rules should be handled by the application. * If users need access to specific files, records, or services, access control should be handled by the application. * If the system needs audit logs, download logs, or compliance records, those should be handled by the application. * If users need to be suspended or revoked based on business rules, that should be handled by the application. The application should maintain its own internal user record. Authing's user identifier should be linked to this internal record, not used as the primary key for application data. ## Common Authing use cases ### Registration and login for China-facing apps Authing is commonly used to provide password-based login, SMS OTP login, or WeChat Login for China-facing applications where a managed identity platform is preferred over building authentication from scratch. ### WeChat Login through Authing Authing supports WeChat Login as a social login method. This can simplify the WeChat Login integration by routing it through Authing rather than integrating WeChat Login directly into the application backend. However, the same WeChat Open Platform requirements still apply. The WeChat application setup, AppID, AppSecret, and callback configuration still need to be in place. Authing does not remove those requirements; it provides the integration layer. For more on WeChat Login requirements, see the [WeChat Login](./wechat-login) page. ### Admin user management Authing includes an admin console where user accounts can be viewed, searched, and managed. This can be useful for support and operations teams who need to look up or disable user accounts without building a custom admin tool. ### Multi-method login under one identity If an application needs to support multiple login methods, such as password login, SMS OTP, and WeChat Login, Authing can consolidate these under a single user identity. This reduces the risk of duplicate accounts when users switch between login methods. ## How Authing fits into the application at a high level ```text User registers or logs in | v Authing verifies credentials and issues a token | v Application backend receives and validates the token | v Application backend looks up the internal user record | v Application applies its own permission and access rules | v User accesses the permitted resources or features ``` The application backend remains responsible for the application's own user records, permissions, and access control. Authing's token should not be treated as a direct authorization grant for application resources. ## Key concepts ### Authing user identity Each user in Authing has a unique Authing user ID. This is the identifier returned after successful authentication. The application should link this Authing user ID to its own internal user record. The internal user record is what should be used for customer data, permissions, organization mapping, and access control. ### Social login and account linking When a user logs in through WeChat or another social login method, Authing can link that social identity to a single Authing user account. This helps avoid duplicate accounts when the same user logs in through different methods. The application should still verify that its own internal user record is correctly linked to the Authing identity. ### Tokens Authing issues tokens after successful authentication. These tokens should be validated by the application backend. The application backend should not rely solely on the presence of a token to make authorization decisions without also checking its own user and permission records. ## What Authing does not replace Authing is an authentication platform, not a complete identity and access management system for your application. It does not replace: * Your application's own user database and customer records * Your permission and role system * Your customer approval or onboarding workflow * Your file and resource access control * Your audit logging and compliance records * Your user suspension and revocation logic tied to business rules These must still be built and maintained by the application. ## Pricing and plan considerations Authing offers different pricing tiers. The features available, including MFA options, social login integrations, and admin capabilities, may vary by plan. Before committing to Authing, clients should confirm that the required features are available on the plan they intend to use. Authing's pricing page is linked at the end of this page. ## Ownership and account management The Authing account and tenant should normally be owned by the client, not by a third party acting on their behalf. If AppInChina helps set up or configure Authing on behalf of a client, the responsibility model should be agreed in advance. At minimum, the following should be clarified: * Who owns the Authing account and tenant * Who manages the Authing admin console * Who stores any API keys or secrets used in the integration * Who handles user support issues that require admin access * What happens if the client wants to migrate away from Authing later ## Questions to confirm before choosing Authing Before deciding whether Authing is the right fit, the following questions should be confirmed: 1. What login methods are required? * Password-based login * SMS OTP * WeChat Login * Other social login * MFA 2. Does the application need user registration to be open, invite-only, or pre-approved? 3. Does the application need to link multiple login methods to a single user identity? 4. Does the application need roles, permissions, or access control beyond basic authentication? 5. Does the application need customer accounts, organizations, companies, or approval workflows? 6. What resources or features should be gated by the user's identity or role? 7. Who can approve, suspend, or remove users? 8. Is there a backend team available to integrate Authing into the application? 9. What should happen after the user is authenticated? 10. Does the application need to integrate with AWS China or another cloud platform? 11. Are the required features available on the Authing pricing plan the client intends to use? 12. Who will own and manage the Authing account and tenant? ## What AppInChina can help with Depending on the project scope, AppInChina can help clients understand: * Whether Authing is an appropriate fit for the application's requirements * Which Authing features are relevant to the use case * What information and access are needed from the client * What work is required from the client's backend, mobile, or web teams * How Authing fits into the broader China launch or localization plan * What risks or limitations should be considered before implementation Implementation details, SDK setup, and API-specific behavior should be confirmed against the official Authing documentation. ## Official documentation * [Authing documentation](https://docs.authing.cn/en/) * [Authing pricing](https://www.authing.cn/pricing) * [Authing website](https://www.authing.cn/) Note: some pages may only be available in Chinese. Browser auto-translate works well for most pages. If anything is unclear after translation, reach out to our team. --- China cloud identity platforms are managed identity services offered by major China cloud providers, primarily Alibaba Cloud and Tencent Cloud. They provide user registration, login, account management, and identity access control as a managed service within the China cloud environment. This page explains what China cloud identity platforms do, where they fit, what they do not provide by itself, and what clients should consider before deciding whether to use one. For detailed setup steps, SDK references, and API documentation, clients and developers should refer to the official platform documentation linked at the end of this page. ## What China cloud identity platforms are China cloud identity platforms are managed CIAM (Customer Identity and Access Management) or IDaaS (Identity as a Service) products. They handle the infrastructure layer of user authentication and identity management so that teams do not need to build and maintain these systems from scratch. Because they run within China cloud infrastructure, they are designed to serve users in Mainland China with low latency and within the regional compliance environment. In simple terms, these platforms help answer this question: > Who is this user, and are their credentials valid — within a China-hosted environment? After that, the application still needs to decide what that user is allowed to do. ## Where China cloud identity fits China cloud identity platforms can be used as the authentication and identity management layer in an application hosted on Alibaba Cloud or Tencent Cloud. They can provide: * User registration and login * Password reset and account recovery * SMS OTP verification * MFA options * Social login integration, including WeChat * User directory and profile management * Session and token management * Admin console for user management * Risk controls and access policies However, they do not provide the full application-side authorization and access control layer by itself. If your application requires any of the following, they must be handled separately by your backend or application layer: * Customer verification and approval workflows * User-to-customer or user-to-organization mapping * Application-level roles and permissions * File or resource access control * User suspension logic tied to business rules * Audit logs for compliance or transactional records * Order history or business data records * Application-level enterprise SSO or federation beyond what the platform supports ## When a China cloud identity platform is a good fit A China cloud identity platform may be a good fit when: * Your application is primarily hosted on Alibaba Cloud or Tencent Cloud in a China region. * You want to keep identity infrastructure close to your China-region user base. * You want a managed identity platform that integrates naturally with your existing China cloud stack. * You want to reduce the engineering effort of building registration, login, and recovery flows from scratch. * You may need enterprise-style features such as SSO, federation, or identity policies in the future. * You have, or plan to build, a backend system that handles permissions, customer records, and access control. ## What a China cloud identity platform should be paired with Like other managed identity platforms, China cloud identity platforms handle authentication. They should be paired with the application's own backend, user database, and authorization logic for everything beyond confirming who the user is. For example: * If users need to be approved before accessing the service, the approval workflow should be handled by the application. * If users belong to specific customers, companies, or organizations, that mapping should be handled by the application. * If users have different roles or permissions, those rules should be handled by the application. * If users need access to specific files, records, or services, access control should be handled by the application. * If the system needs audit logs, download logs, or compliance records, those should be handled by the application. The application should maintain its own internal user record. The cloud identity platform's user identifier should be linked to this internal record, not used as the primary key for application data. ## Key considerations ### Infrastructure alignment China cloud identity platforms are designed to work within the Alibaba Cloud or Tencent Cloud environment. If your application is not primarily hosted on one of these platforms, a different managed identity solution may be more straightforward to integrate. ### Account linking If the application supports multiple login methods, such as WeChat Login, SMS OTP, and password login, the identity platform needs to link these to a single user identity. The application should verify that its own internal user record is correctly linked to the platform identity. ### Compliance and data residency Because these platforms run in China cloud regions, data residency is within Mainland China by default. Clients should confirm whether this aligns with their compliance requirements, particularly if the application also serves users outside Mainland China. ### WeChat Login through a China cloud identity platform Both Alibaba Cloud IDaaS and Tencent Cloud CIAM support WeChat Login as a social login option. Routing WeChat Login through the cloud identity platform rather than integrating it directly into the backend can simplify the integration. However, the same WeChat Open Platform requirements still apply. The WeChat application setup, AppID, AppSecret, and callback configuration still need to be in place. The identity platform provides the integration layer, not the WeChat account itself. For more on WeChat Login requirements, see the [WeChat Login](./wechat-login) page. ## How China cloud identity fits into the application at a high level ```text User registers or logs in | v Cloud identity platform verifies credentials and issues a token | v Application backend receives and validates the token | v Application backend looks up the internal user record | v Application applies its own permission and access rules | v User accesses the permitted resources or features ``` ## Available platforms ### Alibaba Cloud IDaaS Alibaba Cloud IDaaS includes CIAM capabilities for customer-facing applications. It is a good fit when the application's infrastructure is centered on Alibaba Cloud. * [Product page](https://www.aliyun.com/product/idaa) * [Documentation (Chinese)](https://help.aliyun.com/zh/idaa) * [Documentation (English)](https://www.alibabacloud.com/help/en/idaa) ### Tencent Cloud CIAM Tencent Cloud CIAM is a managed identity platform for customer-facing registration, login, and identity access control. It is a good fit when the application's infrastructure is centered on Tencent Cloud. * [Product documentation](https://cloud.tencent.com/document/product/1441) * [Console setup guide](https://cloud.tencent.com/document/product/1441/62405) ## Questions to confirm before choosing a China cloud identity platform Before deciding whether a China cloud identity platform is the right fit, the following questions should be confirmed: 1. Is the application primarily hosted on Alibaba Cloud or Tencent Cloud in a China region? 2. What login methods are required? * Password-based login * SMS OTP * WeChat Login * Other social login * MFA 3. Does the application need user registration to be open, invite-only, or pre-approved? 4. Does the application need to link multiple login methods to a single user identity? 5. Does the application need roles, permissions, or access control beyond basic authentication? 6. Does the application need customer accounts, organizations, companies, or approval workflows? 7. What resources or features should be gated by the user's identity or role? 8. Who can approve, suspend, or remove users? 9. Is there a backend team available to integrate the identity platform into the application? 10. Are there compliance or data residency requirements that affect which cloud region or provider can be used? 11. Does the application also serve users outside Mainland China, and if so, how will identity be handled across regions? 12. Who will own and manage the cloud identity platform account and configuration? ## What AppInChina can help with Depending on the project scope, AppInChina can help clients understand: * Whether a China cloud identity platform is an appropriate fit for the application's requirements * Which platform aligns better with the existing cloud infrastructure * What information and access are needed from the client * What work is required from the client's backend, mobile, or web teams * How the identity platform fits into the broader China launch or localization plan * What risks or limitations should be considered before implementation Implementation details, SDK setup, and API-specific behavior should be confirmed against the official platform documentation. --- Custom backend login means the application implements its own authentication system, backed by its own database and APIs. Common forms include email and password login, phone number and SMS OTP login, and magic link login. This page explains what custom backend login involves, where it fits, what it requires from the client and their team, and what clients should consider before deciding whether to go this route. ## What custom backend login is Custom backend login means the application owns and operates its own authentication layer rather than delegating it to a managed identity platform. The application is responsible for: * Storing user credentials securely * Verifying credentials at login * Issuing and managing sessions or tokens * Handling password reset and account recovery * Sending SMS or email verification messages * Protecting login flows against abuse In simple terms, custom backend login means the application answers this question itself: > Who is this user, and are their credentials valid? There is no third-party identity platform handling that step on the application's behalf. ## Where custom backend login fits Custom backend login can be used when the application already has a backend and the team has the capacity to build and maintain an authentication system. It gives the application full control over the authentication UX, data model, security rules, and integration with the rest of the system. However, this control comes with full ownership of the security and operational responsibilities that a managed identity platform would otherwise handle. ## When custom backend login is a good fit Custom backend login may be a good fit when: * The application already has a backend and a development team that will own the authentication system. * There are specific requirements that managed identity platforms do not easily support, such as highly custom login flows, unusual account structures, or deep integration with an existing user database. * The team has the capacity to implement and maintain password storage, session management, OTP delivery, rate limiting, and abuse prevention. * Avoiding vendor dependency on a third-party identity platform is a priority. * The application has already been partially built with custom authentication in place. Custom backend login is generally more demanding to implement and maintain than a managed solution. For teams that do not have a strong reason to go custom, a managed identity platform such as Authing is usually the lower-risk starting point. ## What custom backend login requires from the team Unlike a managed identity platform, custom backend login does not come with built-in flows, admin tooling, or infrastructure. The team is responsible for building and maintaining: * User registration flow * Login flow with credential verification * Secure password storage (hashing, salting) * SMS OTP or email OTP delivery and verification * Session or token issuance and management * Token refresh and expiry handling * Password reset flow * Account recovery flow * Rate limiting and brute-force protection * Abuse and bot prevention * Monitoring and incident response for authentication failures Each of these is a security-sensitive component. The team should have experience building secure authentication systems or be willing to invest in getting this right. ## What the application still needs regardless of approach Whether using a managed platform or a custom backend, the application still needs: * A stable internal user ID for each user — not derived from credentials, not editable by the user, used as the canonical identifier for all account-bound data * An account recovery path that allows users to regain access without losing their data * Logic to decide what each authenticated user is allowed to do, which is always the application's responsibility and is not handled by the authentication layer alone ## Key security considerations Password storage must use a strong, slow hashing algorithm. Storing plain-text or weakly hashed passwords is a serious security risk. OTP and magic link delivery depends on SMS or email infrastructure. The team needs a reliable delivery provider and should plan for delivery failures and abuse scenarios. Sessions and tokens must be managed carefully, including expiry, revocation, and protection against theft. Rate limiting and abuse prevention are required to protect login and registration endpoints from brute-force attacks and credential stuffing. These are well-documented problems with established solutions. The OWASP references at the end of this page are a good starting point. ## How custom backend login fits into the application at a high level ```text User submits credentials | v Application backend verifies credentials against its own database | v Application backend issues its own session or token | v Application backend looks up the internal user record | v Application applies its own permission and access rules | v User accesses the permitted resources or features ``` ## Combining custom backend login with WeChat Login Some applications use custom backend login as the primary method while also supporting WeChat Login as an additional option. In this case, the WeChat identity should be linked to the same internal user record as the custom login credentials. The application needs a clear account linking strategy to avoid duplicate accounts when a user logs in with different methods. For more on WeChat Login requirements, see the [WeChat Login](./wechat-login) page. ## Questions to confirm before choosing custom backend login Before deciding whether to build a custom backend login system, the following questions should be confirmed: 1. Does the application already have a backend, and does the team have capacity to own an authentication system? 2. What login methods are required? * Email and password * Phone number and SMS OTP * Magic link * WeChat Login as an additional method 3. Is there a specific requirement that a managed identity platform cannot meet? 4. Does the team have experience building secure authentication systems, including password storage, rate limiting, and abuse prevention? 5. Is there a plan for SMS or email OTP delivery infrastructure? 6. What is the account recovery flow, and who is responsible for supporting users who lose access? 7. Does the application need to link multiple login methods to a single user identity? 8. Does the application need roles, permissions, or access control beyond basic authentication? 9. Who can approve, suspend, or remove users? 10. Has the cost and timeline of building and maintaining a custom authentication system been accounted for, compared to using a managed platform? ## What AppInChina can help with Depending on the project scope, AppInChina can help clients understand: * Whether custom backend login is the right fit, or whether a managed platform would better serve the use case * What the baseline requirements are for a secure and compliant authentication system * How custom backend login fits into the broader China launch or localization plan * What risks or limitations should be considered before committing to a custom approach Implementation, security architecture, and ongoing maintenance are the responsibility of the client's development team. ## Reference documentation * [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html) * [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) --- WeChat Login allows users to sign in to an application using their existing WeChat identity. It is commonly used for China-facing apps, websites, customer portals, and services where users are likely to already have WeChat accounts. This page explains what WeChat Login does, where it fits, what it does not provide by itself, and what clients should consider before deciding whether to use it. For detailed platform-specific implementation steps, clients and developers should refer to the official WeChat documentation linked at the end of this page. ## What WeChat Login is WeChat Login is an authentication method. It allows an application to confirm that a user has authorized login through WeChat and to receive WeChat user identifiers that can be linked to the application's own user account system. In simple terms, WeChat Login helps answer this question: > Which WeChat user is trying to log in? After that, the application still needs to decide what that user is allowed to do. For example, if a customer portal uses WeChat Login, WeChat can help identify the user. The portal still needs its own backend logic to decide whether that user is an approved customer, which company or account they belong to, and which files or features they can access. ## Where WeChat Login fits WeChat Login can be used as part of a broader identity and access management system. It can be used for: * User authentication * Social login * Account binding * China-localized login experiences * Reducing the need for users to remember another password * Linking a WeChat identity to an existing application account However, WeChat Login does not provide the full application-side identity and access management layer by itself. If your application requires any of the following, they must be handled separately by your backend, admin system, or identity management system: * Customer verification * User approval workflows * User-to-customer or user-to-organization mapping * Roles and permissions * File or resource access control * User suspension and revocation * Admin user management * Audit logs * Backup login or account recovery * Enterprise SSO, MFA policies, or organization-level identity governance In these cases, WeChat Login can still be used, but it should be treated as one authentication method connected to your own user management and authorization system. ## When WeChat Login is a good fit For China-facing applications, WeChat Login is often considered because many users already have WeChat accounts and are familiar with WeChat-based authorization flows. WeChat Login may be a good fit when: * Most target users are expected to have WeChat accounts. * You want to provide a familiar China-local login method. * You want to reduce friction compared with password-based login. * You want users to bind a WeChat identity to an existing application account. * You have, or plan to build, a backend system that manages users, sessions, permissions, and access control. * You want WeChat identity to be one part of a broader authentication or account-binding flow. ## What WeChat Login should be paired with WeChat Login can be used in applications that require customer identity management, roles, permissions, approval workflows, or enterprise access control. However, WeChat Login should not be expected to provide those functions by itself. In those cases, WeChat Login should be paired with the application's own backend, admin system, or identity management layer. For example: * If users need to be approved before accessing the service, the approval workflow should be handled by the application. * If users belong to specific customers, companies, or organizations, that mapping should be handled by the application. * If users have different roles or permissions, those rules should be handled by the application. * If users need access to specific files, records, or services, access control should be handled by the application. * If users need to be suspended, revoked, or removed, that should be handled by the application. * If the system needs audit logs, download logs, or compliance records, those should be handled by the application. * If users may not have WeChat accounts, the application should provide another login or recovery method. * If the system needs enterprise SSO, MFA policies, or organization-level identity governance, WeChat Login should be integrated as one authentication method within that broader identity architecture. The key question is not whether WeChat Login can be used in these systems. It can. The key question is whether the required user management, authorization, and governance features will be handled somewhere else in the architecture. ## Common WeChat Login scenarios The correct WeChat Login setup depends on where users access your service. ### Native Android and iOS app login This applies when users log in from a native mobile app. Typical use case: > A user opens an Android or iOS app, taps "Log in with WeChat," authorizes through the WeChat app, and returns to the mobile app. This normally requires a WeChat Open Platform Mobile Application setup. For Android, the setup usually involves the app package name and app signature. For iOS, the setup usually involves the Bundle ID and Universal Links. This is the correct option when the login flow happens inside a native Android or iOS app. ### Website QR-code login This applies when users log in from a browser, especially from a desktop browser. Typical use case: > A user opens a website or customer portal, clicks "Log in with WeChat," scans a QR code with WeChat, authorizes login, and is redirected back to the website. This normally requires a WeChat Open Platform Website Application setup. This is the correct option for browser-based portals or websites. ### Official Account webpage authorization This applies when users access a webpage from inside WeChat, usually through a WeChat Official Account menu, article, or message. Typical use case: > A user opens a link inside WeChat and the webpage identifies the user through the associated Official Account authorization flow. This is useful when the user journey starts inside WeChat. ### Mini Program login This applies when users access the service through a WeChat Mini Program. Typical use case: > A user opens a Mini Program and logs in through the Mini Program's WeChat login flow. This requires a WeChat Mini Program setup and is separate from native mobile app login or website login. ## How WeChat Login works at a high level Although the details vary depending on the scenario, the general flow is similar: ```text User starts WeChat Login | v User authorizes through WeChat | v Application receives a temporary authorization code | v Application backend exchanges the code with WeChat | v WeChat returns user identifiers | v Application backend links the WeChat identity to a local user | v Application issues its own session or token ``` The important point is that the application backend remains responsible for the application's own user session, permissions, and access control. The WeChat access token should not be treated as the application's own session token. ## Key identity concepts ### `openid` `openid` is a WeChat user identifier within a specific WeChat application context. The same person may have different `openid` values across different WeChat channels, such as: * Native mobile app * Website application * Official Account * Mini Program Because of this, `openid` should normally be stored together with the WeChat application or channel it belongs to. ### `unionid` `unionid` can identify the same WeChat user across multiple WeChat applications under the same WeChat Open Platform account, when available. This can be useful when the same service uses multiple WeChat channels, such as a mobile app, website, Official Account, or Mini Program. However, `unionid` may not always be available. The application should be designed to handle cases where only `openid` is available. ### Local application user The application should still maintain its own internal user account. The local application user is what should be used for: * Customer records * Permissions * Organization or company mapping * File access * Order history * Audit logs * User suspension or revocation WeChat identifiers should be linked to this local user account, not replace it entirely. ## Backend requirements A backend is normally required for a secure WeChat Login implementation. At a high level, the backend is responsible for: * Receiving the temporary authorization code * Exchanging the code with WeChat * Receiving the WeChat user identifiers * Finding or creating the local application user * Binding the WeChat identity to the local user * Applying customer verification and permission rules * Issuing the application's own session or token The WeChat AppSecret should only be stored on the backend. It should not be included in mobile app code, frontend JavaScript, Mini Program frontend code, or public repositories. ## Client-side work required The work required from the client depends on the login scenario. For native Android and iOS app login, the client or app developer may need to provide: * Android package name * Android app signature * iOS Bundle ID * iOS Universal Link * App Store or Android app store links, if available * App icon and screenshots * App ownership or authorization information * Access to update the Android and iOS apps * A backend endpoint or backend team to support the login integration For website QR-code login, the client may need to provide: * Website domain * Login callback URL * Website name and description * Website logo and screenshots * Backend support for the login callback * Website ownership or authorization information For Official Account or Mini Program login, the client may need to provide: * Official Account or Mini Program ownership information * Relevant AppID or account access * Domain and authorization settings * Backend support for the login flow ## iOS Universal Links For iOS mobile app login, Universal Links are usually required. A Universal Link is an HTTPS URL associated with the iOS app. It allows iOS to return the user from WeChat back into the correct app after authorization. Setting up Universal Links usually requires coordination between: * The app owner * The iOS developer * The team that controls the relevant domain * The WeChat Open Platform administrator The client should expect to provide or configure: * A domain controlled by the app owner * HTTPS support * Apple Team ID * iOS Bundle ID * Associated Domains configuration in the iOS app * The required Apple association file on the domain The exact implementation should follow Apple and WeChat's official documentation. ## Ownership and account management The WeChat Open Platform application, Official Account, or Mini Program should normally be owned by the same legal entity that owns the app, website, or customer relationship. Using a third party's WeChat account can create issues such as: * Incorrect branding on the authorization screen * Long-term dependency on the third party * Migration complexity * Unclear control over AppID and AppSecret * Unclear responsibility for security and data protection * Potential issues during client offboarding If AppInChina helps create or manage the WeChat setup on behalf of a client, the responsibility model should be agreed in advance. At minimum, the following should be clarified: * Who owns the WeChat Open Platform account * Who owns the AppID and AppSecret * Who manages callback domains or Universal Links * Who stores the AppSecret * Who maintains the backend integration * Who handles user support and access issues * What happens if the client wants to migrate away later ## Questions to confirm before choosing WeChat Login Before deciding whether WeChat Login is the right fit, the following questions should be confirmed: 1. Where will users access the service? * Android app * iOS app * Desktop browser * Mobile browser * Page opened inside WeChat * WeChat Mini Program 2. Is WeChat Login expected to be the only login method, or one of several login methods? 3. Should any WeChat user be able to create an account, or should users be pre-approved? 4. Does the application need customer accounts, organizations, companies, or roles? 5. What should happen after the user is authenticated? 6. What resources or features should the user be able to access? 7. Who can approve, revoke, or manage users? 8. Is a backup login or account recovery method required? 9. Does the application need to support users who do not have WeChat accounts? 10. Does the application need to link the same user across mobile app, website, Official Account, or Mini Program? 11. Who will own and manage the WeChat Open Platform, Official Account, or Mini Program setup? ## What AppInChina can help with Depending on the project scope, AppInChina can help clients understand: * Which WeChat Login scenario is most appropriate * What WeChat account or application setup is required * What information is needed from the client * What work is required from the client's mobile, web, or backend teams * How WeChat Login fits into the broader China launch or localization plan * What risks or limitations should be considered before implementation Implementation details, SDK integration steps, and API-specific behavior should be confirmed against the official WeChat documentation. ## Official documentation The following official WeChat documentation should be reviewed depending on the integration type. ### Mobile app login * [Mobile App WeChat Login Development Guide](https://developers.weixin.qq.com/doc/oplatform/Mobile_App/WeChat_Login/Development_Guide.html) * [Authorized API calls and UnionID](https://developers.weixin.qq.com/doc/oplatform/Mobile_App/WeChat_Login/Authorized_API_call_UnionID.html) * [Android access guide](https://developers.weixin.qq.com/doc/oplatform/Mobile_App/Access_Guide/Android.html) * [iOS access guide](https://developers.weixin.qq.com/doc/oplatform/Mobile_App/Access_Guide/iOS.html) ### Website login * [Website application WeChat Login](https://developers.weixin.qq.com/doc/oplatform/Website_App/WeChat_Login/Wechat_Login.html) ### Official Account webpage authorization * [WeChat webpage authorization](https://developers.weixin.qq.com/doc/offiaccount/OA_Web_Apps/Wechat_webpage_authorization.html) ### Mini Program login * [Mini Program login](https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/login.html) ## Summary WeChat Login is a useful authentication method for China-facing applications, especially when users are expected to already have WeChat accounts. It can be used as part of a broader identity and access management system, but it should not be treated as the full identity and access management system by itself. The application still needs its own backend, user database, account mapping, permissions, revocation logic, session management, and audit logging. The correct WeChat Login setup depends on where users access the service: * Native Android or iOS app: Mobile Application WeChat Login * Browser-based portal or website: Website QR-code login * Page opened inside WeChat: Official Account webpage authorization * WeChat Mini Program: Mini Program login Before implementation, clients should confirm the access channel, ownership model, backend requirements, user management requirements, and whether WeChat Login is expected to be the only login method or one part of a broader authentication system. --- Most apps and services need a login system to reliably identify users and associate their data, access, and history with a single account over time. This section explains what login systems need to do in China-facing applications, which solutions are available, and what to consider before choosing one. ## Where to start Read the [Introduction & Requirements](./introduction.md) page first. It covers: * What a login system needs to do at minimum * The real-name authentication legal requirement for apps with social or interactive features * A comparison of available solutions * Questions to confirm before choosing a solution Then go to the solution page that best matches your situation. ## Solutions - [Authing](./solutions/authing.md) — a managed identity platform; the recommended default for most clients starting from scratch - [WeChat Login](./solutions/wechat-login.md) — authentication via WeChat; commonly used for China-facing apps, often alongside a managed platform or custom backend - [China Cloud Identity](./solutions/china-cloud-identity.md) — managed identity platforms from Alibaba Cloud and Tencent Cloud; a good fit when infrastructure is already on one of these providers - [Custom Backend Login](./solutions/custom-backend.md) — building and owning the authentication layer directly; suitable when there is a specific requirement a managed platform cannot meet ## Related - [Login → Payments integration](/payments/guides/login-identity) ---