Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What do you use for authentication and authorization?

news.ycombinator.com

Post reply on HN
Print view View original

31–40 of 247 posts

Re: Ask HN: What do you use for authentication and authorization?

#31

Post by throwawaymath »

chirau wrote: post #26

Why do all API development tutorials always say "Never roll out your own custom auth"? I always found it weird

They say it because as a development exercise it is both seductively attractive and very dangerous. Furthermore, almost no one's authentication problems are unique or unsolved.

There is approximately never a good reason for a team to roll their own authentication solution from the base primitives unless that's both their core competency and their product differentiation. It offers virtually no upside for virtually certain downside.

Re: Ask HN: What do you use for authentication and authorization?

#32

Post by CorvusCrypto »

jakelazaroff wrote: post #27
CorvusCrypto wrote: post #25

Earlier quoted context omitted.

Same goes for any signed token scheme. You can still revoke JWTs if you give them an ID and keep a revoke list somewhere. Though as you said most use these to avoid datastore lookups. It's a trade off. Either time-limit signed tokens that can't be revoked with benefit of no lookups or implement revokation.

"No revocation" is a dangerous constraint to have in an authentication session. What happens if a user's token is compromised? You have to either wait for the token to expire (if you implemented expiry) or log out every single user.

That's exactly the trade-off. I'm not going to say it's a big enough negative to dismiss using the stateless signed token scheme because it depends on the needs of the application.

But either way, if you really can't afford a database or cache layer lookup to see if a token is still valid, then you accept that by using a bearer token, that is only validated by signature alone, that it is possible a user will have their session hijacked without possibility of revokation.

The usual way this is mitigated is by use of a small expiry time (I've commonly seen <=5 min) and a revokable refresh token. This still gives a hijacker a possible 5 minutes (assuming 5 minute expiry) if a user revoked the refresh token, but it does mitigate the damage while still reducing DB lookups since you only do a lookup in token refresh. Hope that clears things up. Again your application needs should drive these decisions.

Re: Ask HN: What do you use for authentication and authorization?

#33

Post by geezerjay »

throwawaymath wrote: post #24
kc10 wrote: post #20

Earlier quoted context omitted.

It's a common practice to add expiry timestamp for such tokens so each token will expire after certain interval.

That's dandy, but it's a solution which is neither standardized nor native to JWT. It's also a weak, passive form of revocation instead of a robust, active form. How do do you revoke a token prior to timestamp expiry? In 2018 it is fully possible to use authentication libraries which natively support granular control for things like revocation using strong, turnkey cryptography. I would argue most people who think th…

> That's dandy, but it's a solution which is neither standardized nor native to JWT.

That statement is false.

JWT were specifically designed to store a payload JSON object which among the many standardized fields include the token's expiry time, and JWT were specifically designed with a workflow which includes not only client-side token refreshing but also server-side token rejection that triggers client-side token refreshes.

In fact, JWT token refreshes and token rejections feature in any basic intro tutorial to JWT, including the design principle that tokens should be discarded and refreshed by the client as soon as possible and also the use of nonces.

Re: Ask HN: What do you use for authentication and authorization?

#34

Post by tyldum »

jakelazaroff wrote: post #27
CorvusCrypto wrote: post #25

Earlier quoted context omitted.

Same goes for any signed token scheme. You can still revoke JWTs if you give them an ID and keep a revoke list somewhere. Though as you said most use these to avoid datastore lookups. It's a trade off. Either time-limit signed tokens that can't be revoked with benefit of no lookups or implement revokation.

"No revocation" is a dangerous constraint to have in an authentication session. What happens if a user's token is compromised? You have to either wait for the token to expire (if you implemented expiry) or log out every single user.

Indeed. However, this is just a building block and not a library solution. Combined with a revocation list you are good. And use something like OpenPolicyAgent to implement it, adding a lot of other possibilities as well.

Re: Ask HN: What do you use for authentication and authorization?

#36

Post by metafunctor »

arkadiyt wrote: post #4

Hard to say without more concrete details, but if I had to reply in broad strokes: - For web, user/pass login exchanged for plain session cookies. Should be marked httpOnly/Secure, and bonus points for SameSite and __Host prefix [1] - For web, deploy a preloaded Strict-Transport-Security header [2] - For api clients, use a bearer token. Enforce TLS (either don't listen on port 80, or if someone makes a request over p…

If you have an API, you can program your web client like an API client, using bearer tokens for authentication (put them in local storage). It's probably better than cookies.

Re: Ask HN: What do you use for authentication and authorization?

#37

Post by mixmastamyk »

aeleos wrote: post #12
arkadiyt wrote: post #4

Hard to say without more concrete details, but if I had to reply in broad strokes: - For web, user/pass login exchanged for plain session cookies. Should be marked httpOnly/Secure, and bonus points for SameSite and __Host prefix [1] - For web, deploy a preloaded Strict-Transport-Security header [2] - For api clients, use a bearer token. Enforce TLS (either don't listen on port 80, or if someone makes a request over p…

Isn't JWT also a type of bearer token? Could you please provide some more detailed arguments about why JWT shouldn't be used other than linking its wikipedia article?

Tptacek shits on them every time it comes up. Unfortunately I can never quite comprehend what he says to do instead.

Re: Ask HN: What do you use for authentication and authorization?

#39

Post by throwawaymath »

geezerjay wrote: post #33
throwawaymath wrote: post #24

Earlier quoted context omitted.

That's dandy, but it's a solution which is neither standardized nor native to JWT. It's also a weak, passive form of revocation instead of a robust, active form. How do do you revoke a token prior to timestamp expiry? In 2018 it is fully possible to use authentication libraries which natively support granular control for things like revocation using strong, turnkey cryptography. I would argue most people who think th…

> That's dandy, but it's a solution which is neither standardized nor native to JWT. That statement is false. JWT were specifically designed to store a payload JSON object which among the many standardized fields include the token's expiry time, and JWT were specifically designed with a workflow which includes not only client-side token refreshing but also server-side token rejection that triggers client-side token r…

No, it's not false. Tutorial "best practice" guidance does not constitute a standard. JWT does not provide native revocation. Neither refreshes nor expiry constitute revocation. Revocation is an active state change, not a dead man's switch.

Re: Ask HN: What do you use for authentication and authorization?

#40

Post by geezerjay »

throwawaymath wrote: post #19
atonse wrote: post #9

Earlier quoted context omitted.

Isn't the argument against JWT mainly one against using it with weak algorithms, and not something inherent to JWT itself?

No, there are several common arguments against JWT for session tokens. The major one intrinsic to JWT is that it has no system of revocation. Thus instead of using a turnkey solution you need to add an additional layer of state logic to your authentication code if you want to be able to revoke tokens. It is also correct that JWT 1) supports far more cryptography than is necessary; and 2) supports weak cryptography. Y…

> No, there are several common arguments against JWT for session tokens. The major one intrinsic to JWT is that it has no system of revocation.

That's technically false. JWT features multiple systems of revocation, including the use of nonces. Token revocation also features prominently in JWT's basic workflow.

The key aspect is that there is no turnkey implementation, and thus projects need to roll their own implementation, which is frowned upon some developers.

Post reply on HN