Authentication and Authorization for Backend Engineers

 

Authentication and Authorization for Backend Engineers

Authentication and authorization are two of the most fundamental concepts in backend engineering. Almost every modern application needs to answer two questions:

  1. Who are you? — Authentication
  2. What are you allowed to do? — Authorization

Authentication establishes the identity of a user or system, while authorization determines what that identity is permitted to access or perform.

Understanding the difference between these concepts—and knowing how sessions, cookies, JWTs, API keys, OAuth 2.0, and role-based access control fit together—is essential for backend engineers.

1. Authentication vs. Authorization

Although authentication and authorization are often mentioned together, they solve different problems.

Authentication: Who are you?

Authentication is the process of establishing the identity of a subject.

For example, when you log in to an application using:

  • Email and password
  • Username and password
  • OTP
  • Fingerprint
  • Face recognition
  • Passkey

the application is trying to determine who you are.

Authorization: What can you do?

Once the application knows who you are, it needs to determine what you are allowed to do.

For example:

  • A normal user can read an article.
  • An editor can create and modify an article.
  • An administrator can delete an article.
  • A moderator may be allowed to manage comments.

So the simple distinction is:

Authentication answers “Who are you?”
Authorization answers “What can you do?”

2. A Brief History of Authentication

Authentication did not begin with passwords or computers. The underlying idea has existed for centuries.

The Era of Human Trust

In small pre-industrial communities, identity was often established through personal recognition.

A respected member of a community could vouch for another person. Agreements could be sealed with a handshake or other symbolic gesture.

This was essentially authentication through contextual human trust.

The problem was scalability.

As societies grew and people started interacting with strangers outside their local communities, personal recognition was no longer sufficient.

This created the need for explicit proofs of identity.

Seals and Physical Authentication

During medieval times, seals became an important mechanism for validating documents and agreements.

A unique wax seal attached to a document could act as a representation of identity or authenticity.

The underlying principle was:

Something you have

If you possessed the appropriate seal, you could demonstrate that you were associated with a particular identity or authority.

However, seals could be forged.

This introduced an early form of what we would now describe as an authentication bypass: an attacker could imitate the authentication mechanism itself.

This encouraged the development of more sophisticated techniques such as watermarks, codes, and eventually cryptographic mechanisms.

3. Passwords and Shared Secrets

With the development of communication technologies such as the telegraph, secure communication became increasingly important.

People began using pre-agreed phrases or shared secrets to validate communications.

This introduced another authentication principle:

Something you know

Instead of proving identity by possessing an object, a person could prove identity by knowing a secret.

This idea eventually evolved into the modern password.

4. Authentication Enters the Digital World

As computers became multi-user systems, authentication became a core requirement.

One notable historical development occurred with MIT’s Compatible Time-Sharing System (CTSS), where passwords were introduced for multi-user computing.

Early password systems had a major security problem: passwords could be stored in plaintext.

If an attacker—or even an authorized person—obtained the password file, all credentials could potentially be exposed.

This led to an important security principle that remains fundamental today:

Never store passwords in plaintext.

Instead, passwords should be processed using secure password-hashing algorithms before being stored.

5. Password Hashing

Hashing transforms an input into a fixed-length representation.

For example:

Password
   ↓
Hashing algorithm
   ↓
Hashed representation

A secure password-storage system does not need to store the original password.

During login, the supplied password is processed and compared against the stored password hash using an appropriate password-verification mechanism.

Modern password storage should use dedicated password-hashing algorithms and appropriate salting rather than plain cryptographic hashes.

The broader evolution of authentication also became closely connected with the fundamental security properties of:

  • Confidentiality
  • Integrity
  • Availability

6. Public-Key Cryptography

The 1970s brought major developments in cryptography.

The work of Whitfield Diffie and Martin Hellman on key exchange introduced a new approach to cryptographic communication.

Public-key cryptography became an important foundation for modern security systems.

Instead of relying solely on a shared secret, asymmetric cryptography uses a public key and a private key.

