The Bouncer Analogy
At a club:
- Bouncer asks: "Who are you?"
- You show ID
- Bouncer checks: Is this really you?
- Match? You're in.
Authentication is the digital bouncer. Before you get access, systems verify you are who you claim to be.
What Is Authentication?
Authentication = Proof of identity
Question: "Who are you?"
Answer: Something that PROVES it's really you.
Not authenticated?
→ Access denied
→ Can't see private data
→ Can't perform actions
Authentication vs Authorization
| Aspect | Authentication | Authorization |
|---|---|---|
| Question | Who are you? | What can you do? |
| Order | First | After authentication |
| Example | Logging in | Admin vs regular user |
| HTTP Error | 401 Unauthorized | 403 Forbidden |
Order matters:
1. Authenticate: Prove identity
2. Authorize: Check permissions
You can't authorize an unknown user!
The Three Factors
Authentication can use different "factors":
Something You Know
Password, PIN, security questions
Pros: Simple, no hardware needed
Cons: Can be guessed, phished, stolen
Something You Have
Phone (SMS, authenticator app)
Hardware security key
Smart card
Pros: Harder to steal remotely
Cons: Can lose device
Something You Are
Fingerprint, face, voice, retina
Pros: Can't forget, hard to fake
Cons: Privacy concerns, can't change
Multi-Factor Authentication (MFA)
Combining Factors
Single Factor:
Password (no second factor) → If stolen, the account is typically at higher risk
Multi-Factor:
Password (know) + Phone code (have)
→ Attacker needs BOTH to get in
Much harder to compromise!
Why MFA Works
Attacker steals your password: Gets in? NO
Attacker steals your phone: Gets in? NO
Attacker has both: Gets in? YES
Having one isn't enough anymore.
Common Authentication Methods
Username + Password
Most common, oldest method.
User: alice@example.com
Password: ********
Server checks: Does hash match stored hash?
Match? Authenticated!
Security depends on password strength.
OAuth / Third-Party Sign-In
"Continue with Google"
"Continue with GitHub"
You prove identity to Google.
Google tells the app: "This is Alice"
Note: In practice, third-party sign-in usually uses OpenID Connect (OIDC) on top of OAuth.
The app typically doesn't see your password.
Magic Links
Enter email → Link sent to inbox → Click to login
No password to remember.
Email inbox is the authentication.
Passkeys / WebAuthn
Modern, passwordless authentication.
Device creates public/private key pair.
Login uses biometrics to unlock private key.
Server verifies without seeing password.
The future of authentication!
Biometrics
Fingerprint, Face ID, voice recognition
Your body is the password.
Convenient but privacy considerations.
Sessions and Tokens
After Authentication
User authenticates successfully.
Server needs to remember them.
Two approaches:
1. Sessions (server-side)
2. Tokens (client-side)
Sessions
Server stores: "Session ABC = Alice"
Client gets: Cookie with "session=ABC"
Each request: Cookie sent → Server looks up session
Tokens (JWT)
Server creates: Token containing user info + signature
Client stores: Token in cookie or storage
Each request: Token sent → Server validates signature
No server-side storage needed!
Single Sign-On (SSO)
One login, many applications.
Login to Google once:
→ Access Gmail
→ Access Drive
→ Access Calendar
No separate logins for each!
Common in enterprise:
Login to corporate identity provider
→ Access Slack, Jira, Confluence, etc.
Password Security
Practical Tips
âś“ Long passwords (16+ characters)
âś“ Unique for each site
âś“ Use a password manager
âś“ Enable MFA wherever possible
What NOT to Do
âś— Same password everywhere
âś— Dictionary words
âś— Personal information (birthday, pet name)
âś— Writing passwords on sticky notes
For Developers
âś“ Hash passwords (bcrypt, Argon2)
âś“ Use salt
âś“ Avoid storing plain text passwords
âś“ Implement rate limiting
âś“ Consider offering MFA
Common Mistakes
1. Weak Password Policies
"Password123!" follows the rules but is predictable.
Encourage length over complexity.
2. Not Offering MFA
Using just a password can create a single point of failure.
Offer (and encourage) MFA when it fits your user base and threat model.
3. Poor Session Management
Very long-lived sessions are often risky.
Invalidate on logout, set reasonable timeouts.
FAQ
Q: Password vs passwordless?
Passwordless (magic links, passkeys) can reduce some risks (like password reuse and some phishing flows) and can be more convenient. It still needs solid recovery and device/account protection.
Q: Is SMS 2FA a good option?
Better than nothing, but vulnerable to SIM swap attacks. Authenticator apps are better.
Q: What if I forget my password?
Reset flows exist, but they're attack targets. A robust reset flow verifies identity another way.
Q: How long should sessions last?
Depends on sensitivity. Banking: short. Social media: longer. Provide logout.
Summary
Authentication verifies identity before granting access, answering "Who are you?"
Key Takeaways:
- Three factors: know, have, are
- MFA combines factors for security
- Different methods: passwords, OAuth, passkeys
- Sessions/tokens track authenticated users
- Hash passwords, and offer MFA where possible
- Authentication comes before authorization
Authentication is the front door to systems that need identity checks.
Related Concepts
Leave a Comment
Comments (0)
Be the first to comment on this concept.
Comments are approved automatically.