OAuth 2 Clients
An OAuth 2 client is an entity that authenticates users or machines on behalf of an application.
Wristband utilizes the OIDC protocol for authenticating users and the OAuth 2 Client Credentials grant for authenticating machines. Therefore, OAuth 2 clients are required to initiate any authentication flow within Wristband. In Wristband's model, an application can have multiple clients. This allows a single Wristband application to support authenticating users from multiple interfaces. For example, a Wristband application could have a backend server client for authenticating users from their web application while also having a native client for authenticating users from their mobile application. In addition, an application could have multiple machine-to-machine clients for cross-service communication in a microservices architecture.
Client Types
Understanding the types of clients your application uses is essential for implementing appropriate security measures. There are four types of clients that Wristband supports:
- Backend Server
- Single Page Application
- Native
- Machine-to-Machine
These client types are categorized into two main classifications based on their ability to securely handle credentials and tokens:
| Client Classification | Client Types | Description |
|---|---|---|
| Public |
| These are user agents or services that cannot securely store client credentials, meaning they do not have a client secret. Public clients rely on the user's authentication, and their lack of a client secret implies reduced security compared to confidential clients. |
| Confidential |
| These are applications or services that can securely store and maintain client credentials (such as a client secret). They are capable of keeping their client credentials confidential and are trusted by Wristband to protect them as well. |
Backend Server
Backend Server client types are intended for web applications hosted on servers, allowing for secure storage of client credentials and facilitating server-to-server communication with the authorization server. They are commonly employed in MVC-style web applications, API proxies for single-page apps, hybrid architectures, and the Backend For Frontend (BFF) model, where the server interacts on behalf of both itself and the application's users.
Single Page Application
Single-page app (SPA) client types should be avoided when possible, as they expose sensitive data such as tokens to the browser, increasing the risk of security vulnerabilities and attacks.
Single-page application (SPA) client types run entirely in the user's browser. This type is for client-side JavaScript applications that will interact with Wristband APIs directly instead of through a backend server. Since SPAs cannot keep client credentials confidential, they only support the OAuth2 authorization code grant type flow with PKCE as the primary means of authentication.
Native
Native client types are intended for a mobile device (i.e., iOS or Android) or a desktop device (i.e., macOS, Windows, or Linux) that interfaces with your application. Native clients support custom Authorization URI protocols and schemes for any URLs that you configure in Wristband. Like single-page applications, native clients only support the OAuth2 authorization code grant type flow with PKCE as the primary means of authentication.
Machine to Machine
Machine-to-machine (M2M) client types are intended for servers that have zero end-user interaction and primarily deal with server-to-server workflows or automated server-side business logic. M2M clients can also be used for generating access tokens by developers looking to test APIs from command-line utilities like cURL or testing tools like Postman.
Application vs Tenant Clients
OAuth2 Clients can be owned either at the application level or at the tenant level. The main distinction is that application-level clients are considered "first-party" while tenant-level clients are considered "third-party".
Application-level / First-Party Clients
First-party clients are owned and operated by your organization, placing your application and its associated OAuth clients within the same "first-party" trust domain as Wristband. You retain administrative control over access to your application's user data and resources within Wristband. Typically, application-level clients meet the majority of your authentication needs for your applications and services.
Supported Client Types
- Backend Server
- Single Page Application
- Native
- Machine-to-Machine
Tenant-level / Third-Party Clients
Third-party clients are designed for use by entities outside your organization’s administrative control over user data and resources. In Wristband, these clients are commonly used to grant access tokens to your customers for integrating with your application's APIs, functioning similarly to API keys.
Supported Client Types
- Machine-to-Machine
Example Scenarios
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 Application + 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.
Updated 2 days ago