Skip to main content

Custom Backend Login

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​

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