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

[nates]

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

[arkadiyt]

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

[3]: https://en.wikipedia.org/wiki/JSON_Web_Token

[4]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

[Klathmon]

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

[aeleos]

Isn't JWT also a type of bearer token? Could you please provide some more detailed arguments about why JWT shouldn't be used other than linking its wikipedia article?

[atonse]

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)

[atonse]

Isn't the argument against JWT mainly one against using it with weak algorithms, and not something inherent to JWT itself?

[tixocloud]

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

[misiti3780]

correct me if i am wrong, but if your backend and front-end run on different ports and you are developing locally using chrome, you have to use CORS to make any non GET requests

[jammygit]

Does sameSite mean you don't need to worry about anti-csrf tokens, or does it just augment it?

[metafunctor]

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.

[xfitm3]

Where does Amazon’s sigv4 fall into play?

[vortegne]

Why not JWT?

[closeparen]

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

[noir_lord]

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.

[nates]

Makes sense. I am sure I misworded, and got turned around a bit. Much of the documentation with fhir talks about oidc. Which seems to be in place if you are doing much more sharing of your data. These things as you mention are probably beyond what is necessary initially and could be added at a further date. However using a service or an open source project that can allow to scale to that size is an interesting proposition.

[pg_bot]

I would echo a bunch of the comments in this thread. I am only posting this because I own a healthcare startup and your question put the fear of god in me. I would strongly advise that you build a different app if you do not already possess the knowledge required to do this. If you have the means hire a professional and you will be better off. You need to get this right from day 1 or people will get hurt, you will be fined into oblivion and/or possibly thrown in jail. There are also numerous other security concerns that you should be worried about since Auth is just the tip of the iceberg.

I will add the following details which are specific for healthcare companies and a bit of inside baseball. Typically people use an email address as the lookup field for a user account. Since email addresses are considered protected health information under HIPAA, I would highly suggest you use usernames instead (possibly auto generated to be safe). HITRUST includes some details about password rules for their certification process. No one will question you if you follow their rules (I think it's 12 characters minimum 1 Upper/Lower/Symbol/Number each). Use a banned password list, you can find one here[0]. You are going to want to set up some manner of 2 factor authentication (I would recommend U2F or TOTP) for all accounts with manual code backup. OAuth and OpenID are goddamn nightmares. You need to own and manage this process entirely by yourself.

[0]: https://haveibeenpwned.com/Passwords

[Deestan]

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.

[nothrabannosir]

I wanted to disagree; how did those professionals become pros? Learning by doing , most of them , after all.

Then I read the last paragraph of the question.

Please follow this guy’s advice. As someone whose medical data you might one day be handling: please get someone who does this well.

Imagine you (or a family member) ever end up sick; your medical data ends up on Pastebin, and the arstechnica article about it surfaces a forum post from the engineer responsible: “hey guys howto auth?”. Honestly: how would you feel?

[inersha]

Classic hacker news. Ask for technical advice, get called incompetent.

[marcosdumay]

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.

[fiatjaf]

How do you know what expert is worth hiring?

[watty]

Come on now, security isn't easy but it's not rocket science. If someone is competent enough to be developing applications they're certainly competent enough to do security correctly by researching first.

[throwawaymath]

Before writing any code you should seek to deeply understand the problem space of authentication and authorization. HIPAA compliance is primarily an authorization problem, not an authentication problem. That is: both are important, but the unique set of challenges within the scope of HIPAA have to do with authorization of read/write access to data, not authentication.

Authentication asserts identities. Authorization asserts capabilities. This shifts and compartmentalizes the problem somewhat. Almost all interactive applications need to support robust authentication, but most applications do not require the sophisticated authorization restrictions HIPAA demands.

Whatever it is you choose, you should:

1) Use a mature, reputable library;

2) Use a library which provides the simplest possible interfaces for solving your needs in the most turnkey manner;

3) Engage with a reputable consulting firm specializing in HIPAA compliance and application security.

I would also recommend reading through as much information about Aptible's architecture and design ethos as possible. They have done an excellent job of navigating this problem space.

[nickjj]

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 component of your app depends on a third party service. Also I know of a few sites who use it and the user experience is really bad. It seems like every other time I access a site that uses it, I have to goto a third party auth0 screen to re-enter my login details (which are already auto-filled out by the browser).

Your user authentication flow is a very unique aspect of your site and it's also one of the first things your users see.

You should have full control over it because if your user's first impression is a slow loading non-intuitive user auth system that bugs them to login every few days they're probably going to look for a competing service. I know I would.

[equasar]

So... what are those libraries?

[buro9]

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.

[scopendo]

How do you implement that cache invalidation, assuming a multiple app server environment? Is it something like a separate redis server?

[nzoschke]

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.

