I am currently starting work on a new app/website. Currently planning to have 1 BE API set to start, probably graphql (which will be user data/information and need to check with the auth server about being protected). I will also have many client apps (web, mobile, potential partners) that will need to make queries to that BE. Do you usually roll your own authentication or use something like auth0/fusionauth/gluu/etc? This product is going to need to be secure as it will be in the healthcare space (so think oidc).
Ask HN: What do you use for authentication and authorization?
1–10 of 247 posts
Re: Ask HN: What do you use for authentication and authorization?
#2Okta.
Re: Ask HN: What do you use for authentication and authorization?
#3[deleted]
Re: Ask HN: What do you use for authentication and authorization?
#4Hard 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 port 80 revoke that token).
- If you go with OpenID/Oauth for client sign-ins then require https callbacks and provide scoped permissions.
- Don't use JWT [3]. Don't use CORS [4].
Again these are broad strokes - if you gave more information you'd get a better response.
[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Se...
[2]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/St...
Re: Ask HN: What do you use for authentication and authorization?
#5Devise, if you’re building a Rails app.
Re: Ask HN: What do you use for authentication and authorization?
#6Roll my own. Passwords are stored as bcrypt hashes. Just use plain old cookies to store session IDs.
Re: Ask HN: What do you use for authentication and authorization?
#7Healthcare is a dangerous sector for a security novice. Please make sure you are familiar with HIPAA [0], including your obligations when handling health information and the nature of possible sanctions. Handling health data at all is risky. Sharing it with partners is something you probably shouldn't even consider before you can afford a serious legal team.
OpenID is a mechanism for one website to assert a user's identity to another website. OAuth is a way to let a user delegate access to some of their data on one site to another site. Neither have any particular affinity with the healthcare space, and they are not things you sprinkle on for extra security.
[0] https://www.hhs.gov/hipaa/for-professionals/security/index.h...
Re: Ask HN: What do you use for authentication and authorization?
#8I was in a similar position, we started using Okta and eventually migrated to AWS Cognito. Rolling your own auth is a recipe for disaster unless you know what you are doing and really need to. Also, be prepared to be fairly locked in once you choose an auth provider, especially if you choose one that is fairly integrated into your ecosystem.
Re: Ask HN: What do you use for authentication and authorization?
#9Hard 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…
Isn't the argument against JWT mainly one against using it with weak algorithms, and not something inherent to JWT itself?
Re: Ask HN: What do you use for authentication and authorization?
#10Hard 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…
Why not JWT?