Concepts

App

All API clients calling any of the fabric platform APIs are logically defined within fabric Identity as apps. Each app needs to secure an access token from fabric Identity before invoking other fabric APIs.

Authentication

Authentication is the mechanism of validating the identity of an app or its end user with fabric Identity. Once the app or end user is confirmed, fabric Identity generates and signs an access token. This access token is used by apps as a bearer token to call fabric platform APIs.

Authorization

Authorization is the mechanism that restricts access to certain APIs after successful authentication. fabric Identity supports role-based access control on all of its platform APIs. This means applications and application end users can be assigned the necessary roles to access only required fabric platform APIs.

Access Control

If users are who they say they’re (authentication), and they have permission to access resources (authorization), access control verifies that the user has permission to access the requested resource.

Authentication/Authorization/Access Control Example

Pat E. Smith and Sandy Beaches both have reservations at the fabric Arms hotel. Pat, however, is a member of the hotel’s loyalty program, and will have a deluxe room, with access to the fabric Lounge, while Sandy has reserved a regular room. Pat and Sandy show up at the same time to check in. The front desk agents ask them for their driver’s licenses to make sure they’re who they say they are. This is authentication.

While preparing the key cards for the two guests, the hotel system authorizes Pat for access to a specific deluxe room, the fabric Lounge, and the hotel’s exercise room. It also authorizes Sandy for access to a specific standard room, and the hotel’s exercise room. Once made and programmed, Pat and Sandy receive their key cards.

Pat and Sandy go to their individual rooms, and their key cards provide access to their rooms. Pat goes down to exercise, and the key card reader on the exercise room acknowledges that the key card has been authorized for that room. Sandy, who is a bit of a rebel, tries to get into the fabric Lounge. The key card reader on the lounge door sends the card info to the access control server, which determines that Sandy doesn’t have access, and Sandy isn’t allowed in the lounge.

App Types

App types help determine how apps authenticate with fabric Identity and use its features.

A user app uses fabric Identity to authenticate its end users. Based on the flow selected (Authorization Code Flow or Authorization Code Flow with PKCE), the app needs a client ID and optionally a client secret. A user app relies on the login page hosted by fabric Identity to log in its end users. This is suitable for e-commerce apps that direct their authentication and authorization needs to fabric Identity. fabric Identity provides several out-of-the-box features for such applications; this allows developers to focus on the user commerce experience, rather than on user login, authentication, and authorization.

A system app generates an access token to identify itself using a client ID and client secret. These apps don’t use fabric Identity to authenticate their end users; rather they use system-to-system communications with fabric APIs. Typical use cases include applications like ERP, OMS, and WMS making calls to fabric APIs to update inventory, change pricing rules, refund orders, etc.

User Pools

User pools help developers provide single sign-on capability to their applications’ end users.

Before using fabric Identity to implement single sign-on, it’s important to define user pools and associate the pools with one or more user app. User apps in the same user pool can validate the access token of any logged-in pool user, allowing SSO within that pool.

New users registering themselves in a user app (for example, shopper self-registration in the ecommerce app) will be created in the user pools associated with the user app. Apps can then use the user’s access token to switch between user apps within the same user pool.

As system apps don’t authenticate any end users, they’re not associated with user pools.

Access Token

An access token is a signed JWT token provided to an app after successful authentication by fabric Identity. After an access token that has been provided to a user app for an individual end user has been successfully authenticated, it will be referred to as a user token. An access token provided to a system app serves the app itself, rather than an end user, and is referred to as a system token.

User tokens and system tokens should be authentication Bearer tokens when invoking fabric platform APIs.

By default, user tokens are valid for 30 minutes. Once a user’s access token is expired, a user app can get a new access token for the end user by using the refresh token. This avoids requiring the logged-in end user to go through the login page again.

By default, system tokens are valid for 10 minutes. Once expired, system apps must reauthenticate and generate a new access token. Refresh tokens aren’t generated for system apps.

Refresh Token

A refresh token is a signed JWT token received by a user app, along with the access token. A user app uses the refresh token to get a new access token once the previous token expires, without having the end user go to a login page again.

Every time a refresh token is used to get a new access token, a new refresh token is also generated. This token should be stored by the app and should be treated as sensitive as an access token itself.

OpenID Connect

OpenID Connect is an established standard based on OAuth 2.0, which defines authentication flows specific to the needs of cloud based applications. Please refer to OpenID Connect for further details.

fabric Identity supports the following flows within OpenID Connect:

• Authorization Code Flow with PKCE: Recommended for all web app apps
• Client Credential Flow: For all headless apps

For devices and applications that don’t support PKCE, fabric Identity supports the regular Authorization Code Flow (without PKCE). However, this option is recommended only when the app has a backend for frontend pattern implemented.