Skip to main content

Authing

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 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​

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​

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.