Proving who you are. The system's way of confirming you are the account holder before letting you in.
Why it exists
Once orders belong to people, the system has to know who is making a request, not just that some browser sent it. Anyone could otherwise claim to be anyone. Authentication exists to prove identity at the start of a session, so every later action can be tied to a real, verified account.
How it actually works
Orders belong to people, so the system must know who is asking. Authentication is the check: you present something only you should have (a password, a code, a fingerprint), and the server confirms it matches the account.
Once confirmed, the server needs a way to remember you across the next requests without asking again every click. That is where sessions and tokens come in.
A senior PM walks you through it
A junior PM, stuck
Rafi pasted a raw response from our login endpoint into Slack, a 401 with some JSON, and asked me to confirm it is the expected wrong-password behaviour before he closes the bug. I could not read it well enough to say yes or no, and I did not want to guess on something with "auth" in it.
You can answer this yourself in five minutes. A login call has exactly two honest outcomes, and reading them side by side makes the wrong-password one obvious. This is the same login attempted twice: once with a wrong password, once with the right one. Read both and you will know whether Rafi's 401 is the system working or a bug.
POST /api/auth/login, wrong password then right password
Treating every red status as a bug. A 401 on a wrong password is the gate doing its job; the real bug would be a 200 that let the wrong password through.
Confusing 401 and 403. 401 is "I do not know who you are," 403 is "I know you but you cannot do this." Filing one as the other sends the ticket down the wrong path.
Expecting the error body to explain everything. invalid_credentials deliberately does not say whether the email or the password was wrong; telling an attacker which half they got right is a security leak, not a missing feature.
Assuming the token is harmless to paste around. That access_token is a working key for 15 minutes; treat it like the password it stands in for.
Reply to Rafi: "Confirmed, 401 invalid_credentials is the expected wrong-password response, the system is working. A 500 or a 200 there would be the bug." You read the status, matched it to the behaviour, and cleared the ticket. That is the skill.
Where a PM meets this
Authentication is the front gate. Its friction (how many steps to log in) directly trades against its security, and that trade is a product decision.
"Auth" problems are high-severity: if login breaks, nobody can use the product at all.