This eventually became fundamental to technologies such as:

  • Public Key Infrastructure (PKI)
  • Secure communication protocols
  • Digital signatures
  • Modern authentication systems

Another important development was Kerberos, which introduced ticket-based authentication. A trusted third party could issue tickets that helped establish identity between users and services.

This concept influenced the token-based authentication mechanisms widely used today.

7. Multi-Factor Authentication

As the internet expanded, username-and-password authentication became increasingly insufficient.

Passwords are vulnerable to:

  • Brute-force attacks
  • Dictionary attacks
  • Password reuse
  • Credential theft
  • Phishing

Multi-factor authentication (MFA) introduced additional authentication factors.

The traditional categories are:

Something you know

Examples:

  • Password
  • PIN
  • Passphrase

Something you have

Examples:

  • Security key
  • Smart card
  • OTP device

Something you are

Examples:

  • Fingerprint
  • Facial characteristics
  • Other biometric characteristics

The idea behind MFA is simple: compromising one factor should not automatically compromise the entire authentication system.

8. Biometrics

Biometric authentication uses physical characteristics to identify users.

Examples include:

  • Fingerprints
  • Facial recognition
  • Retina or iris-based systems

Biometric systems use pattern-recognition techniques to compare a user’s biometric characteristics with stored representations.

However, biometrics also introduce challenges such as:

  • False positives
  • False negatives
  • Secure biometric-template storage
  • Privacy concerns

Therefore, biometrics are an important authentication mechanism, but they are not a universal solution to every authentication problem.

9. Modern Authentication

The 21st century introduced another major shift.

Applications became:

  • Cloud-based
  • Distributed
  • Mobile-first
  • API-driven
  • Microservice-oriented

Traditional authentication mechanisms alone were not sufficient for these architectures.

Modern systems therefore commonly use technologies such as:

  • Sessions
  • Cookies
  • JWTs
  • OAuth 2.0
  • OpenID Connect
  • Passwordless authentication
  • WebAuthn
  • Zero-trust architectures

At the same time, emerging approaches such as decentralized identity, behavioral biometrics, and post-quantum cryptography continue to shape the future of authentication.

10. Three Important Components: Sessions, JWTs, and Cookies

Before discussing authentication architectures, backend engineers should understand three important concepts:

  • Sessions
  • JWTs
  • Cookies

They are related, but they are not the same thing.

11. Sessions

HTTP was designed to be stateless.

That means each HTTP request is treated independently. The server does not automatically remember previous requests.

This worked well for the early web, which primarily consisted of static pages and documents.

But modern applications needed continuity.

Consider an e-commerce website.

The server needs to remember:

  • Who you are
  • Whether you’re logged in
  • What is in your shopping cart
  • Your permissions
  • Other temporary application state

This led to the concept of sessions.

How session-based authentication works

A typical flow looks like this:

Client
   │
   │ Username + Password
   ▼
Server
   │
   │ Create session
   ▼
Session Store
   │
   │ Session ID
   ▼
Client Cookie

When a user successfully logs in:

  1. The server validates the credentials.
  2. The server creates a unique session ID.
  3. The session information is stored on the server.
  4. The session ID is sent to the browser.
  5. The browser sends the session ID with subsequent requests.
  6. The server uses the session ID to retrieve the associated session information.

The session data might be stored in:

  • A database
  • Redis
  • Another server-side storage system

12. Why Redis Is Commonly Used for Sessions

Early implementations could store sessions in files.

However, file-based sessions become difficult to scale as the number of users increases.

Databases provide more persistent storage, but high-volume session lookups can also create performance and scaling challenges.

Distributed in-memory stores such as Redis can provide fast access to session information.

A simplified architecture can look like:

                ┌──────────────┐
                │    Client    │
                └──────┬───────┘
                       │
                  Session ID
                       │
                       ▼
                ┌──────────────┐
                │    Server    │
                └──────┬───────┘
                       │
                  Session lookup
                       │
                       ▼
                ┌──────────────┐
                │    Redis     │
                └──────────────┘

13. What Is a Cookie?

A cookie is a mechanism that allows a website to store information in a user’s browser.

The browser can then automatically send the cookie back to the appropriate server on subsequent requests.

This makes cookies extremely useful for authentication.

For example:

Login
  ↓
Server creates session
  ↓
Server sends session ID as cookie
  ↓
Browser stores cookie
  ↓
Browser automatically sends cookie
  ↓
Server identifies the session

Authentication cookies are commonly configured with security-related attributes such as:

  • HttpOnly
  • Secure
  • SameSite

An HttpOnly cookie cannot normally be accessed by JavaScript, reducing exposure to certain client-side attacks.

14. JWT Authentication

As web applications became globally distributed, traditional server-side sessions introduced additional operational challenges.

Large systems may need to maintain session information across:

  • Multiple servers
  • Multiple regions
  • Multiple services

Synchronizing session state can introduce complexity and latency.

This contributed to the popularity of JSON Web Tokens (JWTs).

JWTs provide a way to transfer claims between parties in a compact, signed token.

A JWT consists of three main parts:

Header.Payload.Signature

JWT Header

The header contains metadata about the token.

For example, it can identify the signing algorithm.

JWT Payload

The payload contains claims.

A token may contain information such as:

{
  "sub": "user123",
  "iat": 1720000000,
  "role": "admin"
}

The sub claim commonly represents the subject or user identifier.

The iat claim represents when the token was issued.

Applications can also define additional claims according to their requirements.

JWT Signature

The signature allows the receiving system to verify that the token was issued by a trusted party and that its signed contents have not been modified.

Conceptually:

Header + Payload
       ↓
Signing process
       ↓
Signature

If someone modifies the payload after the token has been signed, signature verification should fail.

15. Why JWTs Became Popular

JWTs offer several useful properties.

Statelessness

The server can validate a token without necessarily maintaining a server-side session for every user.

Scalability

Multiple servers can validate tokens using the appropriate verification keys.

Portability

JWTs are compact and can be transferred between different systems and services.

This makes them particularly useful in distributed and API-oriented architectures.

16. The Problem With JWTs

JWTs are not a magic replacement for sessions.

One major challenge is revocation.

Imagine a user receives a JWT that expires in one hour.

If the token is stolen, the attacker may be able to use it until it expires.

Because the server is not necessarily maintaining a session record for the token, immediately invalidating a particular token becomes more complicated.

Changing the signing key could invalidate tokens, but that can also invalidate tokens belonging to every user.

This is one reason token lifetime, refresh-token strategies, revocation mechanisms, and secure token storage are important parts of a production authentication architecture.

17. Stateful vs. Stateless Authentication

Let’s compare the two approaches.

Feature Stateful Stateless
Server-side session Yes Usually no
Common mechanism Session ID JWT
Centralized session control Strong More difficult
Token revocation Easier More complex
Distributed scaling More operational complexity Generally easier
Server-side storage Required Not necessarily required

Stateful authentication

A stateful system keeps authentication state on the server.

This provides excellent control over sessions and makes revocation straightforward.

Stateless authentication

A stateless system places relevant claims inside a signed token.

The server validates the token rather than looking up a session for every request.

18. Which One Should You Use?

There is no universal answer.

For traditional web applications, stateful authentication can be an excellent choice because session management and revocation are straightforward.

For distributed APIs, mobile applications, and machine-to-machine communication, stateless tokens can be useful.

A system can also use a hybrid architecture.

For example:

Browser
   ↓
Stateful session authentication

Mobile/API clients
   ↓
Token-based authentication

The correct choice depends on the application’s architecture, security requirements, scalability requirements, and operational constraints.

19. API Key Authentication

API keys solve a different problem.

They are particularly useful for programmatic or machine-to-machine access.

Imagine a service provides an API.

Instead of a human logging into the service through a web interface, another application needs to call the API.

An API key can provide a simple way to identify that application.

The workflow can look like:

Application A
     │
     │ API Key
     ▼
Application B
     │
     │ Validate key
     ▼
API Response

API keys are commonly useful for:

  • Machine-to-machine communication
  • Developer APIs
  • Automation
  • Server-to-server integrations

They can also be associated with permissions, quotas, and expiration policies depending on the system.

20. API Keys vs. User Authentication

A user authentication flow might look like:

User
 ↓
Login
 ↓
Username + Password
 ↓
Authentication
 ↓
Session/JWT
 ↓
API requests

Machine-to-machine communication can instead look like:

Service A
 ↓
API Key
 ↓
Service B
 ↓
API Response

There is no need for a human to interact with a login form every time the service needs to make a request.

However, API keys must be treated as secrets and protected carefully. A leaked API key can allow unauthorized access to the resources associated with that key.

21. OAuth 2.0 and the Delegation Problem

As the number of internet applications grew, another problem emerged.

Suppose an application needs access to resources belonging to another service.

For example:

Travel application
       ↓
Needs access to
       ↓
User's email/calendar/resources

An early and dangerous approach was to share passwords.

That creates a serious problem.

A password generally provides broad access to an account. If you give another application your password, you may effectively give it the ability to perform many actions as you.

There is also no clean way to limit exactly what that application can access.

This is known as the delegation problem.

22. OAuth 2.0

OAuth introduced a much better model:

Delegate limited access without sharing the user’s password.

Instead of giving an application your password, you authorize it and provide an access token with specific permissions.

Conceptually:

User
  │
  │ Grants permission
  ▼
Authorization Server
  │
  │ Access Token
  ▼
Application
  │
  │ Access Token
  ▼
Resource Server

The token can represent a limited scope of access.

For example, an application might receive permission to:

  • Read a user’s profile
  • Read calendar information
  • Read contacts

without receiving the user’s master password.

This is one of the most important ideas behind modern delegated authorization.

23. OAuth 2.0 Is About Authorization

A common misconception is that OAuth is simply a login mechanism.

OAuth 2.0 is primarily an authorization framework.

It allows a client application to obtain limited access to resources on behalf of a user.

For authentication and identity information, OpenID Connect (OIDC) is commonly used on top of OAuth 2.0.

This distinction is important for backend engineers:

OAuth 2.0 → delegated authorization
OpenID Connect → authentication/identity layer built on OAuth 2.0

24. Authorization and RBAC

After authentication comes authorization.

Knowing that a user is user123 is not enough.

The backend must also determine what user123 is allowed to do.

This is where Role-Based Access Control (RBAC) becomes useful.

A system may have roles such as:

  • User
  • Moderator
  • Editor
  • Administrator

Each role can have a specific set of permissions.

For example:

Role Read Write Delete
User ✅ ❌ ❌
Editor ✅ ✅ ❌
Admin ✅ ✅ ✅

25. How RBAC Works

A typical RBAC workflow looks like this:

User
 ↓
Authentication
 ↓
Identify User
 ↓
Determine Role
 ↓
Check Permission
 ↓
Allow / Deny Request

For example:

User → Role: Editor
             ↓
       Write Permission
             ↓
       Article API
             ↓
          Allowed

If the user does not have the required permission, the server can reject the operation.

A common HTTP response for insufficient permissions is:

403 Forbidden

26. Authentication vs. Authorization in an API

Consider:

GET /admin/users

The backend might perform these steps:

Step 1 — Authentication

Determine who is making the request.

User ID = 123

Step 2 — Authorization

Determine what role or permissions the user has.

Role = user

Step 3 — Permission check

Determine whether that role can access /admin/users.

Required role = admin
Actual role = user

Result → Forbidden

This separation is fundamental to secure backend architecture.

27. Multi-Tenant Authorization

Authorization becomes even more important in multi-tenant applications.

Imagine a SaaS platform where users belong to organizations.

An organization administrator might want to assign:

Member A → Read
Member B → Read + Write
Member C → Read + Write + Delete

The authorization system therefore needs to understand:

  • User identity
  • Organization
  • Role
  • Resource
  • Permission

This can lead to more granular authorization models beyond simple roles.

