Authentication

In the Overview, you have been introduced to the actors (APIs, services, apps, etc) that plays a role in the whole thing. Now, how exactly CakeAuth go out and actually helps you managing and securing your users and applications?

There are 2 main important things that we need to do properly in order to achieve a secure and seamless applications: Authentication, and Authorization.

Authentication

To put it simply, this is a process to verify whether a party really are they say they are. There are two most common approaches on authentication: Stateful Authentication, and Stateless Authentication.

Stateful Authentication

Stateful authentication probably one of the most common authentication pattern.

To put it simply:

• On "sign in", if all the credentials is valid, server issues a session identifer.
• On every authentication request, server check against a database of session identifier and check the state (hence the name stateful comes from) whether all the data is still valid.

This approach becomes the most popular arguably because it's the simplest.

But, what happens if an attacker gets their hands on your session identifier? Generally, the answer here is that you're in trouble. If an attacker gets your session identifier, they can sign in as you. And the common nature of the session identifier out there is a long-lived identifier (not all, but it's pretty common).

Therefore, it's best practice to use HTTPS (ensures attacker can't sniff it) and ensure it's stored in the HttpOnly cookie (ensures attacker can't get it via remote JavaScript execution in the browser environment) or in an encrypted storage for native mobile environments.

Stateless Authentication

Stateless authentication becomes popular especially after the rise of JSON Web Token (JWT). And this is the authentication strategy that CakeAuth primarily uses.

The process of stateless authentication initially are pretty similar with the stateful authentication. But, on the every authentication request, there's some major differences.

• On "sign in", if all the credentials is valid, server issues: access token & session token.
  • Access token are short lived. CakeAuth takes it to almost extreme, our access token validity is 59 seconds.
  • Session token (or also commonly called refresh token) are slightly long lived. This is the token that client uses to regenerate new Access Token. In CakeAuth, you can set it up on the session lifetime settings.
• On every authentication request, instead of check database, server only need to check the authenticity of the access token. Since the access token are short-lived, the attack surface for bad guys are really slim.

Pros & Cons

Stateful Authentication

Stateful authentication stores session data on the server, usually in memory or a database.

✅ Pros:

• Session persistence: Users remain logged in without re-authenticating frequently.
• Stronger session control: The server can invalidate sessions immediately.
• More flexibility: Supports features like server-side session management, tracking, and auditing.

❌ Cons:

• Scalability issues: Each request requires access to session data, which can create bottlenecks.
• Increased server load: Storing sessions increases memory usage and database queries.
• Requires session replication: In distributed systems, sessions must be shared across instances.

Stateless Authentication

Stateless authentication does not store session data on the server. Each request contains all necessary authentication data (e.g., JWT).

✅ Pros:

• Scalability: No session storage needed, making it ideal for distributed systems.
• Performance: Reduces database queries and memory usage.
• Flexibility: Works well with microservices and serverless architectures.

❌ Cons:

• Harder to revoke tokens: Cannot easily invalidate a token until it expires.
• Increased token size: JWTs can grow large, impacting request performance.
• Token validity gap: If a token is compromised, it remains valid until expiration if the access token validity is too long.