ELI5: Why is stateful authentication better for web apps, but stateless better for mobile apps and apis?

Comments

1. 

   eloquent_beaver

   April 13, 2025

   This is a /r/AskProgramming question.

   Basically, it comes down to the fact that the browser-based model of UX and server interaction that all of use to access the web lends itself very well toward cookie-based authentication, which while not required to be stateful, has historically been stateful in that upon successful authentication (whether bearer token based like w/ a username and password, or through an email or text link or code, or through federation from an identity provider, i.e. SSO), the server creates and remembers (via some persistence layer, like a database) a privileged session and sets a cookie (through a Set-Cookie HTTP header) in your browser which includes some kind of bearer credential that your browser will automatically present, from which the server can look it

   This is not the only way to do cookie-based authn, but it is the most common.

   There is another PKI-based pattern in which a server can set a cookie that’s an encrypted and/or signed blob containing claims about your identity, e.g., your username / user ID, as well as what permissions you have, and then since it’s a cookie, your browser will present that with every request, the server can decrypt and validate the info, and since it’s the only one who can produce such a blob, it can authenticate you on the basis of that blob in your cookie. This is totally stateless, as it doesn’t require the server to remember or persist anything about your session—rather, the server signs messages and hands them to your client, which the client later gives to the server, and the server can authenticate that it did indeed produce the message at an earlier time, without anything being stored anywhere. The downside of this is it doesn’t lend itself well to logout mechnanisms. When a user logs out, they expect that session to truly be invalidated, and short of maintaining some sort or CRL (certificate revocation list)-like mechanism for remembering invalidated tokens, there’s no mechanism to enforce invalidation statelessly.

   APIs are generally expected to behave statelessly. That is, since the expected interaction model is stateless (you don’t “login,” do stuff under the context of a login session, and “logout” when working with an API), it makes more sense to use stateless protocols like OAuth / OIDC / SAML.

2. 

   dave8271

   April 13, 2025

   In a web browser, the server can set a token to authenticate the user in a cookie and the browser will automatically send that cookie with every subsequent request.

   In an API, it’s up to each individual consumer how they craft the request, so you just give them a token from an auth endpoint and say hey, remember to include that every time you make a request. No point adding the extra hassle of setting a cookie header and making the client parse it to extract a token, then set their own cookie header in subsequent requests. It’s pointless extra work. They still need to include the auth in the request somewhere (usually in a header called Authorization) but TLDR; cookies in browsers are handled automatically, by design. If you’re not targeting a browser, you don’t know how the consumer will handle cookies.