
Ask HN: What do you use for authentication and authorization? - nates
I am currently starting work on a new app&#x2F;website. Currently planning to have 1 BE API set to start, probably graphql (which will be user data&#x2F;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&#x2F;fusionauth&#x2F;gluu&#x2F;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...](https://developer.mozilla.org/en-
US/docs/Web/HTTP/Headers/Set-Cookie)

[2]: [https://developer.mozilla.org/en-
US/docs/Web/HTTP/Headers/St...](https://developer.mozilla.org/en-
US/docs/Web/HTTP/Headers/Strict-Transport-Security)

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

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

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

~~~
beckler
A bit of misinformation in this side thread.

A JWT token is composed of three parts: a header, payload, and signature.

The problem is that people can put sensitive info in the payload.

None of it is encrypted, it's only signed with HMAC.

Unless you're keeping track of the tokens, once a token is issued it's valid
until it expires, due to it's stateless nature.

You can use a JWT as a Bearer token, but since it's only base64 encoded, you
can pull out that payload data.

A truly opaque Bearer token will be meaningless to anything other than your
server.

Play with the debugger here to see what I'm talking about:
[https://jwt.io/](https://jwt.io/)

------
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...](https://www.hhs.gov/hipaa/for-
professionals/security/index.html)

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

~~~
aeleos
If you are handling any kind of medical data about people, then you cannot
think about security at a future date and your life will be difficult from the
start.

~~~
nates
Did I say security? I said sharing at a future date.

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

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

~~~
eximius
If they asked a bunch of doctors how anesthesia worked, they were just about
to go perform surgery at home, you'd expect the doctors to warn that it was a
bad idea, no?

~~~
inersha
I suppose there may be a distinction between asking "how does anaesthesia
work?" and "should I perform surgery at home?".

~~~
nothrabannosir
"A is to B as X is to Y", compares A and X, not A and B. It puts A in the
context of B, as X is in the context of Y.

the comparison is between "how does anaesthesia work?" (A) and "how does auth
work?" (X), relative to "about to perform surgery at home" (B) and "about to
implement a service containing medical information" (Y).

The point is: he's about to do something big, and is asking a basic question.
The real problem is not the basic question (auth) but the context he's doing
it in.

If a nurse in training, in a classroom setting, asked about anaesthesia, it'd
be fine. If they're a doctor, about to operate on a live patient, it's
different.

~~~
inersha
I like the analogy in your final paragraph. I see hacker news as the nurse in
the classroom setting.

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

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

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

~~~
Dowwie
Yes, exactly: you use a fast data store such as redis or memcached.

As a user performs activities, this may involve a scenario requiring
escalation or revocation of authorization roles and corresponding permissions.
Invalidate cache at this moment. Lazy cache updated authorization info upon
next request.

(I authored Yosai)

------
nzoschke
Ory Hydra

[https://github.com/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](https://github.com/dexidp/dex)

------
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](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-...](https://www.podcastinit.com/yosai-with-darin-gordon-episode-120/)

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

~~~
InGodsName
We use Lambda authorizers, how do you use cognito

~~~
nostrebored
You can create a custom auth flow using lambda and cognito; you can return a
series of challenges and create a stateful flow using session tokens which
results in a set of access, identity, and refresh tokens.

Alternatively you can use the auth code flow baked into lambda; if you have
premium support make a case and someone can walk you through it :)

