Ankit Patel
Ankit Patel

Reputation: 67

Authentication: Custom or Third Party

I'm creating an app in Ruby on Rails and have research Devise, Omniauth, and creating my own custom version.

My question is: what are the scenarios in which you would use one of the three choices above?

My take: - Omniauth can provide quick registration through third party APIs, but would require additional permissions to access additional data - Devise provides core functionality which can also be customized based on the applications needs - Custom may be for extreme scenarios which, currently, I do not need

** I'm leaning towards Devise as it provides the core and allows me to add onto that

Additional Considerations: - My application needs to sign in and access basic information for: location, language I18n, etc - My application also does financial transactions (if you're a paid member, et al).

Going back to my question: based on the above, does Devise seem to be the better choice? Does Omniauth provide these features? When should I use one versus the other?

Thanks

Upvotes: 1

Views: 1152

Answers (2)

max
max

Reputation: 102249

Devise and Omniauth do very different things - and they are often used together.

Devise provides a full authentication package with views, controllers and routes to allow users to sign up, edit user profiles, reset passwords, etc. Devise can be used without the database authentication module with provides signup via email password.

Omniauth is a framework for authentication users via Oauth. Omniauth unlike Devise does not ship with any views or controllers. Instead you need to integrate the Oauth callbacks into your app. What Omniauth does is abstract away the differences between different providers.

Both can be used together to provide user authentication via password or oauth for example.

Rolling your own authentication solution is generally not advisable. Projects like Devise have hundreds if not thousands of man-hours behind them and many eyes viewing the code base for flaws. Crappy home rolled auth solutions by companies with Not Invented Here Syndrom are one of the most common security failures that have lead to user data and passwords being leaked.

Upvotes: 2

Richard Peck
Richard Peck

Reputation: 76784

To add context to @max's answer, OmniAuth is an extraction of OAuth (Open Authorization)...

OAuth is a simple way to publish and interact with protected data. It's also a safer and more secure way for people to give you access. We've kept it simple to save you time.

Whenever you have a trusted service such as Facebook, Twitter, LinkedIn, GitHub, NetFlix, etc, and want to use a service in conjunction with your pre-built connectivity on these existing services, you'll need a secure way to "authorize" the use of that data...

  • A "CRM" system which allows you to "import" contacts from LinkedIn
  • A "social sender" system which allows you to send messages to your Facebook friends
  • Recommend new movies based on what you recently watched on NetFlix

Most people know OAuth by virtue of the "Allow Access" notification for Facebook etc:

enter image description here

Interpreting this in your own app is simple - do you want to pull data from Facebook / Twitter / LinkedIn / GitHub etc?

Real use of OAuth should be to extend your application.

enter image description here

Most users treat "app requests" for their social network data as an extension of the "social" experience (IE if I allow app access to my FB, I expect it to post to my wall etc).

Instead of treating it as a way to allow users to sign in with Twitter / Facebook / LinkedIn credentials (which is 100% valid), you should think about the higher-level functionality.

--

Devise != OmniAuth

Devise is an authentication system; OAuth is authorization.

OmniAuth extends OAuth for authentication:

OmniAuth is a library that standardizes multi-provider authentication for web applications.

It replaces email/password with Twitter API key. Thus, whenever creating authentication on your system, you will always need to store User data etc - it's how that data is authenticated which makes the difference.

In short, if you want Sign in with Twitter buttons etc, OmniAuth is recommended. However, to keep your authentication consistent, you'll be best using Devise with OmniAuth.

--

Finally, don't roll your own authentication unless you've implemented Devise at least 5 times. All Rails authentication works similarly (uses Warden strategies). It's not going to be worth your time debugging your own system when Devise has 100,000's of users doing the work for you.

Upvotes: 1

Related Questions