Supabase auth replaced end-to-end with Cognito User Pool, Identity Pool, and Amplify

The sequence matters. An initial AuthStack adds a Lambda Token authorizer that validates Supabase JWTs against the JWKS endpoint (0ae592f). This gets replaced within the same feature branch by a native API Gateway Cognito User Pools authorizer (810abde), eliminating the Lambda cold-start on every request. The old authorizer Lambda is deleted in d6dbb5e.

On the frontend, Amplify Auth lands as a thin wrapper module (dfd69c1), then AuthContext and AwsContext are rewritten to call fetchAuthSession and getIdToken() instead of supabase.auth.getSession() - that call-site replacement happens across eight files in 358951f. The signup page picks up email verification and a TOTP MFA setup flow (99aa05a).

Two architectural decisions are worth calling out. First, the pre-token-generation Lambda injects role: "authenticated" into id tokens to satisfy Supabase RLS - but Supabase RLS is later removed when Aurora replaces Supabase Postgres, so the Lambda becomes dead weight and is removed in 5e6962d. Don't import it unless you're keeping Supabase on the database side. Second, user deletion: the pattern in 2847ef2 cascades all user data synchronously inside DELETE /user/account before calling AdminDeleteUser, which is the right shape for any compliance-driven delete requirement.

The AgentCore token bug (95d538d) is concrete: AgentCore's JWT authorizer validates the client_id claim, which is present in the Cognito access token but absent from the id token. The fork initially sent the id token, got failures, and fixed it to send the access token instead. The allowedAudience field in the AgentCore authorizer config also needed removing (ecc808c). If you integrate Cognito + AgentCore, read those two commits before wiring anything.

TOTP MFA goes through two reversals: disabled (943914b) then re-enabled as optional (7d621a0). The final state is optional TOTP.