------
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/](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](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.

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

~~~
bogomipz
Why are tokens preferred over cookies for a publicly accessible API?

~~~
bpicolo
There are all sorts of cases where managing cookies is annoying when
interacting with an API, like via curl. There might be other reasons as well,
but making consumption easy is probably reason enough

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

~~~
baq
i've stopped being surprised a few years ago that it's usually in the 'call
us' price tier :)

------
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](https://jwt.io) [2]: [https://github.com/auth0/node-
jsonwebtoken](https://github.com/auth0/node-jsonwebtoken) [3]:
[https://auth0.com](https://auth0.com) [4]:
[https://jwt.io/introduction/](https://jwt.io/introduction/)

------
rodrigopetter
We use a local version of UAA
([https://docs.cloudfoundry.org/concepts/architecture/uaa.html](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/](https://oauth.net/2/) Auth0 is the best documentation
to learn about oauth:
[https://auth0.com/docs/protocols/oauth2](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...](https://www.robinwieruch.de/complete-firebase-
authentication-react-tutorial/)

\- [1] [https://www.robinwieruch.de/react-firebase-authorization-
rol...](https://www.robinwieruch.de/react-firebase-authorization-roles-
permissions/)

\- [2] [https://www.robinwieruch.de/graphql-apollo-server-
tutorial/](https://www.robinwieruch.de/graphql-apollo-server-tutorial/)

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

------
verdverm
Check out [https://github.com/sysgears/apollo-universal-starter-
kit](https://github.com/sysgears/apollo-universal-starter-kit)

Fullstack JS, Apollo GraphQL, numerous client types, batteries included. Has
auth implemented plus a number of other things you will find useful in the
graphql world.

If you are in healthcare, you may want to find an auth system like DEX that
can talk to several backends like LDAP & Active Directory, as each hospital or
institution will likely want to reuse what they currently have implemented.
You'll need to hook into them. (This is on our roadmap)

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

------
sebslomski
All new apps I’m building are based on password-less auth [1] & bearer token.
NoPassword is just so much more comfortable than having to remember passwords.
And boy, people are really bad at coming up with passwords - you might have
seen it this Christmas at your parents’. [1]
[http://notes.xoxco.com/post/27999787765/is-it-time-for-
passw...](http://notes.xoxco.com/post/27999787765/is-it-time-for-password-
less-login)

~~~
auiya
This works only on devices for which you simultaneously have email access. For
instance Netflix on a home gaming console would fail miserably using this
schema. See also [https://www.troyhunt.com/heres-why-insert-thing-here-is-
not-...](https://www.troyhunt.com/heres-why-insert-thing-here-is-not-a-
password-killer/)

------
writepub
Truth about side-projects is most never get to the finish line. I'd like to
encourage you to get there, and for that, you'll need to use a third party for
auth, at least till you finish your API and seek feedback/scale. You can
always roll your own after you've validated the viability of your API.

You can choose firebase or AWS Cognito. They offer readymade sever and client
SDKs for a wide variety of targets. Firebase is always free, and AWS free for
50,000 users

They offer authorization based on roles

------
blhack
Roll my own. Passwords are stored as bcrypt hashes. Just use plain old cookies
to store session IDs.

~~~
equasar
What about localstorage for storing a token instead of a cookie?

~~~
tnr23
what about caring about things that matter?

------
throwawaypls
Devise, if you’re building a Rails app.

------
chirau
Why do all API development tutorials always say "Never roll out your own
custom auth"? I always found it weird

~~~
caseysoftware
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, etc, etc.

Doing it yourself means you have 100% responsibility for everything when that
is probably not your main skillset or really what you want to spend your time
doing anyway.

 _Disclosure: I work for one of the companies mentioned in this thread._

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

~~~
caseysoftware
Thanks and great to hear. My email is in my profile. Feel free to drop me a
note.

------
victorNicollet
We use SAML set up for our customers' identity providers (most of the time,
Office365 Azure AD or Google Suite), from a NuGet package.

From there, it's a bearer token encoded in JWT format for ease of debugging.
From another NuGet.

We also support username and public key authentication for our SFTP server.

We do support username and password if necessary.

~~~
baq
and what do you use for authorization?

~~~
victorNicollet
Custom rules on top of ASP.NET middleware.

------
IloveHN84
We use Truedentity ([https://www.truedentity.de](https://www.truedentity.de))
which is pretty robust with smartcard and palm vein pattern to make access
secure. It uses EJBCA as backend for PKI and it's possible to configure
redundancy with it.

------
fiatjaf
Ignoring the body of your question and answering just the title, I'm
developing [https://accountd.xyz/](https://accountd.xyz/) as a system for
mixing and linking identities (email, twitter, github, trello, indieauth for
now) and using that for [https://trackingco.de/](https://trackingco.de/),
[https://listhub.xyz/](https://listhub.xyz/) and
[https://sitios.xyz/](https://sitios.xyz/).

In theory anyone can use it, it works automatically and you don't have to
register or anything like that, but I don't know if people are interested in
it.

------
nine_k
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...](http://hackingdistributed.com/2014/05/16/macaroons-are-better-than-
cookies/)

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

~~~
Boulth
Macaroons have their own issues, see my previous comment here:
[https://news.ycombinator.com/item?id=17879403](https://news.ycombinator.com/item?id=17879403)

If you've got questions about them I'm happy to answer.

------
fma
I'm mostly a backend developer (batch processing, systems integration etc) and
it still amazes me there's no turney solution for different languages. I work
in a large enterprise so we hook into our SSO for any kind of Auth for our web
apps, though I haven't personally had to deal with this since my college days.
If I remmebr.NET had something out of the box.

Anyways, when I dabbled a few years back, I uses stormpath but they closed
down. Les Hazelwood, the creator or Apache Shiro works at Okta now... Which
seems to provide enterprise security.

Can anyone comment on their experience with Shiro, or Okta in general, and if
it would help OP.

------
exabrial
U2F + a password or biometric.

What I wish is Apple and co would give the consumer choices. I am a low threat
target; I don't need to enter a pw to unlock the SIP. So presenting a
fingerprint + a hardware key would be a huge security improvement and a
reasonable defense against 99.9999999% of the threats I face. Unfortunately,
Apple assumes we're all being targeting by physical attacks from the NSA,
decreasing my convenience level for a non-existant threat.

------
based2
[https://www.apereo.org/projects/cas](https://www.apereo.org/projects/cas)

[https://www.freeipa.org/page/Main_Page](https://www.freeipa.org/page/Main_Page)

[https://www.rcdevs.com/](https://www.rcdevs.com/)

------
somada141
I'm in the same boat (SaaS app in the health sector) and opted for Auth0 after
using it a fair bit in the finance sector with work. I'd say start with that
and once your app outgrows it then you can roll out a solution of your own but
I'd suggest you don't try to reinvent that particular wheel when you're
starting out.

------
sidcool
Auth0 for authentication, custom authorization.

------
ai_ia
I use meteor and graphql with accounts package and Alan's: roles packagr. It's
pretty easy using meteor.

------
arnonejoe
We did the bakeoff and AWS Cognito is the by far the cheapest. It's not as
well documented but supports Open Id Connect just like all the other 3rd party
auth solutions. The downside is that Cognito does not support a Resource Owner
Password Flow (not recommended anyhow. see RFC6749).

------
CSMastermind
Echoing the others telling you to hire a professional. If you have the money
Okta has a professional services division that will set everything up for you.
Use them. If you don't have the money us Auth.0. Don't try to handroll
everything you will regret it.

------
dagoat
If you have the budget for it just use auth0 or similar. You will likely spend
less time wiring it up than coming up with a solution yourself.

Going off your question only, this will also likely end up being the most
secure implementation for you (relying on a third party service)

------
BillinghamJ
> healthcare

> OIDC

Nooope. Not a good idea. OIDC is pretty damn complicated to implement as a
server. And it doesn't help at all with anything around revocation etc. To
make that possible, you have to add a load of extra work and you basically
lose most of the benefits of using JWTs.

First, as others have said, if you don't know what you're doing on this, you
have no business trying to secure health data. Bring in someone who does know
what they're doing and then pentest it aggressively.

Second, I'd suggest you'd be better keeping it super simple. Just have a token
in a table, refer to the token by its ID and then attach a 32 byte crypto
random to it which gets checked before the existence of the token is
acknowledged. Compare it with constant timing. If you don't know what that is,
again, you shouldn't be doing it with health data - best to learn on a project
with less sensitive info.

------
21stio
imho github.com/casbin/casbin is the go to solution when it comes to
authorization, it supports ACL, RBAC, ABAC, it's optimized for performance,
it's pretty language agnostic, backed by tencent

------
floriferous
You can use meteor’s healthcare track, specifically designed for healthcare
apps: [http://clinical.meteorapp.com](http://clinical.meteorapp.com)

------
isostatic
All our users have client certs, so using then makes sense to me.

------
vishalsharma
I have heard of keycloak , open source auth platform

any reviews ?

~~~
sphix0r
Currently integrating Keycloak as auth service for multiple existing projects.
It's very advanced, many use cases and configurations are possible. We are in
the middle of the migration but so far it hasn't been hard to integrate.

It's a rather large dependency so I won't recommend it for a single project
with straight forward auth requirements.

------
sfuller
There are seriously dangerous attitudes in this thread regarding what
constitutes token invalidation. Hire someone skilled at secure auth
architecture. You should have at least 2-3 senior engineers who are very well
versed in this if this company is serious about doing anything related to
protected patient healthcare data. One person's opinion should never end up
being the only input for super critical decisions like you are trying to make.

------
ramijames
Well, we build and use Scatter ([http://get-scatter.com](http://get-
scatter.com)), which is both a desktop app and a JS and C# library. This
allows you to use the EOS or Tron blockchains and their account systems. Our
users have local access to remote accounts on those networks. It's pretty
amazing software, and it is really fun building something totally new.

------
rodmena
Using anything other than your own libs for your specific needs probably will
lead to over engineering.

------
lichtenberger
I'm using Keycloak for authentication and Vert.x for aauthorization besides
the main use case.

------
jiveturkey
in the healthcare space really helps. great detail for this question.
honestly, not many people are good at asking questions.

you need an expert, someone that doesn’t need to ask this question.

------
reilly3000
Okta.

------
mattbgates
Email or text message sent to customer and they just input the number they
were sent to match.

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

~~~
weego
In reality it solves far more than that for the average system for the average
user. No on in reality is having their mobile number socially engineered to
get into startup xs system. It's a good place to start until you are at a
scale where you would have dedicated security engineers to work on the
problem.

~~~
techsupporter
> No on in reality is having their mobile number socially engineered to get
> into startup xs system.

The problem is that you can't know whether that's the case at start, at some
point in the future, or never. You'll only find out that your guess was wrong
when you're breached which is never a good time for any service, particularly
one covered by HIPAA. Besides, why intentionally implement a known-to-be-
insecure second factor method? This is brand new code; there's no need to
incur technical debt from day one. Which leads to:

> It's a good place to start until you are at a scale where you would have
> dedicated security engineers to work on the problem.

Except that day never comes for a variety of reasons. "Users already expect it
so we can't remove that." "There are several dozen other security
audits/features/fixes we need to make, let's prioritize those first." "What?
SMS is insecure? Weird, never knew that."

Also, if we don't start making the decision now, before the second factor is
ever implemented, to move away from using SMS as that second factor for the
reasons it is known to be broken, when do we start?

------
InGodsName
Once we lost the user account DB at a startup to database data loss and some
other day, someone logged into mongodb and dropped all the tables and backups
were not test before, so they did not work.

After that we no longer store these details.

We've been using amazon cognito with lambda authorizers.

~~~
SahAssar
That sounds like the problem is how you keep your database permissions and
backups, not anything to do with auth.

