11–20 of 141 posts
In my current project I do away with accounts completely and just email a link that sets a cookie for 30 or 90 days [1]. I think the Auth you choose highly depends on the money/privacy/sensitivity/fraud potential of your project.
If I want to put something together fast I use the default AWS Cognito and Firebase Auth widgets. I think Firebase Auth has more third party sign in options. In my current project I do away with accounts completely and just email a link that sets a cookie for 30 or 90 days [1]. I think the Auth you choose highly depends on the money/privacy/sensitivity/fraud potential of your project. [1] https://tedpiotrowski.svbtle…
Currently I am trying to integrate Firebase into AWS because of how bad Cognito is.
One thing going well that Cognito will never be is Firebase Auth.
I build my apps on Sandstorm[1]_. Sandstorm provides authentication as a part of the platform. For Django applications, I wrote Django Loves Sandstorm[2]_. If your application fits into Sandstorm's model of grains[3]_, then the security benefits of Sandstorm are many. .. [1] https://sandstorm.io/ .. [2] https://pypi.org/project/djangolovessandstorm/ .. [3] https://docs.sandstorm.io/en/latest/using/security-practices.…
At a high level:
1. Claim and prove ownership of a public key 2. Sign a session claim that links the handle with the public key 3. Service verifies the claim's signature was signed by the corresponding private key
I only wanted read-only social network login.
There was an official library in the language of my choice.
It was free (at my level of use).
The only thing I need to keep secure is the API tokens for Facebook / Twitter / GitHub etc. I don't even bother storing anything other than the user's ID, current name, and service.
If someone hacks my service, they won't be able to do anything nefarious with the user's data.
Building your own is a nightmare. If a login provider changes their API flow, Auth0 are incentivised to fix it - rather than passing the buck to me.
Yes the problem these days is a lot of commercial providers want this to become "common knowledge" and for it to be "best practice" to use their systems. But what happens if Okta has a data breach and you don't even know if your users were affected? (This happened)
I strongly believe in rolling your own auth:
1. It keeps it simple
2. You control the data that's a critical part of your system
3. Okta and Auth0 are giant targets because they have so many peoples' creds - you aren't
4. Even if you do use something like Auth0, you still need to implement authorization somehow. Of course, there are people who want to sell you solutions for that too...
Use libraries for the underlying primitives like bcrypt and JWT's. Do the rest yourself. Keep it simple.
Oh, and keep it simple.
The one good reason I've seen recently to use third party auth services is because they often support MFA. But how many companies actually need that? I've worked for a bunch of companies over my career and the amount of times I've had to implement/add MFA is 0.
For bigger projects where I need a full-fledged and reliable solution out of the box, I use Ory[1].
I suspect most people use products like Auth0, not because they are trying to solve those hard problems, but more likely, because it's easy to set up and comforting to hand off that segment to a company that says they are battle-tested and secure, etc.
I personally like writing my own Auth because I can cater to my personal level of paranoia and learn more. Maybe I'm weird in that way, that I like to consider questions like, how short-lived should my token be? Should I issue a new token on every request? Local Storage vs cookie? Should I use a one-time token? Should I store the JWT in memory only on the client? How would I invalidate a user's token at will?
There's lots of interesting questions beyond the basics for sure and I can see how that might be intimidating. Most projects only need the basics though. And if you need more, it might be easier to extend your own implementation rather than some use-case not catered to by a library or service.
At the very least, I think it's wise for dev's to experience writing their own Auth a few times to get a grasp of some the challenges and better understand what those services might be doing for them.