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

41–50 of 247 posts

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

#41

Post by beokop »

metafunctor wrote: post #36
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.

This sounds an awful lot like JWT.

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

#42

Post by yolo1 »

mattbgates wrote: post #35

Email or text message sent to customer and they just input the number they were sent to match.

This is called two factor auth. SMS is not considered a secure method of transport (mostly due to porting). It only solves opportunistic password compromise via password dumps.

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

#43

Post by shocked-pikachu »

I have been using JWT[1] since it's initial push as a mainstream authentication method. There's plenty of libraries that support it and make it easier to use[2]. There's even 0Auth[3] that is a company based around offering authentication services. Simply check for a valid token in the Authorization header, check out the introduction [4].

The library I've linked brings up a good point to make sure that you know the difference between decoding and verifying the token, but after that it's fairly plain sailing.

[1]: https://jwt.io [2]: https://github.com/auth0/node-jsonwebtoken [3]: https://auth0.com [4]: https://jwt.io/introduction/

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

#44

Post by kokokokoko »

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…

Revoking a bearer token is trivial and in all likelihood, revoking tokens is a very infrequent event. In most cases it is such a rare event that you can usually commit your blacklist to source code.

If not a service to validate tokens against a blacklist is again trivial and will scale to all but the top 0.1% of organizations. And it only needs to be in the blacklist long enough for the period until the token expires.

Yes, jwt is not ideal. But this talk that you should never ever use them and your service will be immediately hacked etc is silly internet bandwagoning.

For a huge percentage of services jwts are just fine. Anyone reading this, please do not over think this advice and just ship with jwts if that is what you have.

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

#45

Post by geezerjay »

throwawaymath wrote: post #39
geezerjay wrote: post #33

Earlier quoted context omitted.

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

Yes, that's patently false.

The exp payload field is even specified in JWT's RFC along with the token rejection workflow.

https://tools.ietf.org/html/rfc7519

The same document also specifies the jti field which is the JWT's nonce.

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

#46

Post by cbo100 »

beokop wrote: post #41
metafunctor wrote: post #36

Earlier quoted context omitted.

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.

This sounds an awful lot like JWT.

In what way?

You simply get a bearer token (non JWT) onto the client and use that from local storage instead of a cookie.

Your JavaScript code then makes api calls using the same bearer pathway as other api clients.

The token can still expire, be revoked, etc. it just prevents you having to handle cookie auth on your api.

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

#47

Post by geezerjay »

cbo100 wrote: post #46
beokop wrote: post #41

Earlier quoted context omitted.

This sounds an awful lot like JWT.

In what way? You simply get a bearer token (non JWT) onto the client and use that from local storage instead of a cookie. Your JavaScript code then makes api calls using the same bearer pathway as other api clients. The token can still expire, be revoked, etc. it just prevents you having to handle cookie auth on your api.

You've just described the JWT workflow.

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

#48

Post by throwawaymath »

geezerjay wrote: post #40
throwawaymath wrote: post #19

Earlier quoted context omitted.

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 implemen…

By "intrinsic", I meant precisely that there is no JWT standard which admits native revocation. It naturally follows that no JWT implementation provides a turnkey solution for revocation, because it's not intended to.

JWT is stateless. Revocation is stateful. This is a fundamental tension in both cryptography and access control. Yes, you can retrofit your stateless authentication system with a stateful revocation system. But at that point you're back to square one and the architect working on this should consider why they're undoing the legitimate benefits JWT provides.

Nonce based revocation is an active process. Timestamp expiry is not actually revocation, it's expiry. If your token is compromised prior to expiry, you're out of luck.

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

#49

Post by throwawaymath »

kokokokoko wrote: post #44
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…

Revoking a bearer token is trivial and in all likelihood, revoking tokens is a very infrequent event. In most cases it is such a rare event that you can usually commit your blacklist to source code. If not a service to validate tokens against a blacklist is again trivial and will scale to all but the top 0.1% of organizations. And it only needs to be in the blacklist long enough for the period until the token expires…

> Yes, jwt is not ideal. But this talk that you should never ever use them and your service will be immediately hacked etc is silly internet bandwagoning.

I never said you should never ever use JWT or that your service will be hacked if you do so. In fact, if you kindly reread what I wrote you'll see that I explicitly mentioned there are legitimate use cases for JWT. I am specifically refuting the use of JWT as an authenticated session management system.

> Anyone reading this, please do not over think this advice and just ship with jwts if that is what you have.

This is poor advice.

1) Authentication is sufficiently solved for most workflows and applications that you can use turnkey solutions for more secure and more performant authentication than JWT.

2) What exactly is the scenario you envision in which JWT is all someone has? Do you mean they're forced to use stateless session management, or that JWT is literally all they can do for authentication because nothing else is available?

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

#50

Post by geezerjay »

CorvusCrypto wrote: post #25
mcbits wrote: post #18

Earlier quoted context omitted.

JWT is fine if "revoke" isn't in your vocabulary for the service. If you do need to revoke tokens, JWT becomes a racey contraption that requires synchronizing and looking up state on every request, the avoidance of which was the main reason to use JWT in the first place.

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.

> You can still revoke JWTs if you give them an ID and keep a revoke list somewhere.

You don't need the ID. You can simply store the token's signature. In fact, some implementations store the whole JWT to avoid roundtrips to the auth service, and revoking the token is just a matter of flipping an attribute in the database.

Post reply on HN