Roll my own. Passwords are stored as bcrypt hashes. Just use plain old cookies to store session IDs.
What about localstorage for storing a token instead of a cookie?
What benefit would that have over a cookie? (Honest question)
Ask HN: What do you use for authentication and authorization?
221–230 of 247 posts
Re: Ask HN: What do you use for authentication and authorization?
#222Why do all API development tutorials always say "Never roll out your own custom auth"? I always found it weird
What they said.. - Your authentication problems are not unique to you; - The effort of implementing standards (whether it's front end like OAuth, OIDC, or SAML or back end like hashing) is a pain in the butt and easy to make bad choices; - If your project is successful or as your requirements change over time, now you have to figure out how to add MFA, password resets, internationalization, address security audits, e…
Hey man, funny thing, I just completed your 3 courses on Lynda.com on the REST API learning path yesterday. I did the Design one, the Validation and Authentication one and the OAuth/OpenID one.
Good stuff.
Also, I have a question for you, is there a good place to reach you?
Re: Ask HN: What do you use for authentication and authorization?
#223Earlier quoted context omitted.
Some people have performance concerns with CORS is the main reason I believe. The overhead is an extra round trip.
I thought the concern was security. Anyway HTTP2 would hopefully address that (through header compression), and things like zero-RTT TLS and keep-alive further minimize the overhead of an additional request. Plus doesn't CORS only make preflight requests periodically, not for every request?
I wrote/research a lot about http/2, and even has a small tool for it (https://http2.pro).
Among many things you get from http/2, it cannot eliminate round trip time. Sure, you can keep a connection alive but that's possible with http 1.1 too.
Header compression is HPACK. If the header changes even the slightest bit, it's not cached. Dynamic URLs and headers can easily bust HPACK compression.
Re: Ask HN: What do you use for authentication and authorization?
#224Hard 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…
Does sameSite mean you don't need to worry about anti-csrf tokens, or does it just augment it?
SameSite cookies can eliminate threats from cross domain requests. The strict mode is good enough to even block cross domain regular GET requests too.
However, I wouldn't throw other anti-CSRF measures away because if the attacker can use a stored XSS vuln, they can still make their way to a CSRF as well. Besides that, not all browsers support SameSite flag yet.
Re: Ask HN: What do you use for authentication and authorization?
#225I'm using Keycloak for authentication and Vert.x for aauthorization besides the main use case.
Re: Ask HN: What do you use for authentication and authorization?
#226Using anything other than your own libs for your specific needs probably will lead to over engineering.
Re: Ask HN: What do you use for authentication and authorization?
#227If I do a MVP with React.js, my go to solution is Firebase. [0] Authorization is possible as well. [1] If I need to scale this MVP, I would eventually migrate to a self-hosted backend solution. In my case, it would be Node.js with a GraphQL interface that enables authentication with JWT [2]. Alternatives could be Passport.js and Auth0.
- [0] https://www.robinwieruch.de/complete-firebase-authentication...
- [1] https://www.robinwieruch.de/react-firebase-authorization-rol...
- [2] https://www.robinwieruch.de/graphql-apollo-server-tutorial/
Re: Ask HN: What do you use for authentication and authorization?
#228Earlier quoted context omitted.
How is that better than a cookie though? Cookies already provide automatic storage and expiry mechanism. Bonus feature is that they are not accessible by JS code at all, if set httponly flag.
Browsers automatically attach cookies to HTTP requests, opening the door to attacks like CSRF. The security impact of automatic client-side expiry is tiny, since token expiration must be done server-side anyway. The HttpOnly flag as an XSS mitigation is almost useless; competent attackers will simply run their code from the victim's browser and session. To protect against XSS, HttpOnly doesn't really help you at all.…
> competent attackers will simply run their code from the victim's browser and session
What do you mean? JS even on the same page can't read HTTPOnly cookies. If you are assuming that the browser has been hacked then it is pretty much game over regardless of what you use.
Re: Ask HN: What do you use for authentication and authorization?
#229Earlier quoted context omitted.
I've had an idea for a product I've put on hold for two years because it involves medical data and I just don't know if I can secure it to a level I'd be happy with from a moral point of view. That's before the law gets involved as well.
Yeah... HIPAA is definitely tough. I'd check out https://www.aptible.com if you haven't already. It will at least help out with the infrastructure side of things. Although it does seem like Heroku is offering some services that help too ( https://blog.heroku.com/announcing-heroku-shield ). It's definitely not enough alone, but at least gets you going on the security & compliance aspects.
I'm in the UK and our rules are different, we don't have anything directly equivalent to HIPAA (I suspect because we don't currently have the huge number of private hospitals/doctors the US has) in fact even finding out the exact standards you'd have to comply with for the UK is a challenge.
GDPR is good in that regard as the standards are high and apply to more than just electronic storage/interchange.
Re: Ask HN: What do you use for authentication and authorization?
#230Earlier quoted context omitted.
Yeah... HIPAA is definitely tough. I'd check out https://www.aptible.com if you haven't already. It will at least help out with the infrastructure side of things. Although it does seem like Heroku is offering some services that help too ( https://blog.heroku.com/announcing-heroku-shield ). It's definitely not enough alone, but at least gets you going on the security & compliance aspects.
I'm in the UK and our rules are different, we don't have anything directly equivalent to HIPAA (I suspect because we don't currently have the huge number of private hospitals/doctors the US has) in fact even finding out the exact standards you'd have to comply with for the UK is a challenge. GDPR is good in that regard as the standards are high and apply to more than just electronic storage/interchange.
People have to follow the Data Protection Act.
Are these useful?
Here's the Code of Practice for NHS organisations and staff: https://www.gov.uk/government/publications/confidentiality-n...
Here's the other code of practice for everyone working with NHS data: https://digital.nhs.uk/data-and-information/looking-after-in...
And here's the guidance about when to share if it's needed: https://digital.nhs.uk/data-and-information/looking-after-in...