Auth
Authentication is the process of determining the identity of a user. Common ways of authenticating a user are by asking the user for secret credentials (username & password) or by a third-party authentication provider such as Facebook or Google login.
Authorization is a related concept, which means that once we have verified the identity of a user, we can then determine what that user is allowed to do. For example, a user may be authorized to view a product, but not to edit it.
The term auth is shorthand for both authentication and authorization.
Auth in Vendure applies to both administrators and customers. Authentication is controlled by the configured AuthenticationStrategies, and authorization is controlled by the configured Roles and Permissions.
Administrator auth
Administrators are required to authenticate before they can perform any operations in the Admin API.
Here is a diagram of the parts that make up Administrator authentication:
Roles can be created to allow fine-grained control over what a particular administrator has access to (see the section below).
Customer auth
Customer only need to authenticate if they want to access a restricted operation related to their account, such as viewing past orders or updating an address.
Here are the parts that make up Customer authentication:
Guest customers
Vendure also supports guest customers, meaning that a customer can place an order without needing to register an account, and thus not getting an associated user or role. A guest customer, having no roles and thus no permissions, is then unable to view past orders or access any other restricted API operations.
However, a guest customer can at a later point register an account using the same email address, at which point they will get a user with the "Customer" role, and be able to view their past orders.
Roles & Permissions
Both the Customer and Administrator entities relate to a single User entity which in turn has one or more Roles for controlling permissions.
In the example above, the administrator Sam Bailey has two roles assigned: "Order Manager" and "Catalog Manager". An administrator can have any number of roles assigned, and the permissions of all roles are combined to determine the permissions of the administrator. In this way, you can have fine-grained control over which administrators can perform which actions.
There are 2 special roles which are created by default and cannot be changed:
- SuperAdmin: This role has all permissions, and cannot be edited or deleted. It is assigned to the first administrator created when the server is started.
- Customer: This role is assigned to all registered customers.
All other roles can be user-defined. Here's an example of an "Inventory Manager" role being defined in the Admin UI:
Native authentication
By default, Vendure uses a username/email address and password to authenticate users, which is implemented by the NativeAuthenticationStrategy.
There is a login mutation available in both the Shop API and Admin API which allows a customer or administrator to authenticate using
native authentication:
See the Managing Sessions guide for how to manage authenticated sessions in your storefront/client applications.
External authentication
In addition to the built-in NativeAuthenticationStrategy, it is possible to define a custom AuthenticationStrategy which allows your Vendure server to support other authentication methods such as:
- Social logins (Facebook, Google, GitHub, etc.)
- Single Sign-On (SSO) providers such as Keycloak, Auth0, etc.
- Alternative factors such as SMS, TOTP, etc.
Custom authentication strategies are set via the VendureConfig.authOptions object:
In the above example, we define the strategies available for authenticating in the Shop API and the Admin API. The NativeAuthenticationStrategy is the only one actually provided by Vendure out-of-the-box, and this is the default username/email + password strategy.
The other strategies would be custom-built (or provided by future npm packages) by creating classes that implement the AuthenticationStrategy interface.
Let's take a look at a couple of examples of what a custom AuthenticationStrategy implementation would look like.
Custom authentication examples
Google authentication
This example demonstrates how to implement a Google login flow.
Storefront setup
In your storefront, you need to integrate the Google sign-in button as described in "Integrating Google Sign-In into your web app". Successful authentication will result in a onSignIn function being called in your app. It will look something like this:
Backend
On the backend, you'll need to define an AuthenticationStrategy to take the authorization token provided by the
storefront in the authenticate mutation, and use it to get the necessary personal information on that user from
Google.
To do this you'll need to install the google-auth-library npm package as described in the "Authenticate with a backend server" guide.
Facebook authentication
This example demonstrates how to implement a Facebook login flow.
Storefront setup
In this example, we are assuming the use of the Facebook SDK for JavaScript in the storefront.
An implementation in React might look like this:
Backend
Keycloak authentication
Here's an example of an AuthenticationStrategy intended to be used on the Admin API. The use-case is when the company has an existing identity server for employees, and you'd like your Vendure shop admins to be able to authenticate with their existing accounts.
This example uses Keycloak, a popular open-source identity management server. To get your own Keycloak server up and running in minutes, follow the Keycloak on Docker guide.
Configure a login page & Admin UI
In this example, we'll assume the login page is hosted at http://intranet/login. We'll also assume that a "login to Vendure" button has been added to that page and that the page is using the Keycloak JavaScript adapter, which can be used to get the current user's authorization token:
We also need to tell the Admin UI application about the custom login URL, since we have no need for the default "username/password" login form. This can be done by setting the loginUrl property in the AdminUiConfig:
Backend
First we will need to be making an HTTP call to our Keycloak server to validate the token and get the user's details. We'll use the node-fetch library to make the HTTP call:
The strategy is very similar to the Google authentication example (they both use the OpenID Connect standard), so we'll not duplicate the explanatory comments here:



