Originally published at: http://www.sitepoint.com/rails-authentication-oauth-2-0-omniauth/
This is the third article in the Authentication with Rails series. We’ve build a classic login/password authentication systems with features like remember me, reset password, confirm e-mail, and the like.
Today we are going to talk about authentication via social networks with the help of the OAuth 2 protocol. We will discuss OmniAuth and four of its strategies: Twitter, Facebook, Google+, and LinkedIn, allowing users to log in with any network they like. I will instruct you how to integrate each strategy, set it up, and handle errors.
Source code for this article is available on GitHub.
A working demo can be found at sitepoint-oauth2.herokuapp.com.
OAuth 2 and OmniAuth
OAuth 2 is an authorization protocol that enables a third-party applications to obtain limited access to an HTTP service. One of the main aspects of this protocol is the access token that is issued to the application. This token is used by the app to perform various actions on the user’s behalf. However, it can’t perform something that was not approved (for example, the user may only allow an app to fetch information about friends, but not post on the user’s wall).
This is cool because, under no circumstances should a third-party app access a user’s password. It only gets a special token that expires after some time (typically, users may also revoke access manually, as well) and may only be used o perform a list of approved tasks, called a scope.
How is a third-party app identified? Well, when talking about social networks, an app has to registered first. The developer provides the app’s URL, name, contact data, and other information that will be visible to the user. The authorization provider (Twitter or Facebook) then issues a key pair that uniquely identifies the app for the social network/provider.
Here is the simplistic overview of what happens when a user visits the app and tries to authenticate via a social network:
- User clicks “Login” link
- User is redirected to the social network’s website. The app’s data (
client_id) are sent along for identification
- User sees the app’s details (like name, logo, description, etc.) and which actions it would like to perform on his behalf (the scope). Think of it like you coming to the user and saying: “Hey, my name is Jack and I want to get the list of all your friends! If you agree, I’ll show you interesting statistics about them”
- If the user does not trust this app, they just cancel the authorization
- If the user trusts the app, the authorization is approved and the user is redirected back to the app (via callback URL). Information about the authenticated user and a generated token (sometimes with a secret key) is sent along.
There are numerous of services that support OAuth 2 authentication, so to standardize the process of creating authentication solutions OmniAuth was created by Intridea, Inc. It supports anything from OAuth 2 to LDAP. In this article, we will focus on omniauth-oauth2, an abstract OAuth 2 strategy. Basically it is used as a building block to easily craft authentication strategies on top of it. Here is the huge list of all strategies available for OmniAuth (it also includes those which are not related to OAuth 2).
Having a standard approach for strategies is great because you can integrate as many as you want without issue. Still, you have to remember that some social networks may return a different data about the authenticating user, so testing how your app works is absolutely necessary (I will show you some examples on this.)
If you have never integrated OAuth 2 into an app, this all might seem complicated, but don’t worry, soon it will become very clear! It is nice to learn by example, so let’s dive into the code and create something fancy.Continue reading this article on SitePoint