Authentication Flow

Authentication is one of the least consistent parts of the current platform. The recovered docs show a mix of shared SSO, app-managed sessions, and modules that still require auth hardening.

Current State

Module	Current documented state	Notes
M2	Authentik OIDC + Azure AD via NextAuth	Most clearly documented shared SSO flow
M1 / OBV	App-managed session flow	Backend route protection needs verification on some OBV routes
M3	Needs verification	Flags indicate auth is not fully implemented
M4	Module-specific flow, verify before changes	Current docs are not fully aligned across the technical pages
M7	Not implemented	Flags mark the service as publicly accessible without auth

Reference Flow: M2

M2 remains the clearest example of a production-style auth flow in this docs set.

sequenceDiagram
    participant User
    participant M2
    participant Authentik
    participant AzureAD as Azure AD
    participant NextAuth

    User->>M2: Open application
    M2->>NextAuth: Check session
    NextAuth-->>M2: No valid session
    M2->>Authentik: Redirect to OIDC login
    Authentik->>AzureAD: Federated sign-in
    AzureAD-->>Authentik: Identity assertion
    Authentik-->>NextAuth: OIDC callback
    NextAuth-->>M2: Session established
    M2-->>User: Authenticated app access

Engineering Implications

• Do not assume a single cross-platform auth provider when documenting or implementing changes.
• Check the module-specific docs before touching login, middleware, or protected routes.

Where To Verify Next

• Validate M1 / OBV route protection against the actual app and backend middleware.
• Confirm the final auth story for M4 from the reporting service source before editing its technical pages.
• Treat M3 and M7 as auth follow-up items until their access control is implemented and documented.