Core Entity Types

To better leverage Wristband, it is important to understand the different types of entities you can interact with that represent the core of the platform. Those core entities are:

• Applications
• Tenants
• OAuth2 Clients
• Identity Providers
• Users

Applications

An application in Wristband is a logical representation of your own application and everything inside of it. They represent the top of our entity hierarchy, and every other entity is encapsulated inside of it (tenants, OAuth2 clients, identity providers, users, etc.). There are typically two ways to utilize Wristband applications: environments and products.

Application Environments

Wristband does not explicitly define preset environments for you. Instead, when you create a new application, you can set a flag that determines whether production-level validations will be enforced at runtime. Examples of production validations include enforcing the usage of the https protocol instead of http and preventing the use of any localhost domains. In addition, each application has its own unique domain name that can be used to associate applications to their respective environments.

For example, let's say you are developing a new application, and your company decides to use Wristband for their auth platform. At a minimum, you know you'll need one QA environment and one production environment. The way to set this up in Wristband is to create 2 Wristband applications: one for QA and one for production.

The QA environment will have production validations toggled off, while the production environment will have validations toggled on. The QA environment will be given the domain name "yourapp-qa" to make it clear which environment this represents. The production environment will simply have "yourapp" for its domain.

You can create as many applications as you need for however many environments you have.

Applications as Products

If you have more than one product line that you are taking to market, you can create a Wristband application for each product. For example, if your company created a developer tool product as well as a fintech product, you can set up them up like the following:

Multiple Products and Environments

Let's take the example above one step further. In order to successfully develop and launch the new applications for both products, you will need at minimum one development/testing environment for each product and one production environment for each product. For this example, that would result in four total applications being created in Wristband.

Tenants

A tenant is a grouping of users who have access to a common set of data, configurations, and security settings. Each tenant has its own unique set of data, configurations, and security settings, which are isolated from other tenants, but they share the underlying infrastructure and resources, such as the database and server. In Wristband, multiple tenants can live under a single application, and multiple users can live under a single tenant.

Every tenant can be customized to meet their specific needs and can represent any of the following for your application:

• Organizations
• Companies
• Teams
• Accounts
• Workspaces

OAuth2 Clients

An OAuth2 client is a piece of software that can request access to a user's resources (such as data or APIs) that are stored on a resource server. A Wristband application can have multiple associated OAuth2 clients, and each client can be used to request access to different resources or APIs, allowing for a fine-grained authorization process.

For very simple applications, it is likely you'll only need to configure a single client for your application. However, there are many cases where you might need two or more clients for your application.

Web + Mobile

Let's imagine you have an application that your users can access by the following methods: a web application in their browser served by NextJS, an Android app, and an iOS app. You would configure an OAuth2 Client for each of those three different interfaces to your application. All OAuth2 Clients here can serve all tenants and users under the application.

Microservices

You could also have a scenario where your organization has implemented a microservices architecture to power your application. In the event that multiple servers in the architecture needed a way to make authorized API requests for automated tasks, then each server can be registered as an OAuth2 Client under a Wristband application. Each server would get its own set of Client Credentials with which to obtain access tokens.

Identity Providers

An identity provider (IDP) is a service or system that manages and authenticates user identities for accessing various applications and services. It acts as a trusted third party responsible for verifying the identity of users and providing them with a secure way to authenticate and authorize their access.

Wristband Identity Provider

Wristband is an identity provider and can serve as the source of identity for your applications. We support the following authentication methods:

Login Identifiers

• Email
• Username

Login Factor

• Password
• Magic Link

External Identity Providers

Wristband also allows you to integrate with external IDPs to enable social logins and enterprise single-sign-on (SSO). An external IDP is classified as any identity provider that is not Wristband itself. For example, if you wanted to allow your users to login with Google or Okta, that could be accomplished using Wristband's external IDP support.

The key distinction between Enterprise SSO and social login lies in their target audience, integration scope, and the management of user identities.

Social Login Identity Providers

Social login is more focused on simplifying user onboarding and authentication for external applications by utilizing personal (and often social media) credentials. It relies on external platforms that are not necessarily tied to an organization (often social media platforms) for authentication, with users granting permission to share their profile information. User management is delegated to these external services, providing basic user profile information to the application post-authentication.

Enterprise SSO Identity Providers

Enterprise SSO streamlines access in corporate settings, enabling users to use a single set of credentials for multiple applications. It utilizes a centralized authentication system, granting users access to connected systems without repeated logins. It offers administrators centralized control over user access and authentication policies.

Users

Users are the representation of the human individuals accessing your application. They can have different levels of access and permissions within the application, depending on their roles and permissions. They are isolated per tenant and must always be associated with a specific IDP. Therefore, user attributes that require uniqueness, such as an email address, are required to be unique within the combination of a tenant and an IDP.