feat(auth): FAM/Cognito SPA sign-in via Amplify (Story 1.2)

[gpascucci]

Story 1.2 — Sign in with FAM/Cognito (frontend)

Adds the real Amplify (Cognito OIDC) auth provider beside the mock, behind a single AuthProvider seam. Co-deploys with Story 1.1 (#290) to flip ilcr.security.enabled on.

What's here

• Auth seam — Real (Amplify v6) vs Mock chosen by a runtime double-gate (window.amplifyConfig.mockUser === true && isLocalHost); deployed builds are never mock. Unified useAuth context keeps user/hasRole and adds isAuthenticated/isLoading/signIn/signOut.
• Sign-in — Hosted UI (signInWithRedirect, auth-code + PKCE, openid); fetchAuthSession → ID token; identity/roles from GET /api/v1/me (backend is source of truth).
• Token attach — ID-token Bearer on every APIService request; a 401 forces one refresh and retries, bouncing to sign-in only if the refresh token is gone (no mid-form data loss). Mock mode keeps X-Mock-Groups.
• Deep-link preserved via customState; sign-out runs the OAuth logout chain (ends the upstream session).
• Mock role-selector renders only under the mock provider (absent from real builds); a test asserts it does not render under the real provider.
• Runtime config via window.amplifyConfig (same image every env; ConfigMap overrides per env; no secrets committed).

Domain note

Removed the combined admin/submitter mock user — a user holds exactly one ILCR role (ILCR_ADMIN or ILCR_SUBMITTER).

⚠️ Deploy prerequisite (before the 1.1+1.2 flip)

The frontend OpenShift ConfigMap must supply the real Cognito pool/client/domain/redirects with mockUser:false — analogous to the backend COGNITO_CLIENT_ID. Until then real aud validation and sign-in aren't active in a deployed env.

Test plan

• New: env, amplify-initializer, AuthProvider, RealAuthProvider, MockUserSelector, api-service.auth tests (19 tests) covering authed/unauthenticated-bounce/refresh/logout/deep-link/mock-selector-absent-under-real.
• Full unit suite 782/782; changed-file coverage 86.5%; lint clean.
• Adds aws-amplify@^6 (1 transitive npm audit high — follow-up).

🤖 Generated with Claude Code

---

Thanks for the PR!

Deployments, as required, will be available below:

• Frontend
• Backend

Please create PRs in draft mode. Mark as ready to enable:

• Analysis Workflow

After merge, new images are deployed in:

• Merge Workflow

[Rylan-cgi]

The PR is excellent overall, but two infinite redirect loops must be fixed before
merging:

---

1. Infinite Redirect Loop on /v1/me Gateway/Network Failures

• Where: frontend/src/context/auth/RealAuthProvider.tsx (loadUser())
• Problem: If Cognito has a valid session but /v1/me fails temporarily (500 error,
  gateway timeout, or network disconnect), the broad catch block sets user = null.
  This immediately triggers the mounting useEffect to call signIn(), redirecting to
  Cognito Hosted UI. Because the user's Cognito session cookie is valid, Cognito
  instantly redirects back to the app, which hits /v1/me again, fails, and
  redirects again—looping infinitely.
• Fix: Check axios.isAxiosError(error). If it is a 5xx or network error, set a
  local connection error state and show a fallback screen instead of redirecting.

---

2. Infinite Redirect Loop on 403 Forbidden / Unauthorized Users

• Where: frontend/src/context/auth/RealAuthProvider.tsx (loadUser())
• Problem: If a user logs into Cognito/FAM but is not mapped to any valid
  groups/roles in the directory, /v1/me rejects with 403 Forbidden (or returns
  empty roles). Setting user = null causes the app to treat them as unauthenticated
  and redirect back to Cognito. Cognito sees they are logged in and redirects back
  immediately, creating another infinite loop.
• Fix: Catch the 403 (or check for roles.length === 0), set an unauthorized error
  state, and render an "Access Denied" page with a Sign Out button instead of
  redirecting.

---

Suggested Fix for RealAuthProvider.tsx
Replace the state initialization, loadUser function, redirect useEffect, and return
block in RealAuthProvider.tsx with this pattern:

  1   const [user, setUser] = useState<AuthUser | null>(null)
   2   const [isLoading, setIsLoading] = useState(true)
   3   const [error, setError] = useState<{ status?: number; message: string } |
     null>(null)
   4   const redirectingRef = useRef(false)
   5
   6   const loadUser = useCallback(async () => {
   7     setIsLoading(true)
   8     setError(null)
   9     try {
  10       const session = await fetchAuthSession()
  11       if (!session.tokens?.idToken) {
  12         setUser(null)
  13         return
  14       }
  15       const { data } = await
     apiService.getAxiosInstance().get<AuthUser>('/v1/me')
  16
  17       if (!data.roles || data.roles.length === 0) {
  18         setError({ status: 403, message: 'Access Denied: You do not have
     permissions mapped to this application.' })
  19         setUser(null)
  20         return
  21       }
  22       setUser(data)
  23     } catch (err: unknown) {
  24       if (axios.isAxiosError(err)) {
  25         const status = err.response?.status
  26         if (status === 401) {
  27           setUser(null) // Token expired: trigger login bounce
  28         } else if (status === 403) {
  29           setError({ status: 403, message: 'Access Denied: You do not have
     permission to access this application.' })
  30           setUser(null)
  31         } else {
  32           setError({ status, message: 'The server is temporarily unavailable.
     Please try again later.' })
  33           setUser(null)
  34         }
  35       } else {
  36         setUser(null)
  37       }
  38     } finally {
  39       setIsLoading(false)
  40     }
  41   }, [])
  42
  43   useEffect(() => {
  44     // Only bounce if unauthenticated AND no error is present
  45     if (!isLoading && !user && !error && !isOAuthCallback() &&
     !redirectingRef.current) {
  46       redirectingRef.current = true
  47       void signIn()
  48     }
  49   }, [isLoading, user, error, signIn])
  50
  51   // Render error screen to break the redirect loop
  52   if (error) {
  53     return (
  54       <div style={{ padding: '2rem', textAlign: 'center' }}>
  55         <h2>{error.status === 403 ? 'Access Denied' : 'Connection Error'}</h2>
  56         <p>{error.message}</p>
  57         <button onClick={error.status === 403 ? () => void doSignOut() : () =>
     void loadUser()}>
  58           {error.status === 403 ? 'Sign Out' : 'Retry'}
  59         </button>
  60       </div>
  61     )
  62   }

[gpascucci]

Thanks @Rylan-cgi — both redirect loops are fixed in d900036.

loadUser() now classifies the failure instead of blindly nulling the user (which the redirect effect was reading as "unauthenticated" and bouncing on a still-valid Cognito session → loop):

• 401 — leave error null so the effect re-authenticates (token genuinely expired/rejected).
• 403 — render an "Access denied" screen with a Sign out button. No redirect.
• 5xx / network / fetchAuthSession failure — render a "Connection error" screen with a Retry button. No redirect.

The redirect effect now guards on !error, so only a genuinely unauthenticated visitor is sent to the Hosted UI.

On the roles.length === 0 → error suggestion: I kept roles:[] as a non-null user rather than an error. A valid FAM token with no ILCR group isn't a failure — it's the O8 no-access case, and Story 1.3 renders a dedicated "no ILCR access — contact an administrator" screen for it (AC4). Treating it as an error here would duplicate that and fight the 1.3 RouteGuard/NoAccess design. Since the user stays non-null, there's no null→bounce loop either.

Tests added/updated in RealAuthProvider.test.tsx: session-lookup failure → connection error (asserts no signInWithRedirect); /me 500 → connection error + Retry re-attempts and authenticates; /me 403 → access-denied + Sign out. Full suite green (794 passing) and lint clean. Also merged forward into the 1.3 branch (#301).

[Rylan-cgi]

Issues fixed. Looks good!

[paulushcgcj]

The auth flow now covers both local mock and Cognito paths, including token attachment, one-time refresh handling, deep-link restoration, and a recovery screen for /me failures. The focused tests and production build pass, and the retry guard is a particularly useful protection against recursive 401 handling. I found two runtime/deployment edge cases inline.

[paulushcgcj]

The one-retry boundary is a strong improvement. Marking the original request before retrying prevents a persistent 401 from recursively re-entering the refresh flow, while still giving a valid refreshed session one chance to complete the request.

[gpascucci]

Thanks @paulushcgcj — both edge cases are fixed in 6d0bfc4.

1. Redirect config guarded up front (amplify-initializer.ts). configureAmplify() now includes redirectSignIn and redirectSignOut in the fail-loud guard alongside pool/client/domain, and no longer coerces them through String(...). A ConfigMap that omits either now throws a named error at startup (… missing one of: … redirectSignIn / redirectSignOut) instead of letting the literal "undefined" reach Amplify and only failing mid-flow at the Hosted UI. Added a missing-value test for each.

2. Transient refresh no longer discards the route (api-service.ts). You're right that the old catch bounced on every fetchAuthSession({forceRefresh:true}) rejection. Now, on a forced-refresh error I check hasUsableSession() (a plain non-forced fetchAuthSession): if a session still remains — including a cached-but-expired id token — I preserve the route and reject the 401 to the caller rather than redirecting. I only bounce to the Hosted UI when Amplify confirms no usable session remains (the refresh path returns no token, or the non-forced lookup also comes back empty). This matches the intended only-bounce-when-the-refresh-token-is-gone behavior.

Tests added: transient forced-refresh failure with a live session → no signInWithRedirect; forced-refresh failure with no session → bounces (plus the existing forceRefresh-returns-no-token → bounce case). Full frontend suite 798 passing, lint clean. Also merged forward into the 1.3 branch (#301).