All API clients which need to invoke any of the fabric platform APIs are logically defined within fabric Identity as an app. Every such app needs to secure an access token from fabric Identity before invoking other fabric APIs.


Authentication is the mechanism of proving the identity of an App or an end user of App with fabric Identity. Once the identity is confirmed an access token is generated and is signed by fabric Identity. This access token should be used by Apps as a Bearer Token to invoke fabric platform APIs.


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

App Types

App types help determine how an app would authenticate with fabric Identity and use its features.

A sysapp generates an access token to identify itself using a client-id and client-secret. These apps do not indent to use fabric Identity to authenticate their end users and instead prefer a system-to-system communication 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. sysapp

A userapp uses the fabric Identity to authenticate its end users. Based on the flow selected (Authorization Code Flow or Authorization Code Flow with PKCE), the app would need the client id and optionally a client-secret. userapp relies on the login page hosted by fabric Identity to login their end users. This is suitable for e-commerce apps that offload their authentication & authorization needs to fabric Identity. fabric Identity provides several out-of-box features for such applications which allows developers to focus more on the user buying journeys than user login, authentication and authorization journeys.

User Pools

User pools in fabric Identity help developers provide single sign-on to their application's end users.

Before using fabric Identity to implement SSO, it is important to define user pools and associate the same with one or more userapp(s). userapp(s) that use the same user pool can validate the access token of any logged in users of the pool allowing single sign-on.

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

As sysapp(s) do not authenticate any end user they are not associated with any user pools.

Access Token

An access token is a signed JWT token provided to an App after a successful authentication by fabric Identity. Access token provided to a userapp is for the individual end user of the app after a successful authentication and will be referred to as a user token. Access token provided to a sysapp is for the app itself and not for any end user and will be referred to as a system token.

Both user token and system token should be used as authentication Bearer tokens when invoking fabric's platform APIs.

user token(s) are, by default, valid for 30 min. Once expired, userapp(s) can get a new access token for the end user using the refresh token, This would avoid showing the login page again for the logged in end user.

system token(s) are, by default, valid for 10 minutes. Once expired, sysapp(s) are expected to again perform the authentication and generate a new access token. There are no refresh tokens generated for sysapp(s).

Refresh Token

Refresh token is a signed JWT token received by userapp along with the access token. This token is should be used by a userapp to get another access token once the previous one expires and withouth taking the end user through 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 apps of type webapp
  • Client Credential Flow: For all apps of type headless

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