Managing users | LoopBack Documentation

LoopBack's built-in User model provides essential user management features.

See also:

Page Contents

Overview

LoopBack’s built-in User model provides essential user management features such as:

Registration and confirmation via email.
Login and logout.
Creating an access token.
Password reset.

Important: If your application requires only a user model with email and password fields, then you can use the built-in User model for user management. Otherwise, you must create your own custom model (named something other than “User,” for example “Customer” or “Client”) that extends the built-in User model rather than use the built-in User model directly.

Starting with version 3.3.0, LoopBack supports applications with multiple models based on the User model. (previous versions allowed only one). For more information, see Access control with multiple user models.

Creating and authenticating users

The basic process to create and authenticate users is:

Register a new user with the User.create() method, inherited from the generic PersistedModel object. See Registering users for more information.
Log in a user by calling User.login() to get an access token. See Logging in users for more information.
Make subsequent API calls using the access token. Provide the access token in the HTTP header or as a query parameter to the REST API call, as shown in Making authenticated requests with access tokens.

Performance tip

To improve performance during login and user creation, try installing native bcrypt.

$ npm install --save bcrypt

Warning: To run this package, you must install compiler tools on your system, since it’s a binary package.

Understanding the built-in User model

By default, a LoopBack application has a built-in User model defined by user.json (this file is part of the LoopBack framework. Don’t modify it; rather, follow the procedure in Extending built-in models).

Tip: For a basic introduction to how the LoopBack user model performs authentication, see Introduction to User model authentication.

Default access controls

The built-in User model has the following ACL:

{
  "name": "User",
  "properties": {
    ...
    "acls": [{
      "principalType": "ROLE",
      "principalId": "$everyone",
      "permission": "DENY"
    }, {
      "principalType": "ROLE",
      "principalId": "$everyone",
      "permission": "ALLOW",
      "property": "create"
    }, {
      "principalType": "ROLE",
      "principalId": "$owner",
      "permission": "ALLOW",
      "property": "deleteById"
    }, {
      "principalType": "ROLE",
      "principalId": "$everyone",
      "permission": "ALLOW",
      "property": "login"
    }, {
      "principalType": "ROLE",
      "principalId": "$everyone",
      "permission": "ALLOW",
      "property": "logout"
    }, {
      "principalType": "ROLE",
      "principalId": "$owner",
      "permission": "ALLOW",
      "property": "findById"
    }, {
      "principalType": "ROLE",
      "principalId": "$owner",
      "permission": "ALLOW",
      "property": "updateAttributes"
    }, {
      "principalType": "ROLE",
      "principalId": "$everyone",
      "permission": "ALLOW",
      "property": "confirm"
    }, {
      "principalType": "ROLE",
      "principalId": "$everyone",
      "permission": "ALLOW",
      "property": "resetPassword",
      "accessType": "EXECUTE"
    }],
    //...
  }
}

The above ACL denies all operations to everyone, then selectively allows:

Anyone to create a new user (User instance).
Anyone to log in, log out, confirm their identity, and reset their own password.
A user to perform deleteById, findById, and updateAttributes on their own User record (instance).

Important:

You cannot directly modify built-in models such as the User model with the ACL generator.

However, you can create a custom model that extends the built-in User model, then use the ACL generator to define access controls that are added to those of the default User model. For example, you could create a Customer or Client model that extends the built-in User model, and then modify that model’s ACL with the tool. Since a model doesn’t inherit ACLs from its base model, you must define ACLs for the new custom model.

User realms

See Partitioning users with realms.

Security considerations

When a user’s account is compromised (for example their password is leaked or the attacker gains access to their email account), the app needs to be able to prevent continued use of the hijacked account.

To address this case, LoopBack invalidates access tokens (logs out sessions) when a change of password or email is detected. The access token used to request the change (the current session) is preserved.

Important:

To preserve backwards compatibility, LoopBack 2.x LTS does not enable this functionality by default, but prints a startup warning to notify the application developer about a potential security issue. See AccessToken invalidation in LB 2.x for more details.

Tags: authentication