Early on in Everyday Rails, I outlined three options for adding authentication to your Rails applications. It’s still a popular subject—and with two major releases of Rails and a number of new authentication options hitting the streets since I wrote my original list, it’s due for a refresh. Here’s a look at the current Rails authentication landscape.
If you don’t want to mess with usernames and passwords—or perhaps as importantly don’t want your users to have to mess with so many of them—OmniAuth is your best bet. OmniAuth lets you pick from any number of login providers, from Facebook to Twitter to GitHub to Google to LDAP to OpenID to any combination of the above. See the README for a full list of 60-plus providers. With some additional work, you can also incorporate OmniAuth into an existing login mechanism.
Note that as of this writing there are two branches—a stable 0.3 branch and a work-in-progress 1.0 version. The change is a major one, but well-justified for the long-term health of OmniAuth.
Last year I recommended Devise for Rails authentication needs. Its biggest selling point then continues to be its biggest selling point now: Full-featured authentication, including signing up, signing in, password resets, account management, and testing helpers. With Devise, you can have all of that in under ten minutes. Devise’s documentation continues to be incredible, as does the list of third party extensions to provide alternative ORMs, encryption, external authentication, and other general functionality.
That said, I’ve moved away from Devise for most of my projects, because inevitably something I wanted to do didn’t jive with how Devise wanted to do things. However, if you need full-featured authentication, won’t be straying too far out of the box, and time is an issue, Devise is still tough to beat.
Sorcery is this year’s new kid on the block for authentication, and to be honest my exposure to it doesn’t go much further than the recent Railscasts episode covering how to set it up. Its developer, Noam Ben Ari, stresses a “less is more” approach to authentication—giving you the tools you need to set up authentication relatively quickly, as well as room to adjust in the future as your application’s authentication requirements change. In other words, Sorcery provides the authentication library, but you’ll have to write the models, views, and controllers to make it work the way you want it to in your app.
In terms of complexity, Sorcery resides somewhere in the middle of Devise’s kitchen sink approach and the do-it-all-yourself approach I’ll talk about momentarily. As such, it should be a good option if you want to be able to get some quick authentication in place and still be able to customize down the road with minimal headaches.
If you want total independence from other developers’ interpretations of how authentication systems work, it’s really not that hard to write your own. Two excellent Railscasts episodes cover how to do this in Rails 3.1 (using the new has_secure_password option) or Rails 3. Bonus points for adding password reset and remember me functionality; even more bonus points for writing specs to make sure authentication works as planned.
For the record, this is the approach we took on our current big project at my day job. It does take a little more time to implement—though not much. In the long term we’ve got a simple-but-solid solution that fits our exact authentication needs perfectly.
If you liked my series on practical advice for adding reliable tests to your Rails apps, check out the expanded ebook version. Lots of additional, exclusive content and a complete sample Rails application.
Ruby on Rails news and tips, and other ideas and surprises from Aaron at Everyday Rails. Delivered to your inbox on no particular set schedule.