Rails: authentication through different domains

Question

I have to integrate the web application I am developing, with an external web application in order to use their services. Unfortunately this is my very first work and I am a bit confused.

They asked me to provide the verification URL with login token to help them identify which users come from my website.

1. Users from my app want to get information from 3party app database
2. To do that, the 3party app need to know who they are because, there are different roles in app. And each of them will have different privileges on the 3party app
3. Login to 3party app has to be in my app. They just want a verification URL with login token.

Is it possible to use token authentication through devise to do that? Can I generate a token, store it in clients browser and than use that to get them authenticated in the external domain?

Answer 1

I hope this answer isn't too obvious. Sounds like you're just starting off on this and need some guidance.

From what I read, I get the following requirements:

1. You need to be able to be the authentication authority for another app
2. The 3rd party app wants to exchange and verify credentials via auth tokens
3. The 3rd party app wants the urls to the API calls to do this from you app

I'll cover this in a broad sense, and let you search out a specific solution. Basically you need a way to generate secure authentication tokens. Devise should do this, along with authlogic and several others. What you don't want to do is try to roll your own auth token generation. Definitely use the gems out there to do this for you.

Once you've got tokens being generated, here's an overview of the basic transaction, where an auth token is simply passed as a parameter into a controller action (https is your friend in this transaction, FYI).

1. 3rd party app makes an API call with a token provided by your app
2. Your app checks the auth token for validity, and takes whatever action is requested, if the authentication succeeds
3. Your app responds with authentication success/failure code, and any other response data that the 3rd party app requested, if the authentication was successful

How the tokens are handed off to the 3rd party app, so it can use it to make API requests, is a matter of how you want your app to work. However, a common practice is to use a method is something which follows the following pattern:

1. When the 3rd party app needs to make an API request on a user's behalf, the 3rd party app redirects to your app where the user enters their credentials (if they haven't already). This way the 3rd party app never gets the user's username+password directly.
2. Assuming a successful authentication, your app then redirects back to your callback URL, passing in as a parameter the auth token generated by your app. That auth token is what is used in future API calls, until and unless the auth token expires (it's up to you when they expire, of course, since you're the authentication authority).

If at all possible, it would be great if you can actually use an OAuth provider or some other mechanism that already exists to act as a 3rd party authentication means that both your app, and the 3rd party app trusts. To go down that route, check out this Railscast: http://railscasts.com/episodes/235-omniauth-part-1

...but of course, since you already have an existing app, and especially in enterprise apps, it's less common to be able to integrate oauth providers into your application. But either way, whenever possible it's almost always preferable to offload the authentication mechanism to another party. This is mostly because you want security experts to be worrying about, and updating their authentication services, and to leave the app code to you.

On the other hand, even if you don't go with an OAuth provider as way of solving this, the railscast noted above will give you an idea and pattern to follow when building your own API/callback mechanism. What you'll wind up with is a series of API calls/actions. The routes (urls to these API calls) can, of course, be anything. But as an example, they might look something like this:

/api/auth/:id                     {:controller=>"api", :action=>"auth"}

...which takes as parameters, the a unique key identifying the 3rd party app, along with the 3rd party app's secret key (essentially a password), and a callback url for both success and failures, and responds with success/failure, and a valid auth token upon success.

/api/some/restful/resource/call   # example API call for some RESTful resource you make available
... etc. ...

Like I said, even if you don't go with a 3rd party authentication provider, following the railscast I posted (as well as the follow up episodes) will give you an idea of the implementation pattern that other robust APIs out there use. Setting up a demo application to do facebook authentication would also be very instructive, and would probably only take you a couple of hours, just to get a handle on the workflow.