Authentication - lesson 7 | HackIndia Skills

Key point

Proof beats claims

Your repo should show working auth, not just say it has auth. A recruiter or judge should be able to clone it, add env values, run it, sign in, and see protected routes behave correctly.

Your to-do

Make it runnable

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Commit the app code, lockfile, and clear setup instructions.
Keep secrets out of git and show required env names in a sample file.
Add seed or demo account steps if your app needs test data.
Mention the exact Node, Python, or framework version if setup can break.
Test the clone flow in a fresh folder before submitting.

0 of 5 done

Example

Add env example

Create a sample env file with names only. Never paste real OAuth client secrets, JWT secrets, database passwords, or production URLs with credentials.

# .env.example
DATABASE_URL="your_database_url_here"
SESSION_SECRET="use_a_long_random_secret_here"
GOOGLE_CLIENT_ID="your_google_client_id_here"
GOOGLE_CLIENT_SECRET="your_google_client_secret_here"
NEXTAUTH_URL="http://localhost:3000"

Your to-do

Write the README

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Explain what sign-in methods work, such as email password or Google OAuth.
List which routes are public and which routes are protected.
State where auth checks happen, such as middleware, server routes, or API handlers.
Describe cookie or token handling in plain words.
Add a short security checklist and say what you tested.

0 of 5 done

Example

README auth section

Use direct language. The goal is to help someone inspect your choices fast.

## Auth overview

Sign-in methods:
- Email and password
- Google OAuth

Protected routes:
- /dashboard requires a signed-in user
- /api/notes requires a signed-in user
- /login is public

Security choices:
- Passwords are hashed with bcrypt before storage
- Session is stored in an httpOnly cookie
- Cookie uses secure in production and sameSite=lax
- Server checks the session before returning private data
- Secrets are loaded from environment variables

How to test:
1. Run the app locally
2. Visit /dashboard while signed out. You should be redirected to /login
3. Sign in with a test account
4. Visit /dashboard again. You should see private content
5. Sign out and confirm /dashboard is blocked again

Common mistake

Do not hide gaps

Do not write “secure auth added” if your API routes still return private data without checking the user. Reviewers often test APIs directly, not only pages.

Also avoid committing screenshots that show real user emails, tokens, cookies, or OAuth secrets. Use a demo account and fake data.

Tip

Use AI carefully

Ask ChatGPT, Gemini, or Claude to review your README and test plan. Paste only non-secret code or file snippets.

Check what it returns. It may suggest fake package flags, wrong cookie names, or security claims your app does not actually implement.

Prompt:
Review this README auth section for clarity and missing security checks.
Do not add features I have not implemented.
Point out any claims that need proof in code.

Your to-do

Do this now

Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

Add .env.example with placeholder values only.
Write the README auth overview, protected routes, and test steps.
Run your app from a fresh clone or fresh folder.
Test signed-out, signed-in, and signed-out-again flows.
Submit the public repo link with screenshots or a short demo note.

0 of 5 done

Ship an auth-ready repo

Proof beats claims

Make it runnable

Add env example

Write the README

README auth section

Do not hide gaps

Use AI carefully

Do this now

Quick check