Live data from Hacker News

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

news.ycombinator.com

71–80 of 247 posts

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

#71

Earlier quoted context omitted.

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

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

Good luck using session cookies with Cordova on iOS, for example [1]. In cases like these JWT is perhaps your only option.

[1] https://issues.apache.org/jira/browse/CB-12074

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

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

> It's probably better than cookies.

Why do you think so? I would guess it's a tradeoff about what you think is more likely to happen. XSS or CSRF.

Local storage (and session storage) is vulnerable to XSS. Use a strict content security policy and escape (htmlspecialchars in php and similar functions in other languages) output to combat that.

Cookies are vulnerable to CSRF but can't be read from JS if they are http only (no XSS). To combat CSRF most frameworks already have built-in csrf token support. In case of a API use a double submit cookie. Frameworks like AngularJs/Angular support that out of the box. Also use the secure flag SameSite and __Host prefix [0][1]

[0] https://www.youtube.com/watch?v=2uvrGQEy8i4

[1] the slides from the video: https://www.owasp.org/images/3/32/David_Johansson-Double_Def...

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

#74
For authentication I use Auth0 on the free tier, with a passwordless setup that uses Google OAuth and Microsoft OAuth and allows fallback to emailing a code to a user. We store nothing more than the email address. The great thing about Auth0 is the separation it provides between the authentication layer and the web app, and how if you go down the SaaS route you can allow people to bring their own Auth0 accounts and configure their own bespoke authentication.

For authorization you are going to have to implement your own solution once you have an authenticated session. What someone can do always depends on your app and the functions you provide and so there is no nice third party solution to this. In my case I store the map of users to roles and what a role can do in a PostgreSQL app and cache there the answers to "which users are in a role" and "what can a role do"... user permission and roles changes are infrequent but flush the cache and so take immediate effect.

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

#75

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.

> 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 JWT on its own is sufficient; they just keep accepting the token until it expires naturally.

The token expiry determines the baseline accuracy of banning across all services.

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

#76
post #11
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…

Also (separate post for separate replies), why not use CORS? this is the first I'm hearing about this. SPA websites often use things like JWT and CORS (ours included)

Some people have performance concerns with CORS is the main reason I believe. The overhead is an extra round trip.

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

#77

If your plan is to connect other services then I'd suggest using LDAP for central authentication. It can easily be connected to any API without much "glue". And most common open source services already support it as auth backend. It's also easier to audit than any custom service you might concoct on your own because auditors already have experience with it through Active Directory.

LDAP is really overlooked by many and I think people are surprised by the amount of software that offers LDAP support.

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

#78
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…

You don't need JWT in this case. You can use a normal token with short expiry and some mechanism to keep it fresh as long as the user doesn't exit the application.

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

#79
post #42

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.

It's not called two factor authentication. Two factor authentication is when you have two factors for authentication. This is just one..
Post reply on HN