Skip to main content

When configuring the backend as an API server, the following implementations are necessary:

  • Store the token (JWT), which is the authentication information for the SaaSus Platform, in the browser's local storage.
  • SaaS Platform users authenticate themselves using JWT.
  • The frontend is implemented with React, Vue.js, etc.
  • The backend API server is implemented in PHP / TypeScript / Go / Python / C# / JAVA, etc.

Process Flow (Login to User List Display)

SaaSus Platform API Process Flow

Implementation Sample

1. Frontend Implementation

1.1. Description of the Implementation Sample

1.1.1. Post-Authentication Redirect Screen

When you log in from the login screen generated by the SaaSus Platform, the URL set as the post-authentication redirect is called.

To perform a test run using this implementation sample, set it as http://localhost:3000/callback.

Post-Authentication Redirect

At the post-authentication redirect, a temporary code necessary for obtaining authentication information is passed in the query parameter (code=xxxxx). Implement the process to obtain JWT using this temporary code and save it in local storage.

1.1.2. Self-Signup Screen

  • React implementation sample (In preparation)

It is necessary to check if the user is logged in, so call the API to get user information and confirm that the user is logged in.
Use the JWT stored in local storage for the API call.
By being able to obtain user information, you can confirm that the user is logged in.

The process for self-signup should be implemented according to whether self-signup is used or not.
If self-signup is not used, the screen for self-signup is not needed.

If self-signup is used, the process for self-signup will only be executed during the first login.
Whether it is the first login can be determined by whether the logging-in user is linked to a tenant.

1.1.3. User List Screen (Homepage)

Regarding the use of user information obtained from the /userinfo endpoint:

  • tenants array:
    In the design of your SaaS,
    if it is fixed to 1 tenant per 1 user, use tenants[0] fixed.
    If a user belongs to multiple tenants, it is necessary to decide which tenant to use.
    Example: Users linked to multiple tenants will see a tenant selection screen after logging in to choose a tenant.

  • envs array:
    id(name)【1(dev), 2(stg), 3(prod)】
    dev, stg, prod do not refer to your SaaS's environments.
    Example: In your SaaS's production environment, if users use test users as a sandbox, use 1(dev), 2(stg). Normally, use 3(prod).

  • roles array:
    In the design of your SaaS,
    if it is fixed to 1 role per 1 user, use roles[0] fixed.
    If a user has multiple roles, an implementation to check all roles is needed.
    Example: If it is possible to assign two permissions such as a general user and administrator,
    when displaying an admin-only management screen, an implementation to reference all roles is needed.

1.2. How to Use the Implementation Sample

2. Backend Implementation

2.1. Description of the Implementation Sample

2.1.1. JWT Retrieval API

2.1.2. User Information Retrieval API

2.1.3. Self-Signup API

  • Go(echo) implementation sample (Preparation in progress)
  • Python implementation sample (Preparation in progress)

In order to confirm that the API request is from the user who logged into the SaaSus Platform, it is always necessary to confirm the login by retrieving the user information. The self-signup process is as follows:

  • Prerequisite) The user who self-signs up becomes the administrator of the new tenant:
    • a. Tenant creation
    • b. Link the logged-in user to the created tenant
    • c. Set the logged-in user as the admin of the tenant

2.1.4. User List Retrieval API

It is always necessary to confirm the login by retrieving the user information to verify that the API request originates from the user that is logged into SaaSus Platform.

2.2. How to use the implementation example