This article is for LoopBack 2.x, which is no longer supported. Please see the corresponding article for 3.x.

Managing users

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.

LoopBack 2.x allows only one model in an application that is based on the User model.

Watch this video for an introduction to user management in LoopBack:

[フレーム]

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

See Access token invalidation.

Tags: authentication