Overview
Authentication is not a single moment but a sequence of states a request moves through: from unauthenticated, through the act of authenticating, to authenticated — and eventually back again when a session ends. In authentication-focused CTF challenges, the flag is usually hidden behind a state you are not supposed to reach, and solving the challenge means understanding exactly how the application decides which state you are in. This lesson maps out those states so later lessons on sessions, weak designs, and access controls make sense.
Learning objectives
- Distinguish the core authentication states an application tracks.
- Explain the difference between authentication and authorization.
- Recognize how an application decides whether a request is authenticated.
- Identify where flawed state handling creates a challenge (or a real vulnerability).
Core concept
Authentication answers the question "who are you?". An application tracks each request's authentication state to decide what that request is allowed to see and do. The common states are:
- Unauthenticated (anonymous) — the request carries no proven identity. The user has not logged in, or their session has ended.
- Authenticating — the transitional step where credentials (a password, a token, a one-time code) are being submitted and verified.
- Authenticated — the application has accepted proof of identity and now associates the request with a specific user.
A crucial companion concept is authorization, which answers "what are you allowed to do?". Authentication establishes identity; authorization uses that identity to grant or deny access to specific resources. Being authenticated as a low-privilege user is not the same as being authorized to reach an admin-only page — a distinction that the access-controls lesson builds on directly.
How it works
An application cannot "remember" you between HTTP requests on its own, because HTTP is stateless — each request arrives independently. To track authentication state, the server issues something the client returns on every subsequent request, most often a session identifier stored in a cookie, or a token sent in a header. On each request the server:
- Reads the identifier or token the client presents.
- Looks up (or validates) it to determine which user, if any, it belongs to.
- Sets the request's authentication state accordingly — anonymous if nothing valid is presented, authenticated if it is.
- Hands the decision to the authorization layer, which checks whether that identity may perform the requested action.
The security of the whole system depends on the server making step 2 and 3 correctly. If the server can be tricked into treating an unauthenticated request as authenticated, or a normal user as an administrator, the state machine is broken — and that is precisely what authentication challenges probe.
Practical example
Consider a deliberately vulnerable practice application running in an isolated lab. It has three pages: a public home page, a login form, and a /dashboard that should require login. You visit /dashboard while unauthenticated and are redirected to the login form — the expected behavior for the anonymous state. You then log in with valid lab credentials, the server issues a session cookie, and now the same /dashboard request succeeds because your state is authenticated.
The challenge appears when the application decides state poorly. Suppose /dashboard checks for the mere presence of a cookie named logged_in rather than validating a real session. Setting logged_in=true in your own browser — something entirely under your control as the client — would flip you to the "authenticated" state without ever proving identity. Recognizing that the server trusts client-controlled data to set authentication state is the whole solution. (This is a teaching example on a system you are authorized to test, not a technique for real sites.)
Cybersecurity relevance
Authentication state handling is one of the most consequential parts of any application, which is why it is a standing category in security testing and appears prominently in frameworks like the OWASP Top 10 under identification and authentication failures. Real breaches frequently trace back to state confusion: endpoints that forget to check authentication, "authenticated" flags the client can forge, or transitions (such as password reset or multi-factor steps) that can be skipped. Learning to reason about which state the server thinks a request is in, and why is a transferable skill that applies equally to CTF flags and to production security reviews.
Common mistakes
- Conflating authentication with authorization — proving who you are is not the same as being allowed to act.
- Trusting client-controlled data to set state — cookies, hidden fields, and headers the client can edit must never by themselves decide "authenticated."
- Assuming every endpoint re-checks state — some applications protect the login flow but forget to guard individual API routes.
- Ignoring the transition steps — password reset, "remember me," and multi-factor stages are part of the state machine and are often where flaws hide.
Key takeaways
- Authentication is a state machine: unauthenticated → authenticating → authenticated, and back to unauthenticated when the session ends.
- Authentication ("who are you?") is distinct from authorization ("what may you do?"); the two work together but fail differently.
- Because HTTP is stateless, the server relies on a session identifier or token presented on each request to determine state — and must validate it, not merely detect its presence.
- Challenges and real vulnerabilities arise when the server sets or trusts authentication state incorrectly.
Check your understanding
- What is the difference between authentication and authorization, and why does the distinction matter?
- Since HTTP is stateless, how does a server decide whether an incoming request is authenticated?
- Why is checking for the presence of a cookie a weak way to determine authentication state?