Request Flow

In this section, we will see how the JWT communicates between the systems. In this example, datapine is the service provider and needs to receive information from the external application about the user to authenticate him.




The external application has an intranet portal where the datapine application has been embedded. The objective is that logged in users in the external portal can access datapine without being prompted with an additional login form, leveraging therefore an SSO authentication.




The Customer is required to develop and expose an HTTP endpoint which will provide the JWT. The datapine application will redirect itself at load time to the above-mentioned endpoint, which has been previously configured by an administrator of the customer organization. The goal of this redirect is to obtain a valid JWT. The response of the endpoint is required to be a 302 redirect back to datapine, with the JWT passed as parameter of the request. Let’s see this flow in more detail:


Assuming that users are logged into your intranet portal and that a cookie or any other means of authentication for the domain Customer.comis therefore present in the user’s browser. When the user navigates to the datapine dashboards (can also be embedded in the portal via iFrame), datapine authenticates the user and displays the dashboards he has access to.


In order for this to happen, datapine must receive a valid JWT from your system which represents a user. After successful validation, datapine ensures that the token represents a valid user of your organization and performs the authentication. This entire process happens “under the covers” in the browser and the user accesses the dashboards.


This process is performed through a series of redirects to automatically retrieve and deliver the JWT transparently.


Chronologically, this is what happens:


  1. The user navigates to your intranet portal and logs in.
  2. The user navigates to the page where the datapine dashboards are embedded via iFrame.
  3. The iFrame loads and redirects itself to the authentication URL of your company.
  4. The authentication endpoint is hosted under your domain and therefore receives the authentication cookies of your intranet portal. The endpoint knows who is requesting an access token and can generate a suitable JWT.
  5. The endpoint response is another redirect to a URL passed in the previous request as a query string parameter called “ssoCallback”. The JWT, after being created with the user credentials and signed with the shared secret key, is appended to this new URL with a parameter called “token”.
  6. datapine receives this request, parses the JWT and determines whether it is valid or not. In case of validity, a final redirect is issued to display the app and the dashboards. A datapine authentication cookie is set.

Here the process described above translated into the following requests being sent: 


 datapine’s embedded iFrame source URL (#3):{organization_id}/iframe


Customer login URL (#4):


 iFrame redirect (#4):


Customer Redirect (#5){organization_id}?token={encoded_token}


Final redirect, fully authenticated (#6):{organization_id}/iframe