91–100 of 247 posts
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.
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.
LDAP is really overlooked by many and I think people are surprised by the amount of software that offers LDAP support.
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.
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?
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 c…
> 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.
Earlier quoted context omitted.
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?
Tptacek shits on them every time it comes up. Unfortunately I can never quite comprehend what he says to do instead.
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.
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.
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)