Authentication at Statista

In a monolithic application the user is typically authenticated by a session cookie that is set after the user logs in. In a microservice architecture like Statista 4.0, authentication is more complex. In this section we go through the architecture and flow of authentication for Statista 4.0 applications.

We try to centralize authentication as much as possible at our partner Auth0.

The main components involved in the authentication flow are:

1. A cookie that's shared across all Statista 4.0 applications to identify the user session.
2. An access token (JWT) that is stored in that cookie

The difference between the access token and a session cookie is the following:

• A session cookie is typically a random string that identifies a user session on the server
• An access token (JWT) is a signed token that contains user information (like permissions) and can be verified without server-side storage.

How do issue the access token?

We have a central app called Remix-SSO that is in charge of aqcuiring the access token from Auth0 and writing it to the shared cookie.

To get the access token we use OpenID Connect (OIDC) Authorization Code Flow with Auth0.

The flow is made up of two main steps:

1. The user's browser is redirected to Auth0 to log in and comes back to Remix-SSO with an authorization code.
2. Remix-SSO server exchanges the authorization code for an access token and writes it to the shared cookie.

How do we we authenticate users without username/password?

We have a lot of user that belong to an organization and don't have their own username/password.

These institutions have their own identity provider (IdP) that manages their users. So before Auth0 can create an access token for these users, it has to authenticate them against their IdP.

One option is to another round of OIDC. So we (Remix-SSO) want an access token from Auth0, but Auth0 needs to get an access token from the institution's IdP first. So we get this nested OIDC flow:

1. The user's browser is redirected to Auth0 to log in
2. Auth0 redirects the user's browser to the institution's IdP to log in
3. The user's browser is redirected back to Auth0 with an authorization code
4. Auth0 server exchanges the authorization code for an access token from the
5. The user's browser is redirected back to Remix-SSO with an authorization code.
6. Remix-SSO server exchanges the authorization code for an access token and writes it to the shared cookie.

Next to OIDC we also support SAML as authentication method for institutions that don't support OIDC. And we even have a handful of institutions that use custom authentication methods that we have implemented directly in Auth0.

Main takeaways

• OIDC is a widely used standard for authentication
• We use OIDC Authorization Code Flow to get access tokens from Auth0
• Institutions can use their own IdP to authenticate users
• Statista 4.0 applications use access tokens (JWT) stored in a shared cookie for authentication

Authentication Infrastructure Overview

This document provides an overview of our authentication architecture, detailing how user authentication flows through the system. The main components involved are:

Remix-SSO library (TS): Statista 4 apps can use this JS library/package to authenticate Statista users.

Frontend (PHP/TS/JS): Initiates authentication by redirecting users to Remix-SSO.

Remix-SSO service (TS): Validates the request and interacts with Auth0.

Auth0 (JS/Identity Provider): Manages authentication, user identity, and token issuance.

Platform-SSO (TS/JS): Validates user information and pulls data from Users DB.

Users DB (MySQL): Stores user data and credentials.

Authentication Flow

1. A user starts a log in request by one of the Authentication Methods.
2. The Frontend redirects them to Remix-SSO.
3. Remix-SSO redirects the browser to Auth0 for authentication.
4. Auth0 communicates with some services in Platform-SSO-Services depending on the Authentication Method used.
5. Upon success, Auth0 redirects back to Remix-SSO with an authorization code.
6. Remix-SSO exchanges the code for an ID token and access token with Auth0.
7. Remix-SSO redirects to the provided callback url with the tokens.

graph TB
    User["User/Browser"]

    subgraph Frontend["Frontend"]
        direction LR
        Monolith["Monolith<br/><br/><br/><br/><br/>"]
        App1["Statista 4.0 App"]
        App2["Statista 4.0 App"]
    end

    subgraph RemixSSO["remix-sso"]
        direction LR
        Server["remix-sso server<br/>(/sso/...)"]
        Library["remix-sso<br/>library"]
    end

    PSS["platform-sso-services"]
    Users[("Users<br/>DB")]
    Auth0["auth0"]

    %% Connections
    Library --> App1
    Library --> App2
    User -->|1. Login request| Frontend
    Frontend -->|2. Redirect| Server
    Server -->|3. Redirect| Auth0
    Auth0 <-->|4. Validate| PSS
    PSS -->|Pull data| Users
    Auth0 -->|5. Auth code| Server
    Server <-->|6. Token exchange| Auth0
    Server -->|7. Callback with tokens| Frontend
    Frontend -->|Authenticated| User