[headmelted]

I would have phrased it differently, but I see the parent's point.

You don't roll your own security. You just don't do it. There are far too many variables that you can screw up, and anything you come up with isn't realistically going to go through nearly as much battle-testing as a ready-made solution (either upfront or on an ongoing basis).

> Custom built auth isn't as scary as you make it to be

Custom-built auth should be scary. Anyone who's worked on the security story for a popular framework will tell you that.

If you're not scared by it I'd have to assume you're either not seeing large swathes of the problem space or you're a genius.

[debaserab2]

But everyone rolls their own security. Security isn't a feature of the application, it's a characteristic of every piece of code, workflow, and practice your dev team implements. I know this sounds like a platitude, but if you treat security like something that you should only let the experts handle, you may end up not paying attention to the security properties that end up in your control.

Don't write your own crypto. That's great advice. The idea that everyone's auth needs are so standard they fit for every app just hasn't been realistic in my experience.

[sellingwebsite]

I should have phrased it differently.

Yes, you don't roll your own security. You use powerful primitives provided by Ruby and Rails, such as bcrypt, has_secure_password/has_secure_token, encrypted sessions, secure httponly cookies with prefixes + samesite attrbiute all served over TLS 1.2+, with HSTS and CSP

[ratww]

I'd argue that Auth itself isn't hard per se, but it involves hard things that you shouldn't roll your own, notably cryptography and session handling.

But those are things that people normally delegate to either libraries (crypto) or the framework itself (session handling).

Of course, there's lots of places one can screw up, such as sending non-expirable password reset tokens, revealing private information and membership status via F2A/reset tokens. But those are the kinds of screw-ups that can happen in other parts of the website too.

That said, Devise is one of the few things that I don't completely dislike about Rails.