Ask HN: What do you use for authentication and authorization? • Hacker News Board

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

#161

Post by throwawaymath » Thu, Dec 27, 2018, 4:53 PM UTC

jondubois wrote: post #66

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.

If you use a realtime transport like WebSockets, you could keep automatically re-issuing a fresh JWT with a very short (e.g. one minute) expiry every 50 seconds; just push them at an interval to authenticated clients. That way your banning mechanism would only have a one minute a delay. No need to revoke tokens; just let them expire. In such a system, a user would be logged out after one minute of closing the connect…

What you’ve described is a workflow that will technically work. But I’m weakly confident it’s still suboptimal for most use cases.

How will you deal with the usability problem introduced by expiring all sessions for users who are offline (closed tab, spotty internet connection, etc) for at least 50 seconds? It actually seems like you really should be wondering how to interpret users being offline temporarily.

You could just accept this as working as intended, but you don’t need to accept it if you just use normal session IDs. Is your application really so latency sensitive that it can’t tolerate a DB lookup? What is an example workflow in which users on a web or mobile application cannot be tolerably authenticated with standard DB lookups?

You can also use a refresh token, but this brings you back to the revocation problem, but with longer term tokens. Likewise, there is a material difference between millisecond revocation and sub-minute revocation. There are good reasons to care about sub-minute revocation.

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

#162

Post by geezerjay » Thu, Dec 27, 2018, 4:54 PM UTC

jondubois wrote: post #75

geezerjay wrote: post #50

Earlier quoted context omitted.

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

This kind of comment might make one wonder why not just use a sessionId to begin with but JWT in this case is still useful in a microservice arch because a token which has been revoked from one high security microservice may still be valid for lower security microservices: It gives each microservice the option of deciding what kind of security they need to provide... They may not need any revocation list; maybe the J…

> This kind of comment might make one wonder why not just use a sessionId to begin with

JWT and sessionIds are totally different beasts. JWT are used per request, are designed to expire and be refreshed, are specific to each individual endpoint and store authorization info in a specialized third party service.

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

#163

Post by throwawaymath » Thu, Dec 27, 2018, 4:55 PM UTC

jondubois wrote: post #132

groestl wrote: post #104

Earlier quoted context omitted.

With WebSockets, you also have just one lookup when opening the connection. No scalability issue here.

This is not accounting for reconnect scenarios. With sessionId, if the user loses the connection and reconnects, there will need to be another DB lookup to verify that the sessionId is valid. This is not the case with JWT. The validity of the JWT can be checked without any DB lookups. Also, this is a security consideration because a malicious user could intentionally send fake sessionIds to make us DoS our database.…

Why wouldn’t you rate limit connections? That is something you should be doing anyway, and it neatly resolves the denial of service problem.

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

#164

Post by lmm » Thu, Dec 27, 2018, 4:58 PM UTC

geezerjay wrote: post #160

lmm wrote: post #86

Earlier quoted context omitted.

The big objection to JWT is that it's a bearer token with no revocation support. If you're going to implement a bearer token with no revocation support, or a custom revocation implementation, anyway, then the criticisms of JWT apply just as much to the system you're building and you might as well just use JWT.

> The big objection to JWT is that it's a bearer token with no revocation support. That statement is not true. JWT do support revocation. In short, servers are free to reject any token, which triggers a token refresh on the client-side. Token revocation is even an intrinsic aspect of JWT as they suport issue and expiry timestamps, along with a nonce to avoid replay attacks. It seems some users have an axe to grind re…

> In short, servers are free to reject any token, which triggers a token refresh on the client-side.

Servers can of course implement whatever custom behaviour they desire, but the protocol itself (and common implementing libraries) does not have any direct support for revocation.

Furthermore, any revocation implementation will inherently have to compromise the statelessness that is JWT's most prominent selling point.

> Token revocation is even an intrinsic aspect of JWT as they suport issue and expiry timestamps, along with a nonce to avoid replay attacks.

JWT does indeed support expiry and nonces. But these are not the same thing as revocation.

