Navigation
  • Stitch >
  • Users & Authentication

User Authentication Overview

Introduction

Stitch applications secure data and authorize requests based on the user that issued a given request. As a result, user authentication is a core component of the Stitch programming model and all Stitch applications must incorporate some form of authentication. Stitch will not process any requests from a client application if no user is logged in.

The goal of authentication is to uniquely identify users that interact with your Stitch application and store metadata that describes those users. You can also write dynamic rules that logically separate each user’s data and determine their access permissions.

Concepts

Authentication Providers

An authentication provider is a service that maintains information about your application’s users and allows them to verify their identity. Depending on the type of authentication, an authentication provider can also provide additional data about a user, such as their email address, birthday, or preferred locale.

Every application must have at least one provider configured and enabled before a client application can successfully connect. You can enable multiple providers in the same Stitch application to give users flexibility in how they log in.

Stitch includes several built-in authentication methods, including email/password, API keys, and OAuth 2.0 through Facebook and Google. If you prefer to use another system to authenticate users, you can integrate a custom authentication provider. You can also allow users to authenticate as temporary, anonymous user accounts that have no associated information other than a unique ID.

User Accounts

A user account represents a single, distinct user of your application. Each user account has a unique ID and is associated with at least one authentication provider identity. User accounts also include arbitrary data from each authentication provider that describe the user.

A user logs in to their account by providing a set of credentials to an authentication provider. If the credentials are valid, the provider returns a unique id that proves the user’s identity. If the identity is already associated with a particular user account, that account is logged in and becomes the active user. By default, Stitch creates a new user account whenever a user logs in through a particular provider for the first time; however, you can also link new identities to an existing user to allow them to log in with multiple methods.

For more information about how Stitch models users and manages sessions, see Stitch Users.

Active Users

The active user of a Stitch application is a logged in user account that is associated with application requests. When Stitch receives a request from a client application, it executes the request in the context of the active user, replacing any dynamic references to the user (e.g. %%user in a JSON expression or context.user in a Function) with the active user’s information.

Multiple user accounts can log in to an application simultaneously, but only one account can be active at any given time. For more information on managing multiple logged in users in a client application, see Working with Multiple User Accounts.

System Users

A system user is an internal user that has advanced privileges and automatically bypasses all rules. You can configure Functions and incoming webhooks to run in the context of a system user instead of the user account that issued a request. This approach is particularly useful if you need unrestricted access to MongoDB CRUD and aggregation operations.

Security Warning

Stitch rules do not apply to system users, which means that Functions and webhooks that run as a system user can be a security liability. Ensure that you do not expose these functions to unauthorized users.

For example, instead of calling a Function that runs as system directly from a client application, you could call it inside of a second, non-system Function and then call this second Function from the client. The non-system Function can use function context to check if the active user is allowed to call the system function, e.g.:

exports = function() {
  const activeUser = context.user
  const adminUserId = context.values.get("adminUserId");
  if(activeUser.id == adminUserId) {
    return context.functions.execute("mySystemFunction");
  } else {
    throw Error("This user is not allowed to execute the system function")
  }
}