See also:
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 genericPersistedModelobject. 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.