> It seems some users have an axe to grind regarding the idea of having to keep track of some tokens that were poorly designed (i.e., absurdly long expiry dates without a nonce) but the solution quite obviously is to not misuse the technology. In the very least, if a developer feels compelled to use a broken bearer token scheme that does not expire tokens based on issue date then quite obviously he needs to keep a scratchpad database of blacklisted tokens to compensate for that design mistake.

Insults and "obviously"s are not a good way to convince people of your point of view.

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

#165

Post by [deleted] » Thu, Dec 27, 2018, 5:02 PM UTC

lmm wrote: post #85

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…

I'd argue that people who think they should be using caching are heavily discounting the consistency issues they will encounter (no doubt at the least convenient time), and may well end up reintroducing the same problem they're trying to solve. If you have revocable tokens accessed via an authentication lookup cache with a 5-minute expiry then you've spent a lot of time and engineering effort to have exactly the same…

[deleted]

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

#166

Post by geezerjay » Thu, Dec 27, 2018, 5:11 PM UTC

Aeolun wrote: post #154

icebraining wrote: post #96

Earlier quoted context omitted.

He suggests KISS: you can probably get away with plain old server-side auth, and if you really need client-side tokens, use something simple that just encrypts and signs them: https://news.ycombinator.com/item?id=13612941#13615634

> Something simple that just encrypts and signs them Like JWT? I feel like that argument goes around in circles.

> I feel like that argument goes around in circles.

I feel that the problem is that some users are talking about stuff they know nothing about, but still feel compelled to be very vocal and opinionated.

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

#167

Post by equasar » Thu, Dec 27, 2018, 5:20 PM UTC

nickjj wrote: post #98

I roll my own using well supported libraries for the languages I work with. These libraries handle the gory bits and pieces where it's easy to make mistakes. It's a split between using passwordless logins, or standard password authentication depending on who the target audience is. I would never in a million years ever think about using a service like auth0. It's not just a huge privacy issue but now a critical compo…

So... what are those libraries?

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

#168

Post by geezerjay » Thu, Dec 27, 2018, 5:20 PM UTC

tixocloud wrote: post #146

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…

What’s the difference between a Bearer Token and JWT? I thought they were related?

In essence, a JSON Web Token (JWT) is a bearer token. It's a particular implementation which has been specified and standardised.

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

#169

Post by ynniv » Thu, Dec 27, 2018, 5:20 PM UTC

jondubois wrote: post #132

groestl wrote: post #104

Earlier quoted context omitted.

With WebSockets, you also have just one lookup when opening the connection. No scalability issue here.

This is not accounting for reconnect scenarios. With sessionId, if the user loses the connection and reconnects, there will need to be another DB lookup to verify that the sessionId is valid. This is not the case with JWT. The validity of the JWT can be checked without any DB lookups. Also, this is a security consideration because a malicious user could intentionally send fake sessionIds to make us DoS our database.…

You can sign session ids to prevent DoS, and you can cache session ids to avoid database lookups, but you can't detect forged or stolen JWT tokens.

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

#170

Post by geezerjay » Thu, Dec 27, 2018, 5:26 PM UTC

moltar wrote: post #55

geezerjay wrote: post #53

Earlier quoted context omitted.

> By "intrinsic", I meant precisely that there is no JWT standard which admits native revocation. That's patently false. JWT's basic workflow features token refreshes, issue and expiration timestamps, and even nonces, and the backend workflow also supports arbitrary token rejections to trigger token refreshes. The only aspect of JWT's workflow that is left as an implementation detail is tracking revoked tokens. > JWT…

If you have to track revoked tokens you might as well track active sessions via a session ID.

> If you have to track revoked tokens you might as well track active sessions via a session ID.

No. Tracking revoked tokens is only necessary if for some reason a server wants to reject a valid token, and that's only required until the token expires.

The use of nonces to avoid replay attacks is also a widely established practice, thus we're not talking about extra infrastructure.

Tracking revoked tokens also doesn't take up any resources as tokens are designed to be short-lived.