Hands-On Reasoning Lab & Phase Exit Prove that the authentication model is understood before Supabase Auth implementation
Phase 16 - Authentication Fundamentals Volume 05 - Authentication & Security
v
v
v
v
Phase 16 builds the security mental model before any Supabase Auth integration code is introduced.
Hands-on reasoning lab Phase 16 is intentionally concept-heavy. The lab tests whether you can reason about authentication architecture before a provider SDK hides the mechanics.
Lab A - Classify the concept Scenario Concept
User types email Identification / claimed identity
NestJS verifies access token Authentication evidence verification
Task cannot transition directly DONE -> TODO Business rule, not auth
Lab B - Find the security mistake • Frontend sends userId in POST /tasks and service trusts it as owner.
• JWT payload is base64-decoded and sub is trusted without signature verification.
• Refresh token is placed in a URL query parameter.
• Authorization header is written to request logs.
• JWT is stored in localStorage without discussing XSS risk.
• Cookie auth is enabled with SameSite=None but CSRF is never considered.
• CORS allowlist is treated as proof that the request is authenticated.
• Logout only hides the dashboard but leaves a valid provider session alive.
Lab C - Draw the future TaskFlow flow On paper, draw: User -> Supabase Auth -> session/access token -> Next.js -> Authorization header -> NestJS guard -> trusted subject -> TasksService -> membership/ownership check -> Prisma. Label every point where trust changes.
Exercise levels Level Challenge
1 - Follow Explain AuthN vs AuthZ, access vs refresh token, and HttpOnly vs JavaScript-readable storage.
2 - Modify Design a logout lifecycle for a shared-office computer where the user expects sign-out to terminate future token refresh.
3 - Implement (design) Write pseudocode for a NestJS guard that returns 401 for missing, expired, wrong-issuer, or invalid-signature tokens without implementing cryptography yourself.
4 - Engineer Threat-model authentication for an HRIS payroll approval screen. Identify authenticator strength, session storage, re-authentication, authorization, audit logging, token exposure, logout/revocation, and recovery risks.
Architecture oral exam • Why does a browser-supplied userId not prove identity?
• Why is decoding a JWT different from verifying it?
• What does aud protect against?
• Why should access tokens usually be short-lived?
• Why is a refresh token more sensitive than an access token?
• Why can HttpOnly cookies reduce token theft but still require CSRF thinking?
• Why is CORS not an authentication mechanism?
• What is the difference between 401 and 403 in TaskFlow reasoning?
• What should never appear in authentication logs?
• What responsibility will Supabase Auth own versus NestJS?
Phase exit checklist • You can explain identity, authenticator, authentication, session, token, and authorization separately.
• You understand why TaskFlow will not implement password hashing itself.
• You can explain cookie attributes Secure, HttpOnly, and SameSite.
• You can explain why localStorage/sessionStorage token use creates XSS exposure.
• You can identify JWT iss, sub, aud, exp, nbf, iat, and jti.
• You know that decoding a JWT does not verify it.
• You understand access vs refresh tokens and refresh rotation conceptually.
• You understand XSS, CSRF, CORS, and HTTPS as different concerns.
• You can draw the planned Supabase Auth -> Next.js -> NestJS guard flow.
• You are ready to integrate Supabase Auth without treating it as magic.
v
v
v
v
v
v
Phase 16 ends when the learner can explain every arrow before writing provider-specific code.
Authentication answers who the request represents. Treating decoded or client-supplied identity as trusted is a security boundary failure.
Restate the goal of “Hands On Reasoning Lab and Phase Exit” as one observable behavior. Write the success signal before touching code.
Trace the boundary map: credentials/session → token → verification → trusted identity → protected operation. Mark the one boundary this lesson changes.
Inspect the current repository state and record the exact files, route, table, or runtime involved. Avoid creating an abstraction before you can name the existing owner.
Implement the smallest vertical slice. Add one coherent change, run the narrowest verification command, and read the output before continuing.
Connect the slice to TaskFlow’s phase artifact: Authentication threat/flow diagram explaining what the browser stores, what servers verify, and what happens when credentials expire.. Verify behavior from the outside as a user or API client would.
Create one controlled failure that is safe to reproduce. Predict the symptom first, capture evidence, locate the earliest broken boundary, then fix only that cause.
Close the reference and rebuild or explain the core change from memory. Record what you would monitor or test before trusting the same change in production.
const token = readBearerToken(request);
const claims = await verifier.verify(token);
request.user = {
id: claims.sub,
email: claims.email,
};Do not copy this as a finished answer. Predict what each boundary does, type the smallest useful slice, run it, then compare the result with your prediction.
Inspect whether a token exists, whether it is expired, which issuer/audience signed it, and what the API verifier expects.
Trust only verified server claims; never repair identity by accepting a client-sent user id.
Without copying the final source, create a second small scenario that applies “Hands On Reasoning Lab and Phase Exit” to a different TaskFlow resource or input. Write the acceptance criteria first, implement it, and provide the evidence that each criterion is satisfied.
Separate authentication (who) from authorization (may do what) with concrete TaskFlow examples.
Use the smallest change that demonstrates this lesson. Stop after it works and capture evidence.Confusing hidden UI with authorization
Predict the symptom before causing the failure. Then locate the earliest boundary where reality diverges from expectation.Why does this responsibility live here, what input does it trust, what output proves success, and what would go wrong if another layer owned it?
If your explanation is vague, repeat the boundary trace before moving on.Close the reference. Reproduce the core idea from memory or explain the exact request/data flow aloud. Then check your diff or notes for accidental shortcuts that bypass validation, authorization, error handling, or verification earned in earlier phases.