I'm trying to figure out the differences between omniauth (https://github.com/intridea/omniauth) and oauth-plugin - (https://github.com/pelle/oauth-plugin)
I'm simply looking for a way to allow my users to authenticate with (Twitter, Facebook, etc) within my app.
I know omniauth provides this, but I'm running rails 2.3.10 which I don't believe is supported by omniauth. Can I use oauth-plugin? It also seems to have a lot fewer dependencies. Any thoughts are appreciated.
I have to disagree with the previous answers.
oauth-plugin is
a plugin for implementing OAuth Providers and Consumers in Rails applications. 1
It provides two generators (one for implementing an OAuth provider, one for the consumer) which create the models, the views and the controllers. The way the controllers work, is that they are subclasses of controllers defined in the gem. It's tied into Rails pretty deeply, and can only do OAuth.
omniauth, on the other hand, is a modular, framework-agnostic library that allows you to provide authentication via a multitude of providers.
Concretely, it means that you set up two endpoints (/auth/:provider and /auth/:provider/callback), have your user authenticate with the provider, and receive a hash with the user's info in return.
TL;DR
If you only need to provide authentication via Facebook/Twitter/OAuth/etc (i.e. you want to be an OAuth consumer), then omniauth is definitely more lightweight.
If you want to run an OAuth provider, oauth-plugin might be more straightforward, but it tends to be a lot more bloated, in my opinion, since it injects a lot of boiler-plate code into your app.
Omniauth is a mega-authorization gem, giving you access to the OAuth processes for a whole list of web services (Twitter, Facebook, Foursquare, Gowalla, Netflix, YouTube, etc, etc), so you can call specific functions for each service and get it set up quickly.
The oauth-plugin you mention appears to just set you up with an OAuth general setup, and you'd have to do the API hookups for each service yourself. More lightweight, so if you only need Twitter services, for example, that might be a better way to go, although I'd still probably check out Omniauth to see how big of a performance drain it is, because it's going to be a lot easier to use overall.
Related
Due to requirement changes we need to add a node server to our already existing system. We will be using sails.js for the realtime communication part of the app and redis store for session management. But the confusion now is what is the best way to authenticate the client app/user on both servers with one login form.
Any help will be much appreciated.
Unless you have specific limitations or widhes, this sounds like standard requirement for SSO (Single Sign-On) implementation. OAuth is wide-spread standard in this area.
Ruby have implementations for this, see this repository for example
OAuth2 A Ruby wrapper for the OAuth 2.0 specification.
As for reading materials, you can check this article:
Single Sign On (SSO) for Multiple Applications with Devise, OmniAuth
and Custom OAuth2 Implementation in Rails
This tutorial may also help.
Then, you can implement OAuth in your node js server, and other services when needed.
Or detail your question and specific requirements or limits for other options. Meanwhile, you can check this SO question on other non-SSO options.
I'm learning about developing APIs with rails, but I can't find how to secure the base methods like user creation. Let's say I have a rails backend API and a frontend mobile app. I want the app to be able to make API calls to create a new user. Off course, not everyone should be able to create a new user, so it should have some kind of authentication. I could use basic or digest authentication (doesn't really matter, because I'll definitely use SSL), but then I would have to hardcode the credentials into my app. If the credentials are discovered somehow, I would have to change them, but that would mean that all instances of the app are no longer authenticated and they can't create users anymore.
The things I would like to have:
Only my apps should be able to use the user creation calls.
It should be easy to change the credentials, or the credentials should change automatically over time. If they would involve the date and time for example, it would be harder to crack.
It should be impossible (or VERY hard) to beat the system behind it, while having knowledge of a couple of the credentials over time.
Would it be possible for example to let my apps generate public and private key pairs at random and use them? What's the standard way of securing these calls?
Thanks in advance,
Rugen Heidbuchel
I could share my own experience:
https protocol communication with API. That is your last sentence about private/public keys, all is built in into https.
Doorkeeper (we combine it with Devise) gem for Oauth (github accounts in my case) as authentication, while you can use pairs of user/passwords instead.
CanCanCan gem as authorization (User creation restriction is about authorization and not authentication)
Set of that three tools should provide essential security level for your API. I believe cancancan could be under discussion, while devise is mostly industry standard.
So Im developing a Rails app- primarily serves API which I want to lock down behjind a nice authorization system. Ive created Rails apps which render HTML and for that I used Devise and CanCan. This time I want to serve JSON to my clients. I basically have the following requirements:
Need an authorization system thats robust
A user should be able to log in with existing apps such as facebook, twitter, linked in and google
There should be full stack authorization available
Now this is my 1st app that Im writing that serves up API so I started researching and so far Ive found the following solutions that people have used:
I've seen people use Devise with CanCan
I've seen people talk about using Oauth2
http://railscasts.com/episodes/353-oauth-with-doorkeeper?autoplay=true
I've heard... "Use Doorkeeper"
I've heard use ..." Use omniauth"
So basically my 1 day of research basically just confused me more. When di I use these and for my requirements which comnbination would I use! Im struggling to make sense of the alphabet soup, can someone help me understand this
Devise is an authentication engine for Rails apps of all types. Devise allows authentication against username/password, token authentication (good for API's), and an oauth provider (such as Google, Facebook and the like). This obviously allows you to deny access to the API unless the user is signed in through one of the services you offer.
CanCan is an authorization system that will work on top of Devise to allow users access to certain parts of your system based on their role within the system. CanCan has a very slick DSL prviding can and cannot methods for allowing or denying access to views or controller actions.
Doorkeeper is an oauth provider gem if you wanted to roll your own oauth solution on top of your API. This would be if you wanted your application to act in the same manner as Google or FAcebook in providing an oauth endpoint for users to authenticate against. From what you stated above, I don't think this is the case.
Given the requirements you provided above, I believe that Devise and CanCan would be the route that I would choose. This would allow the user to authenticate at first by username/password, or some oauth provider, then allow token authentication after that to access your API. You can then lock down access to specific actions through CanCan.
We're building a Rails 3 web application that will need to authorize and authenticate regular users who visit the site. Those same users may also use third-party applications to access the site via our API.
What approaches can we use to effectively and cleanly provide access to clients as well as users? What strategies have you used in your own Rails applications that also have RESTful APIs?
Ideally, we're after a solution which:
plays well with Devise and CanCan (which we already use for authn/authz)
plays well with Mongoid
doesn't pollute our controllers
is relatively simple to install and configure, if it's a gem or plugin
is easily testable, if it's a general strategy; or is already tested, if it's a gem or plugin
Since you're already using Devise, take a look at the token_authenticatable strategy (Add it to your user model and make sure the devise init reflects whatever you call the token param).
You'll want to add: "before_save :ensure_authentication_token" to your user model as well (assuming you don't want it to be single use).
Just provide your user's with their tokens on say their profile page or wherever. Call it an API token if you like.
I have a rails 2.3.5 application with an API I wish to protect.
There is no user - it is an app to app style webservice (more like an Amazon service than facebook), and so I would like to implement it using a two-legged OAuth approach.
I have been trying to use the oauth-plugin server implementation as a start:
http://github.com/pelle/oauth-plugin
...but it is built expecting three-legged (web redirect flow) oauth.
Before I dig deeper into making changes to it to support two-legged, I wanted to see if there was an easier way, or if someone had a better approach for a rails app to implement being a two-legged OAuth provider.
Previously, the only good answer was to hack about in the oauth-plugin to get this subset of the oauth interaction. Since then, the oauth-plugin was refactored, and now you can use it straight up, just by adding the right type of authentication filter to your controller:
class ApiController < ApplicationController
include OAuth::Controllers::ApplicationControllerMethods
oauthenticate :strategies => :two_legged, :interactive => false
# ...
end
I'm not aware of any alternatives to oauth-plugin at the moment, though it is definitely getting long in the tooth and ripe for a replacement. My recommendation is to generate the oauth server from oauth-plugin, then extract the dependencies from the plugin (which are just a couple modules worth of methods) and trash the plugin. Then tweak everything to your needs. 2-legged oauth should not be a big problem since it is simpler than 3-legged anyway, and my feeling is that oauth-plugin is not usable these days without significant modifications anyway.
The meat of OAuth has long been extracted into the base oauth gem anyway, so the oauth-plugin is sort of in limbo. The architecture makes some heavy-handed assumptions about what authentication system you are using, and the generated code is dated. So to me, oauth-plugin serves more as an example of how to wire everything up rather than something that most sites would want to use out of the box.