Keycloak Integration

We use Keycloak for authentication in April Robots (AR) and April Hub (AH). Keycloak has many features, but as of May 2026, only authentication is fully utilized by us.

The backends receive Keycloak identification token for user authentication. The backends then use information about the user from their local databases to authorize or block user requests. The frontends only save Keycloak tokens (in cookies).

Keycloak has client-side and server-side libraries to assist integration.

Currently, access to AR and AH works in the following way:

1. When users register via April Robots, they are created as “pending” users (unapproved) in the AR Database (DB). Pending users do not have any access. After an AR admin approves a pending user, the user will be activated and saved in the Keycloak DB. The user will now be able to access the AR app. When the user tries to log in AH for the first time, AH backend automatically creates an entry in its DB, so the user will seamlessly be able to access the AH app.
2. When users register via April Hub, they are created in both AH and Keycloak databases and can immediately access the AH app. However, the users will not be able to access the AR app or AR components in the AH app. To receive access, the user should manually register in AR (as of May 2026) and get approved.

The following diagram briefly describes authentication process for a user that has access to both apps:

    sequenceDiagram
    participant AHF as April Hub Frontend
    participant AHB as April Hub Backend
    participant K as Keycloak

    AHF->>K: unauthenticated user accesses a protected route
    K->>K: user logs in with credentials through Keycloak form
    K->>AHF: Keycloak redirects back with tokens
    AHF->>AHF: frontend saves the tokens
    AHF->>AHB: frontend uses the access token <br> to retrieve protected information
    AHB->>K: backend verifies the received token
    K->>AHB: approves
    AHB->>AHF: backend returns protected data

    participant ARB as April Robots Backend
    participant ARF as April Robots Frontend

    ARF->>K: unauthenticated user accesses a protected route
    K->>K: user logs in with the same credentials through Keycloak form
    K->>ARF: Keycloak redirects back with tokens
    ARF->>ARF: frontend saves the tokens
    ARF->>ARB: frontend uses the access token <br> to retrieve protected information
    ARB->>K: backend verifies the received token
    K->>ARB: approves
    ARB->>ARF: backend returns protected data