[bpicolo]

Dex is another OSS option:

https://github.com/dexidp/dex

[gregimba]

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?

[jbattle]

> The hackability of these is very attractive

Maybe not the best choice of phrasing

[konspence]

Since it's in the healthcare space, have you considered hiring a consulting team? Or at least a firm? What other Hacker News readers use for authentication is largely irrelevant since we don't usually work on HIPAA-compliant applications.

[reaperducer]

What other Hacker News readers use for authentication is largely irrelevant since we don't usually work on HIPAA-compliant applications.

I think this is a rather sweeping, and wrong, generalization.

Though the chattering masses on HN may not be HIPAA devs, that doesn't mean there aren't HIPAA devs here. I'm one of them.

Every time someone brings up an obscure topic on HN, there always seems to be a group of people who specialize in that topic that come out of the woodwork and have fascinating insights.

The largest number of commenters on HN seem to be Googlers, Facebookers, and one man bands. But there are plenty of, for example, Apple devs on HN. They just choose to keep the S/N ratio high.

[Dowwie]

It depends on what type of system you plan to support. If it's for a hospital setting featuring many different types of actors, roles, and constraints, this requires a greater level of sophistication.

Beware, authorization is an Alice in Wonderland rabbit hole where one may fall far deeper than one expected to.

A few years ago, I ported Apache Shiro from Java to Python, resulting in The Yosai Project: http://yosaiproject.github.io/yosai

It was a grueling but rewarding experience.

I honored Shiro in name and license, open sourcing everything and using Apache 2. I went even further than Shiro by adding two factor authentication workflow using totp and including starter modules for caching, data store, and integration with the web app I was using (pyramid).

If you choose to use python, or even just want something to learn from and reference, check out Yosai. I put a lot into this work to make it useful for others, entirely on my own.

I spoke with Tobias (podcast init) about the project some time ago: https://www.podcastinit.com/yosai-with-darin-gordon-episode-...

[spricket]

If someone else needs to use your API, please use OAuth/OIDC. I've seen countless hand-rolled (and insecure) authentication schemes. It's almost always a nightmare. If you plan on connecting this to multiple apps and partners, rolling your own will create a hellscape for everyone

If you use OAuth, anybody can connect using a standard library and "flow" across tons of languages. And you don't need to worry about screwing up the most security critical part of your API. It will save you countless headaches.

Some people bash OAuth because of JWT, but this overblown. Storing permissions in a token is the only sane way to do things if you end up with multiple services down the line (you will).

The whole revocation debate is a bunch of noise about nothing. Make the expiration interval fairly short, and if that isn't enough you can make a cache of revoked tokens that only needs to live as long as your expiration interval. This is still orders of magnitude more efficient than not storing permissions in the token and just as secure.

If you need to revoke all tokens in a breach scenario you just change your signing key. I recommend using SHA256 based signatures rather than public/private key since even though public/private is theoretically more secure, calculating signatures is quite a bit of overhead. If your backend is using a fast language like java/C#/Go, the majority of server CPU will be signing tokens.

Read about OAuth and ignore the haters. The design is well thought-out, secure, and efficient. If it was really that bad you wouldn't see most of the tech giants migrating to and using it. There's a lot of people that don't like it because they don't understand it well enough.

[aeleos]

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

[Bombthecat]

Why did you switched away from okta?

[InGodsName]

We use Lambda authorizers, how do you use cognito

[davismwfl]

I'd advocate against using third party services here. In general third party services and healthcare comes with a lot of hurdles and costs which you need to evaluate carefully. Even log data stored on a 3rd party server that might have some PII can be a violation of U.S. law unless they are a contracted BAA following all the same security and legal rules required of healthcare tech.

Overall just start with strong security in mind that will meet the U.S. healthcare security rules/laws, even if you aren't in the U.S., the basic principles are just focused around strong security. People can debate the specific methods, but I will argue using almost any third party service has potential problems for you with compliance. Yes, I agree and understand those services specialize around auth usually, and for most companies that is fine and even for some more fringe areas of healthcare that is fine. But take another viewpoint, that is because those companies secure so many disparate third parties their attack surface is huge compared to your own, and a vulnerability at their end may force you to do public disclosures. That alone isn't a sole reason not to use them, but do consider all the factors.

Also, in the U.S. you will likely (depending on specific type of product) need to deal with HIPAA and other similar acts (HITECH/TRUST etc). None of these are actually all that complicated if you take them into account early, although going back and adding them later can be a struggle.

Basic principles is secure everything, have timed (short interval) token expiration, have a global token expunge, and always err on the side of reauth over pass thru. Also, if you have many backend services, do not rely on a proxy authentication service to pass off requests. Force all services to validate the authentication of each request. Yes this is "expensive" in terms of extra cycles but it minimizes the risk considerably. Lastly, store trace and audit logs of everything you can imagine, all requests.

