undefined | Better HN

0 pointskbutler8y ago0 comments

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.

0 comments

matwood8y ago

> 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.

azernik8y ago

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.

matwood8y ago

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.

MichaelGG8y ago

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.

matwood8y ago

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.

1 more reply

j / k navigate · click thread line to collapse

0 pointskbutler8y ago0 comments

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.

0 comments

matwood8y ago

> 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.

azernik8y ago

matwood8y ago

MichaelGG8y ago

matwood8y ago

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 more reply

j / k navigate · click thread line to collapse