Investigate session share between multiple frontend apps

pbastia commented 3 months ago

Description:

There would be multiple ways of doing that. The team has used a postgres table in the past - that has the advantage of being able to implement RLS easily Are there any other options?

Acceptance Criteria:

Given When Then

Development Checklist:

[ ] Checklist item
[ ] Checklist item
[ ] Checklist item
[ ] Meets the DOD

Definition of Ready (Note: If any of these points are not applicable, mark N/A)

[ ] User story is included
[ ] User role and type are identified
[ ] Acceptance criteria are included
[ ] Wireframes are included (if required)
[ ] Design / Solution is accepted by Product Owner
[ ] Dependencies are identified (technical, business, regulatory/policy)
[ ] Story has been estimated (under 13 pts)

·Definition of Done (Note: If any of these points are not applicable, mark N/A)

[ ] Acceptance criteria are tested by the CI pipeline
[ ] UI meets accessibility requirements
[ ] Configuration changes are documented, documentation and designs are updated
[ ] Passes code peer-review
[ ] Passes QA of Acceptance Criteria with verification in Dev and Test
[ ] Ticket is ready to be merged to main branch
[ ] Can be demoed in Sprint Review
[ ] Bugs or future work cards are identified and created
[ ] Reviewed and approved by Product Owner

Notes:

Potential session share solutions:

Database session, shared by the multiple frontend services
- we could RLS on our database tables "last line of defense"
- we're familiar with that pattern
- would need to inject raw SQL which can confuse Django
API Gateway with reverse proxy to pods
- KongAPI? (bcgov has some teams that are using this tool - community support)
- Could we share the session through the gateway?
- Implement some basic Rule-Based Access Control in the gateway -> offload some basics that we may be implementing in several places in our various APIs to a single source
- KONG OPA plugin?

Leaning towards API Gateway to handle the session sharing. Could also add a DB session & RLS independently.

Dependencies

Blocked by
Blocking

hannavovk commented 3 months ago

Dedicated meeting needed - @pbastia @shon-button @dleard @joshgamache

Sepehr-Sobhani commented 3 months ago

Sharing my thoughts:

Login and Token Exchange:

User logs in with Keycloak.
Front-end receives access token and sends it to the backend API in a secure request.

Backend Validation and Session Creation:

Backend validates the access token with Keycloak's OpenID endpoint.
If valid, user is identified and a Django session is created containing user data.
A unique session identifier is generated.

Session Exchange and Access Control:

Backend sends the session identifier (e.g., cookie) to the front-end.
Front-end securely stores the session identifier.
Subsequent requests from the front-end include the session identifier.
Backend uses the session identifier to retrieve user data and grant access based on permissions.

shon-button commented 2 months ago

This spike is to explore upgrading authentication to auth.js v5, and to explore sharing JWT session state across microfrontends using Next.js Multi-zones feature.

Background

auth.js v5
Auth.js provides JWT-based user session strategy using JSON Web Tokens (JWT). When a user signs in, a JWT is created in a HttpOnly cookie. Making the cookie HttpOnly prevents JavaScript from accessing it client-side (via document.cookie, for example), which makes it harder for attackers to steal the value. In addition, the JWT is encrypted with a secret key only known to the server. So, even if an attacker were to steal the JWT from the cookie, they could not decrypt it. Combined with a short expiration time, this makes JWTs a secure way to create sessions. When a user signs out, Auth.js deletes the JWT from the cookies, destroying the session. This JWT session strategy allows logging in once, for the time the JWT is valid, so users do not have to log in every single time they visit the site.

Next.js multi zones A zone refers to a single Next.js app running on a server. Multiple Next.js apps can be combined together using the multi-zones feature so to appear as a unified application. For example, let’s say we have a Next.js application that consists of three different micro-frontends: a home app, a registration app, and a reporting app. You could define each of the separate micro-frontend app as a separate “zone”, and then, through configurations of .env, next.config.js, package.json, the user can navigate the apps as if it was a single, monolithic application allowing sharing of the authentication session between apps deployed on separate subdomains.

auth.js v5