Skip to main content

Login a Header Based APP with Social Account

About 4 min

Login a Header Based APP with Social Account


In this tutorial, we will use the Datawiza Access Proxy (DAP) to enable SSO for a header-based Web App. We will use DAP's sidecar deployment mode, which means DAP and this app are running on the same server.

  • The application will run on localhost:3001.
  • The DAP will run on localhost:9772, which means the traffic to the app will reach DAP (running on port 9772) first and then be proxied to the application (running on port 3001).
  • We will provide the docker images for the DAP and this header-based application.

Demo APP

See our live demo appopen in new window which provides two ways to login: Google social account and Azure AD Accounts in any organizational directory (Any AD directory - Multitenant) and personal Microsoft account.

Quick Set Up

We use the Google social account as the set-up example.

Part I: Google Configuration

This session shows how to register a Credential on Google. When registering the Credential, we are getting the Client Id and the Client Secret that are needed for later configuration in Datawiza Cloud Management Console (DCMC):

1. Create a new OAuth consent screen: Select OAuth consent screen and select External, then Click CREATE: Google Create OAuth consent screen Supply the App name, User support email and Developer contact information and click SAVE AND CONTINUE. Google Create OAuth consent screen
Google Create OAuth consent screen
Add basic Scopes and click SAVE AND CONTINUE: Google Create OAuth consent screen Add Optional info if needed and click SAVE AND CONTINUE.
Google Create OAuth consent screen Check the Summary and click BACK TO DASHBOARD--an OAuth consent screens should be displayed: Google Create OAuth consent screen

Create and Configure your Google Credentials

2. Create a Credential:
Select Credentials tab and click CREATE CREDENTIALS, then select OAuth client ID:
Google Credential Config
Select Web application as Application type: Google Credential Config

3. Configure the Credential:
Add Authorized redirect URIs, e.g., http://localhost:9772/datawiza/authorization-code/callback, and click Create: Google Credential Config
Make sure you save the Client ID and Client Secret. We’ll need to enter these values in the DCMC when configuring our IdP. Google Credential Config

We have shown how to register a Credential on Google. Please make sure to save the Client Id and the Client Secret for later setting in Datawiza Cloud Management Console.

Part II: Datawiza Cloud Management Console (DCMC) Configuration

In this section, we will show you how to create an application on the Datawiza Cloud Management Console (DCMC) and generate a pair of PROVISIONING_KEY and PROVISIONING_SECRET for this app. This key pair is used by the Datawiza Access Proxy to get the latest configurations and policies from the DCMC.

Sign Into DCMC

  1. Log into the DCMCopen in new window.

Log Into DCMC

Create New Deployment In DCMC

Welcome to the DCMC homepage! Let's get started:

  1. Click the orange button Getting started. Specify a Name and a Description, and click Next.

New deploymentNew deployment

Add Application

Configure your application with the following values:

  • Platform: WEB
  • App Name: Demo App
  • Public Domain: http://localhost:9772
  • Listen Port: 9772
  • Upstream Servers: http://host.docker.internal:3001
  • Select Next.

Note that upstream sever is the address of the application that you want to enable SSO.

  • If you use the DAP in sidecar mode and your application is running on localhost:3001 on Mac or Windows, then set the upstream server to host.docker.internal:3001 (Docker 18.03+).
  • If your application is running on Linux, use ip addr show docker0 to get docker host IP (e.g., and then set upstream server to (see thisopen in new window for more details).

Create app in DCMC

IdP Configuration

  1. Select Google as the Identity Provider from the drop-down menu. Input the Client ID and the Client Secret gotten from the Google Cloud Platform. Choose Google IdP

Part III: Run DAP With a Header-Based Application

You can use either Docker or Kubernetes to run DAP. The following is an example docker-compose.yml file. You may need to login to our container registry to download the images of DAP and the header-based app. See Step3 : Configure DAP and SSO Integration for more details or Deploy DAP with Kubernetes for Kubernetes-specific instructions.

version: '3'

    container_name: datawiza-access-broker
    restart: always
      - "9772:9772"
      PROVISIONING_KEY: #############################
      PROVISIONING_SECRET: #############################

    container_name: ab-demo-header-app
    restart: always
      - "3001:3001"

After executing docker-compose -f docker-compose.yml up, the header-based app should have SSO enabled with Google. Open a browser and type in http://localhost:9772/. You should see the Google login page as follows. DAP with Google

Part IV: Pass User Attributes to the Header-Based App

The DAP gets user attributes from the IdP and can pass the user attributes to the application via header or cookie.

Please follow the instructions of Step4 : Pass User Attributes to pass the user attributes to the header-based app.

After successfully configuring the user attributes, you should see the green check sign for the first three user attributes as follows. Google with DCMC attributes

Part V: Achieve Granular Access Control

You can configure access control to an application based on the user's attributes (e.g., given name, family name) and other metadata of a request (e.g., URL, IP, HTTP method, access time).

Please reference Step5 : Achieve Granular Access Control for detailed instructions on how to set up access rules.

A Rule Example

  1. Create the following two rules: Because Google social account doesn't have group or role, we use the first name here as example:
  • hr path can only be accessed by the user whose first name is West.
  • sales path can only be accessed by the user whose first name is John.
  1. Verify that the user can only access hr page in the header-based app, but cannot access sales page. Trying to access the header-based application on localhost:9772 in your browser, you should get something similar to the following screenshots. http://localhost:9772/hr: Google Examplehttp://localhost:9772/sales: Google Example Access Forbidden