3 ms·

I like basic auth (Header of `Authorization: Basic username:password`) but for persistent session auth I prefer the Bearer tokens[1][2] (Header of `Authorizatio

I like basic auth (Header of `Authorization: Basic username:password`) but for persistent session auth I prefer the Bearer tokens[1][2] (Header of `Authorization: Bearer my_token_here`). It's easy to generate a hash after the user logs in and then just store it in a cookie. The user doesn't have to store their password locally and I can delete the token from the database to force them to re-login. You can reuse the same token generation infra for APIs too so its pretty dynamic. I've basically moved away from JWTs in favor of this simpler approach. [1]: (list of auth schemes) https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication#authentication_schemes https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentica... [2]: (Bearer auth spec) https://datatracker.ietf.org/doc/html/rfc6750 https://datatracker.ietf.org/doc/html/rfc6750

creeble 5y ago
Surprised there aren’t more comments here - does everyone agree that this is equivalent (in security terms) to using JWT? I would very like to never use JWTs again.
- devmunchies 5y ago
  i listen to a few cryptography podcasts and cryptography is an interest of mine[1]. most security engineers agree that JWT has too much of a surface area and takes a lot of care from the implementer that it can lead to security holes[2]. Another reason i like just generating a securiity token when the user logs in is that i can require a join on the table for any query so that its extra secure. e.g. if fetching "posts" for a "user" and i have 3 tables (users, posts, and user_tokens) i can do an inner join like this (if the `posts` table has `user_id`): select p.* from posts p inner join user_tokens ut using (user_id) where p.user_id = $1 and ut.token = $2 -- `users` table wasn't needed for this join since am not selecting from it with JWTs the security happens once when you verify the JWT signature, but then security is less of a focus when making queries, which would complicate queries anyway since you have to make sure the same user who owns the JWT has access to the data (it handles authentication but not authorization). You still need to hit the database anyway for fetching any data so the headless approach for JWTs isn't really saving me much, so I like to just bake in security for the queries. [1]: I recommend new book "Real World Cryptography" by David Wong [2]: (podcast about JWTs from cryptographer, august 2021) https://securitycryptographywhatever.buzzsprout.com/1822302/9020991-what-do-we-do-about-jwt-feat-jonathan-rudenberg https://securitycryptographywhatever.buzzsprout.com/1822302/... -- EDIT: would probably want a few more predicates in that query to account for token status. e.g. where p.user_id = $1 and ut.token = $2 and ut.is_revoked = false and ut.is_expired = false

creeble 5y ago

Surprised there aren’t more comments here - does everyone agree that this is equivalent (in security terms) to using JWT? I would very like to never use JWTs again.

devmunchies 5y ago
i listen to a few cryptography podcasts and cryptography is an interest of mine[1]. most security engineers agree that JWT has too much of a surface area and takes a lot of care from the implementer that it can lead to security holes[2]. Another reason i like just generating a securiity token when the user logs in is that i can require a join on the table for any query so that its extra secure. e.g. if fetching "posts" for a "user" and i have 3 tables (users, posts, and user_tokens) i can do an inner join like this (if the `posts` table has `user_id`): select p.* from posts p inner join user_tokens ut using (user_id) where p.user_id = $1 and ut.token = $2 -- `users` table wasn't needed for this join since am not selecting from it with JWTs the security happens once when you verify the JWT signature, but then security is less of a focus when making queries, which would complicate queries anyway since you have to make sure the same user who owns the JWT has access to the data (it handles authentication but not authorization). You still need to hit the database anyway for fetching any data so the headless approach for JWTs isn't really saving me much, so I like to just bake in security for the queries. [1]: I recommend new book "Real World Cryptography" by David Wong [2]: (podcast about JWTs from cryptographer, august 2021) https://securitycryptographywhatever.buzzsprout.com/1822302/9020991-what-do-we-do-about-jwt-feat-jonathan-rudenberg https://securitycryptographywhatever.buzzsprout.com/1822302/... -- EDIT: would probably want a few more predicates in that query to account for token status. e.g. where p.user_id = $1 and ut.token = $2 and ut.is_revoked = false and ut.is_expired = false