The following diagram shows the JSON Web Token workflow in Fluid Topics:
flowchart LR
User([User])
FT([Fluid Topics])
ClientApp([Client application])
AuthProvider([Authentication provider])
User -- "1: Requests access" --> FT
FT -- "2: Redirects user" --> ClientApp
ClientApp -- "3: Requests JWT (user authenticates)" --> AuthProvider
AuthProvider -- "4: Returns JWT" --> ClientApp
ClientApp -- "5: Authenticates with JWT" --> FT
FT -- "6: Returns FT_SESSION cookie" --> ClientApp
ClientApp -- "7: Redirects user<br>User is logged in" --> User
%% Custom colors for participant nodes
style User fill:#d0e6fa,stroke:#0e639c,stroke-width:2px
style FT fill:#fbe6cf,stroke:#ad7000,stroke-width:2px
style ClientApp fill:#d2fae6,stroke:#207868,stroke-width:2px
style AuthProvider fill:#f7d8e6,stroke:#bc1855,stroke-width:2px
- User requests access to Fluid Topics.
- Fluid Topics redirects the user to the client application.
- User authenticates with the client application, which requests a JWT from the authentication provider.
- Authentication provider returns a JWT to the client application.
-
Client application authenticates with Fluid Topics using the JWT.
Fluid Topics then checks who the issuer of the JWT is. If the issuer exists in the realm configuration, Fluid Topics calls the associated JSON Web Key Sets (JWKS) URL to get a verification public key. If the token signature is not verified by the public key, Fluid Topics rejects it.
-
Fluid Topics returns an
FT_SESSIONcookie to the client application. - Client application redirects the user to Fluid Topics, and the user is logged in thanks to the cookie.
- It is necessary to add the client application domain to the trusted origins of the Fluid Topics portal.
- The client application security and CORS policy must allow HTTP requests to the Fluid Topics domain.