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

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

#181

Post by nickjj » Thu, Dec 27, 2018, 6:20 PM UTC

equasar wrote: post #167

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?

That depends on what language / framework you use.

With Flask I use Flask-Login. For Rails I still use Devise usually and with Phoenix I just use Plug.Session directly.

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

#182

Post by nine_k » Thu, Dec 27, 2018, 6: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?

JWT in particular uses cryptography to encode a timestamp and some other parameters. This way, you can check if it's valid by just decrypting it, without hitting a DB.

Not all bearer tokens have this property.

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

#183

Post by nine_k » Thu, Dec 27, 2018, 6:22 PM UTC

I wonder why macaroons [1] are not even mentioned in this discussion yet.

They have all the upsides of cookies, but also can be narrowed down to be handed to third parties (good for APIs), caveats, and have a standardized and implemented [2] verification scheme.

I wonder why they don't see wider use. Do they have significant downsides?

[1]: http://hackingdistributed.com/2014/05/16/macaroons-are-bette...

[2]: https://github.com/rescrv/libmacaroons

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

#184

Post by gregimba » Thu, Dec 27, 2018, 6:28 PM UTC

nzoschke wrote: post #110

Ory Hydra https://github.com/ory/hydra Open source OAuth / OpenID connect server The docs, API and Docker images make it really easy to start developing against. Then the Docker images and database migration tools make it easy to deploy into our production infrastructure. Also evaluating the other Ory tools like Keto, a policy engine. The hackability of these is very attractive over closed services like Auth0.

I'm currently building an internal Authentication service with Hydra. I have some questions about its use in production do you mind if I send you an email?

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

#185

Post by marcosdumay » Thu, Dec 27, 2018, 6:36 PM UTC

Deestan wrote: post #90

Professionals. Hire an expert. If you can't answer these questions yourself (which is fine - it's specialized knowledge separate from the skillset needed for building a useful application), you are lacking critical competence for coding anything handling health information. The security minefield is much much bigger than the login page.

I would say you are assuming a bit too much (but just a bit).

There isn't enough information on the question to tell wether the OP is a complete novice with no idea of the minefield he is getting it, or if he is somebody competent that wants a list of current practices to start further research.

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

#186

Post by metafunctor » Thu, Dec 27, 2018, 6:52 PM UTC

beokop wrote: post #105

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.

Also, people make a big stink when authentication cookies aren’t marked as HTTPONLY. Storing tokens in localstorage (even sessionstorage) is just as bad but for some reason more accepted.

Stealing tokens from localstorage or cookies means the attacker can run code in the user's security context. Why would they limit themselves to stealing tokens? Using them outside of the browser would be stupid, anyway, as it would risk tripping reauthentication, IPS, or whatever.

HttpOnly is a joke, and people should stop claiming it helps with XSS. It does not help. It's security benefit is at most neutral. In fact, people often seem to think that it prevents XSS, and get lulled into a false sense of security. For that reason, HttpOnly seems to be worse than neutral.

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

#187

Post by felipelemos » Thu, Dec 27, 2018, 7:04 PM UTC

throwawaymath wrote: post #152

atonse wrote: post #11

Earlier quoted context omitted.

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)

The author hasn’t clarified yet, but I suspect what they’re referring to is the fact that CORS does not support granular access control. If you make something public under CORS, any client can retrieve the resource if no other authorization or authentication check is in place. It’s not a system of authentication, it’s a system of authorization - specifically, for authorizing hosts to request resources which normally…

CORS is not a tool to turn resources private, but to protect the browser (not the server's content) from cross domain requests.

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

#188

Post by i_cant_speel » Thu, Dec 27, 2018, 7:05 PM UTC

Klathmon wrote: post #137

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 someone makes a request over port 80 revoke that token I really like this trick! Not only do you now have a log of "shady stuff" happening, but you've gotten rid of the now compromised tokens instantly!

Can you elaborate on what this means? I'm not too familiar with authentication flows. Why would someone make a request over port 80? Why is that bad?

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

#189

Post by jammygit » Thu, Dec 27, 2018, 7:06 PM UTC

I'm using a selfmade system atm as as excuse to learn the subject for a MEAN app, but I would use OKTA or some similar service if I was 'playing for keeps.' Just boring client side sessions using Mozilla's client-sessions library with bcrypt for passwords.

I'm finding it hard to get information above the 'follow these steps to use this library' level, yet beneath 'here's how to make a cryptosystem from scratch'. I'm about to read some RFCs unless I find a better intro resource.

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

#190

Post by huntertwo » Thu, Dec 27, 2018, 7:10 PM UTC

i_cant_speel wrote: post #188

Klathmon wrote: post #137

Earlier quoted context omitted.

> if someone makes a request over port 80 revoke that token I really like this trick! Not only do you now have a log of "shady stuff" happening, but you've gotten rid of the now compromised tokens instantly!

Can you elaborate on what this means? I'm not too familiar with authentication flows. Why would someone make a request over port 80? Why is that bad?

Requests sent to port 80 will (usually) be unencrypted HTTP traffic, hence revealing the secret token to anybody listening in between the client and the server. Someone may accidentally send an HTTP request either by typo or lack of knowledge.