[eximius]

Edit: just read other comments pointing out the healthcare thing. Hire a professional.

Honestly, authentication is not that hard. There are many ways to do it, all with valid trade offs.

What you need to know is what your AUTHORIZATION story will be. Can anyone who can hit your API receive all data? Otherwise, you either need some kind of stateful access control or some kind of bearer token granting certain kinds of access. If the latter is simple enough for your use-case, then JWT, despite it's naysayers, might shine for you. Otherwise you can just use about anything since you'll be looking up what they can access in a DB anyway.

[vwpolo3]

The open source ory ecosystem ( http://github.com/ory/ ) might have what you're looking for, but it's definitely for advanced usecases. I know a lot of people that worked with Auth0/Okta/AWS Cognito but got so frustrated by downtimes, bugs, and complexity that they moved away. But it is an option for rapid prototyping although I'd keep a "replace it" somewhere in my milestone planning. Another possibility is Keycloak which is very enterprise / java fullstack and quite complex to understand.

Most advice in the comments is pretty bad though. Stuff like "API Clients need bearer tokens" is completely backwards and pushed by marketing people from companies (Auth0, Okta, ...) that misuse open protocols (OAuth2, OIDC) as a way to legitimize the closed source saas approach they took. Along the lines "if it looks complex it looks secure because most people have no idea". It's actually very easy to use cookies (httpOnly, secure) with API clients and you're saving yourself so much complexity with refreshing tokens and all that stuff.

Yet another possibility for super rapid prototyping is: https://github.com/bitly/oauth2_proxy

edit:// I forgot KeyCloak, but it's also for advanced enterprise use cases (SAML, OIDC, Realms, ...) and (from what I've heard) with a steep learning curve and heavy.

[bogomipz]

>" Stuff like "API Clients need bearer tokens" is completely backwards and pushed by marketing people from companies (Auth0, Okta, ...) that misuse open protocols (OAuth2, OIDC) as a way to legitimize the closed source saas approach they took."

Can you elaborate on how they "misuse" them? I don't have any familiarity with those two companies, generally curious. Thanks.

[bpicolo]

I think the distinction is that, if you intend to have a publicly accessible API, tokens are preferred vs cookies. For your own mobile clients, doesn't matter

[yellowapple]

"This product is going to need to be secure as it will be in the healthcare space (so think oidc)."

Considering most EMRs (or at least the ones with which I've interacted) don't go very far beyond a username/password combo, you're probably fine keeping things simple.

Generally, when in doubt, I'd strongly recommend using some existing auth library instead of trying to roll your own. It's not clear where exactly in the healthcare world your site will fit, but if you're aiming for hospitals, any hospital worth their salt is going to be using Active Directory or something similar, so you'll probably want to find something that can support offloading user identification in that direction (and fall back to username/password if the org doesn't yet have AD).

I don't know your specific jurisdiction, but at least in the US, as long as you're encrypting all your data (both at-rest and in-transit) and aren't doing anything egregiously stupid (plaintext passwords, single shared password for everyone, literally selling patient data on the Dark Web, etc.) you should have a pretty hard time violating HIPAA, and you'll already be on-par with most extant medical systems. Any further hardening on the authentication front (e.g. specific session management strategies) will just be icing on the security cake.

If you haven't already, I'd suggest reviewing NIST's guidelines for system security; most official HIPAA reference materials point toward NIST guidelines, and most hospitals will tend toward that direction as well.

[INTPenis]

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.

[mrweasel]

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

[shocked-pikachu]

I have been using JWT[1] since it's initial push as a mainstream authentication method. There's plenty of libraries that support it and make it easier to use[2]. There's even 0Auth[3] that is a company based around offering authentication services. Simply check for a valid token in the Authorization header, check out the introduction [4].

The library I've linked brings up a good point to make sure that you know the difference between decoding and verifying the token, but after that it's fairly plain sailing.

[1]: https://jwt.io [2]: https://github.com/auth0/node-jsonwebtoken [3]: https://auth0.com [4]: https://jwt.io/introduction/

[rodrigopetter]

We use a local version of UAA (https://docs.cloudfoundry.org/concepts/architecture/uaa.html) he behaves like a google or facebook authentication where the user concedes the permission to the apps using OAuth 2.0 protocol.

We have 10+ web clients, 2 mobile apps and one internet gateway. Spring Security make it very easy to integrate everything.

https://oauth.net/2/ Auth0 is the best documentation to learn about oauth: https://auth0.com/docs/protocols/oauth2

The best part of using Oauth is that you can change your authentication server (UAA, Auth0, etc) without changing your app code (only configurations)

[rwieruch]

If 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/