28. Don’t Reveal Too Much Through Authentication Errors

Security-conscious backend engineers should be careful about authentication error messages.

Consider these responses:

User not found

and:

Incorrect password

They appear helpful to legitimate users, but they can provide useful information to attackers.

For example:

User not found

could reveal that an email address is not registered.

Meanwhile:

Incorrect password

could confirm that the username exists.

An attacker could use this information for username enumeration.

A safer approach is to use a generic response such as:

Authentication failed.

The goal is to avoid revealing unnecessary information about which part of the authentication process failed.

29. Timing Attacks

Another security consideration is response timing.

Imagine an authentication system performs:

1. Find user
2. Check account status
3. Verify password

If the username does not exist, the system might immediately return an error.

If the username exists but the password is wrong, the system may spend additional time performing password verification.

An attacker could potentially measure these differences.

For example:

Invalid username → 50 ms
Invalid password → 200 ms

Repeated measurements could reveal information about whether an account exists.

This is an example of a timing attack.

30. Defending Against Timing Attacks

Backend systems can reduce timing differences by using appropriate constant-time cryptographic comparison mechanisms and designing authentication flows so that observable execution times do not unnecessarily reveal which step failed.

The important principle is:

Avoid allowing authentication failures to reveal information through timing differences.

Authentication security is therefore not just about passwords and tokens. Even seemingly small implementation details can leak useful information.

31. Should You Build Authentication Yourself?

For learning, implementing authentication yourself is extremely valuable.

It helps you understand:

  • Password hashing
  • Sessions
  • Cookies
  • JWTs
  • Token validation
  • Authorization
  • Roles
  • Permissions
  • Security trade-offs

But production authentication is considerably more complicated than implementing a basic login form.

A production system may need to handle:

  • Password resets
  • Email verification
  • MFA
  • Session management
  • Account recovery
  • Token rotation
  • Revocation
  • Rate limiting
  • Credential attacks
  • Security monitoring
  • OAuth/OIDC integrations
  • Secure cookie configuration
  • Password hashing
  • Account lockout policies

For medium-to-large production systems, using a well-established identity/authentication provider can reduce the amount of security-sensitive infrastructure your team has to maintain.

The important thing is to understand what the provider is doing and why, rather than treating authentication as a black box.

32. A Practical Mental Model for Backend Engineers

When designing authentication and authorization, think about the system in layers:

                    ┌─────────────────────┐
                    │      Client         │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │   Authentication    │
                    │    Who are you?     │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │ Identity / Session  │
                    │    / Token / JWT    │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │   Authorization     │
                    │   What can you do?  │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │ Permissions / RBAC  │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │    Application      │
                    │      Resource       │
                    └─────────────────────┘

This mental model makes many authentication architectures much easier to understand.

33. Key Takeaways

Authentication and authorization are closely related but fundamentally different concepts.

Authentication establishes identity.

Authorization determines permissions.

The evolution of authentication has moved through several stages:

Human Trust
    ↓
Physical Tokens / Seals
    ↓
Shared Secrets
    ↓
Passwords
    ↓
Password Hashing
    ↓
Public-Key Cryptography
    ↓
MFA & Biometrics
    ↓
Sessions & Cookies
    ↓
JWTs & Token-Based Authentication
    ↓
OAuth 2.0 / OpenID Connect
    ↓
Passwordless & Modern Identity Systems

For backend engineers, the most important concepts to understand are:

  • Authentication vs. authorization
  • Password hashing
  • Sessions
  • Cookies
  • JWTs
  • Stateful vs. stateless authentication
  • API keys
  • OAuth 2.0
  • OpenID Connect
  • RBAC
  • Permissions
  • Token revocation
  • Secure authentication errors
  • Timing attacks

The goal is not to memorize every authentication technology. The goal is to understand why each mechanism exists, what problem it solves, what security trade-offs it introduces, and when it makes sense to use it.

That understanding becomes especially important as applications move from simple monolithic systems to distributed, API-driven, cloud-native architectures.

Tags:

Leave a Reply