Yes, it does.

If you want to be completely stateless, you need to send the authorization info on each request, probably as basic auth headers.

This is actually simpler than implementing the Bearer token, for both client and server, but requires that the client retain the non-expiring username and password, rather than retaining the expiring, session-specific Bearer token.

> but requires that the client retain the non-expiring username and password

IMO, this makes this simpler solution a non-starter. It becomes way too easy to leak credentials.

The auth framework I use avoids this problem but remains stateless by encrypting/signing the tuple (user ID, session expiration time, maybe other stuff) in a cookie. Essentially it's using the browser as an encrypted one-row database to store the info that would normally be in a sessions table.

This can work, but you want to keep what you send with every request very small. It's also hard to do a mass expiration or revoke a single session. If you have the tokens on the server you can run a query and easily do both. Checking signatures and decrypting on every request can also be a performance issue.

How so? The client needs to have the username and password to call the login function over and over, as well as managing the session token. It's just incredibly annoying with no benefits in nearly every scenario.

The client should not store the user/pass [1]. If the token expires, the user needs to provide a user/pass to login in again. The user should also be forced to provide a user/pass in order to change the password - something that cannot be enforced if keeping the user/pass on the client.

You also lose any method to force a re-authentication. With a token, I could expire with no activity for an hour and allow it to be good for a max of 2 hours.

[1] Users have a bad habit of just leaving computers. With a token, the worst case is someone has a short lived access to to something. With a user/pass left on the client worst case now becomes use/pass taken.

What is the client? OP says API which sounds more machine to machine. If you mean the API powering a site, used from the client's browser, then sure. Track separate logins, then give them a control panel to see where they're logged in.

But most clients store their user/pass in their browser anyways so I'm not sure it's a security win for preventing credential loss.

You don't lose re-auth. The master system issuing API keys can revoke keys, too.

But anyways maybe we're talking about different contexts because I don't understand the scenario you're describing.

I see. I read "Rest API" as securing the server portion with no implication that it meant only server to server. Cheers!

Yes, if you mean a token that identifies a session that is saved on the server somehow. But not a JWT, which is only saved on the client and verified on the server.

"Stateless" refers to the app, not to its datastores, because that would be nonsensical.

JWT is also poorly specified (no protocol under any circumstances should use negotiation, it does not support revocation, and it has been hammered home by the best security folks I know that public key cryptography is what you do when you don't have any other choice) and dangerous to use. Avoid it. Do the simplest thing that can possibly work. That's a session token. If, in the far and unlikely future, you are so successful that a single database call is so harmful, then you have the money to hire someone who doesn't have to Ask HN this question.

Totally agree -- but verifying a session token doesn't even have to be a database call. Put the token in memcache or redis; now, if you are so successful that a single network call that doesn't touch disk is your bottleneck, well, you can hire some very smart people to fix that for you.

If you use it for authorization only, it doesn’t.