Authentication Providers

The Authentication Providers section allows you to configure how users authenticate in Gaio DataOS, combining traditional authentication, enhanced security, and third-party identity providers (SSO). These settings are project-wide and directly impact security, access governance, and user experience.

In this section, you can:

• Define global authentication policies.

• Enable or disable Two-Factor Authentication (2FA).

• Configure session timeout.

• Allow or restrict email/password login.

• Integrate third-party authentication providers (SSO).

Authentication Settings

• Two-factor authenticator (Google Authenticator, Microsoft Authenticator, Authy, etc.)

  • Adds an extra security layer to user login

  • Based on time-based authenticator apps

  • Strongly recommended for:

    • Corporate environments

    • Sensitive data projects

    • Multi-user workspaces

• Session timeout (zero for infinite): Defines the maximum duration of an active session.

• Activate third party providers

  • Enables external authentication providers

  • Uses OAuth / identity federation standards

Authentication Flow

User opens the login page → Selects an available authentication method. → (Optional) Completes 2FA validation. → Session starts based on the configured timeout.

Step-by-Step Guide to Obtain Google Credentials

How to Create a Google Account to Use as an Authentication Provider

1. Access Google Cloud Console

   1. Log in to the Google Cloud Console using the link: https://console.cloud.google.com/

2. Create a New Project

   1. Click on “Select a project”.

   2. A popup will open — click “New Project”.

   3. You will be redirected to the project creation page.

   4. Fill in:

      • Project name

      • Organization location (if applicable)

   5. Click “Create”

3. Google Cloud Free Trial (Optional)

   1. After creating the project, you may be redirected to the “Start your free Google Cloud trial” screen.

      1. You can agree and continue

      2. Choose whether the account will be:

         • Organizational

         • Personal

4. Access Google Auth Platform

   1. Once your account is ready, go to: https://console.cloud.google.com/products

      1. In the “All products” list, find and click “Google Auth Platform”

      2. On the main screen, under the “Overview” tab, click “Get started”

      3. Fill out the form and create a new configuration

5. Create OAuth Client

   1. After completing the setup, you will see a screen with:

      1. Metrics

      2. Project Check-up

         • In this screen, under Metrics, click “Create an OAuth client”.

6. Configure OAuth Client

   1. Set Application type to Web application

   2. Define the Application name

   3. Configure the following fields (you will need help from your developers):

      • Authorized JavaScript origins

      • Authorized redirect URIs

   4. Click “Create”

7. Retrieve Client ID and Client Secret

   1. A popup will appear showing the Client ID. Click OK.

   2. Navigate to: https://console.cloud.google.com/auth/clients

   3. Select the client you just created

   4. In the bottom-right corner, click “+ Add secret” (if one does not already exist)

   5. Create a new secret

   6. Copy and store securely:

      • Client ID

      • Client Secret

These credentials will be used to configure Google as an authentication provider in your application (OAuth 2.0).

Keep the Client Secret secure and never expose it in public repositories.

Microsoft Entra ID (Azure AD) — Step-by-step to get OAuth credentials (Client ID + Client Secret)

What you will obtain

• Tenant ID (Directory ID)

• Client ID (Application ID)

• Client Secret (Secret Value)

• Redirect URI(s) (Callback URL(s)) configured for your app

These are the typical values required to configure Microsoft as an authentication provider.

1. Access the Microsoft Entra admin center

   1. Open the Microsoft Entra admin center (Entra portal).

   2. Sign in with an account that can create app registrations (typically Application Developer or higher).

2. Create a new App Registration

   1. Go to: Entra ID → App registrations

   2. Click New registration

   3. Fill in:

      • Name: a recognizable name for your application (e.g., Gaio Auth Provider)

      • Supported account types: choose based on your scenario (most internal business cases use “Accounts in this organizational directory only”)

   4. Click Register

3. Copy the required IDs (Client ID and Tenant ID)

   1. After registration, on the app Overview page:

      1. Copy Application (client) ID → this is your Client ID

      2. Copy Directory (tenant) ID → this is your Tenant ID

4. Configure the Redirect URI (Callback URL)

   1. This step ensures Microsoft can redirect the user back to your application after sign-in.

      1. In the left menu, go to Authentication

      2. Click Add a platform

      3. Choose Web

      4. Under Redirect URIs, add the callback URL(s) provided by your developers (must match your app domain/routes)

      5. Save your changes

   2. Developer input required

      1. Your team must provide:

         • The exact Redirect URI(s) used by your frontend/backend sign-in callback routes

         • If applicable, the correct environment URLs (prod/staging/local)

5. Create a Client Secret

   1. In the left menu, go to Certificates & secrets

   2. Under Client secrets, click New client secret

   3. Enter:

      • Description

      • Expiration

   4. Click Add

   5. Copy the Value immediately (this is the Client Secret) — it will not be shown again after you leave the page

6. Save your credentials securely

   1. Store these values in your secrets manager or environment variables:

      • TENANT_ID = Directory (tenant) ID

      • CLIENT_ID = Application (client) ID

      • CLIENT_SECRET = Secret Value

      • REDIRECT_URI = the same redirect URI configured in Authentication

Best Practices

• Always enable 2FA for sensitive or enterprise environments.

• Configure an appropriate session timeout.

• Prefer SSO providers for corporate projects.

• Disable conventional login if only SSO is required.

• Periodically review authentication policies.