Rails and oauth-plugin part 2: the consumer

In the previous post, I showed how you could build a provider with oauth-plugin and Rails. Now, I will demonstrate how to build a consumer (it’s a lot easier).

I will assume that your provider is already running on localhost:3000. The consumer will run on localhost:4000 (run it with “rails server -p 4000”).

Here we go!

rails new consumer
cd consumer

Put this in your Gemfile:

source 'http://rubygems.org'
gem 'rails', '3.0.7'
gem 'sqlite3'
gem 'devise'
gem "oauth-plugin", ">= 0.4.0.pre1"

And run these commands:

bundle install
rails generate devise:install
rails generate devise User
rake db:migrate
rails generate controller welcome index
rm public/index.html

And here is your routes.rb:

Provider::Application.routes.draw do
devise_for :users
root :to => "welcome#index"
end

Create the consumer

rails generate oauth_consumer user
rake db:migrate

in app/controllers/oauth_consumers_controller.rb, replace:

before_filter :login_required, :only=>:index

by

before_filter :authenticate_user!, :only=>:index

Uncomment the methods for devise (go_back, logged_in? currentuser=, deny_access!) in app/controllers/oauth_consumers_controller.rb.

Add to app/models/user.rb:

 has_one  :test, :class_name=>"TestToken", :dependent=>:destroy

Now go to http://localhost:3000/oauth_clients/ to register your first application with these parameters:

Name:                 Test consumer
Main Application URL: http://localhost:4000/
Callback URL:         http://localhost:4000/oauth_consumers/test/callback

You’re redirected to http://localhost:3000/oauth_clients/1. It shows:

Consumer Key:      CRcIJ15MwSqlDTxsH8MpO3En4wjaOxkqeofLioH4

Consumer Secret:   C7uci8xkyMShCf4SNXWPclKbBo3ml1Zf2W2XWu4W

Request Token URL: http://localhost:3000/oauth/request_token

Access Token URL:  http://localhost:3000/oauth/access_token

Authorize URL:     http://localhost:3000/oauth/authorize

Now, you need to put the key and secret in config/initializers/oauth_consumers.rb:

 OAUTH_CREDENTIALS={
:test =>{
:key => "CRcIJ15MwSqlDTxsH8MpO3En4wjaOxkqeofLioH4",
     :secret => "C7uci8xkyMShCf4SNXWPclKbBo3ml1Zf2W2XWu4W",
     :expose => true
   }
 }

Create app/models/test_token.rb. This model will store the token for your provider. If you want to provide helpful methods, take inspiration from lib/oauth/models/consumers/services/.

class TestToken < ConsumerToken
TEST_SETTINGS={
:site => "http://localhost:3000",
:request_token_path => "/oauth/request_token",
:access_token_path => "/oauth/access_token",
:authorize_path => "/oauth/authorize"
}

def self.consumer(options={})
@consumer ||= OAuth::Consumer.new(credentials[:key], credentials[:secret], TEST_SETTINGS.merge(options))
end

end

You should now be able to use the URLs “/oauth_consumers/test/client/”, “/oauth_consumers/test/callback”, “/oauth_consumers/test/callback2″,” /oauth_consumers/test/edit”,
and “/oauth_consumers/test”.

Modify the welcome controller t get the provider data:

 class WelcomeController < ApplicationController
 def index
 # cf http://oauth.rubyforge.org/rdoc/classes/OAuth/AccessToken.html
 @consumer_tokens=TestToken.all :conditions=>{:user_id=>current_user.id}
 @token = @consumer_tokens.first.client
 logger.info "private data: "+@token.get("/data/index").body
 end

end

To connect a user to an external service link or redirect them to:

/oauth_consumers/[SERVICE_NAME]

Where SERVICE_NAME is the name you set in the OAUTH_CREDENTIALS hash. This will request the request token and redirect the user to the services authorization screen. When the user accepts the get redirected back to:

/oauth_consumers/[SERVICE_NAME]/callback

That’s it

This tutorial is really short, and could be explained a bit more, but I’ll leave that for another post. You have enough to start tinkering with OAuth. Have fun!

Advertisements

Rails and oauth-plugin part 1: the provider

These days, I have been playing a lot with Oauth and its RoR implementation, oauth-plugin. Its documentation is a bit short, so here is a tutorial to show how to use it, both in provider and consumer mode. And we will even make them communicate with each other.

We will now build an Oauth provider using oauth-plugin for authorization and Devise for authentication. And we will add a controller protected by Oauth.

Starting up

A few instructions to create the application. You won’t need an explanation for this:

rails new provider
cd provider

Put this in your Gemfile:

source 'http://rubygems.org'
gem 'rails', '3.0.7'
gem 'sqlite3'
gem 'devise'
gem "oauth-plugin", ">= 0.4.0.pre1"

And a few more commands:

bundle install
rails generate devise:install
rails generate devise User
rake db:migrate
rails generate controller welcome index
rm public/index.html

And don’t forget ‘root :to => “welcome#index”‘ in config/routes.rb.

Create the provider

rails generate oauth_provider oauth

rake db:migrate

You could put something else than “oauth” as parameter, but for the moment, the generator has some bugs (it always generate the class OauthController, but with a different name). I’ll check more recent versions of the code.

Now, modify config/application.rb and add:

require 'oauth/rack/oauth_filter'
config.middleware.use OAuth::Rack::OAuthFilter

Put in app/models/user.rb:


has_many :client_applications

has_many :tokens, :class_name=>"OauthToken",:order=>"authorized_at desc",:include=>[:client_application]

Put in app/controllers/oauth_controller.rb:


alias :logged_in? :user_signed_in?

alias :login_required :authenticate_user!

and uncomment authenticate_user.

Put in app/controllers/oauth_clients_controller.rb:

alias :login_required :authenticate_user!

And now some data

Create a new controller:


rails generate controller data index

And now, edit your controller:

class DataController < ApplicationController
  before_filter :oauth_required

  def index
    @data = { "coincoin" => "o< o<" }

    respond_to do |format|
      format.json { render :json => @data }
    end

  end
end

UPDATE

I discovered a few bugs in this tutorial, so here are the fixes.

oauth-plugin needs the function current_user=, so add this to your ApplicationController:

def current_user=(user)
  current_user = user
end

Next, to handle revocation, you need to add this to config/routes.rb:

post 'oauth/revoke'

And at last, you need to fix the rack filter. The current code doesn’t verify the token validity, and lets revoked tokens access your data.
You have to modify lib/oauth/rack/oauth_filter.rb in the oauth-plugin gem folder.
Replace the line 46:

oauth_token = client_application.tokens.first(:conditions=>{:token => request_proxy.token})

by

oauth_token = ClientApplication.find_token(request_proxy.token)

And that’s it!

You now have a working provider. OauthController handles all the communication with the consumers. OauthClientsController manages the registration of new consumers. They both have customizable views: oauth for the authorization part (for users) and oauth clients for the consumers. And you just need the oauth_required filter to manage access to your data.

And now, you can go to /users/sign_up, then /users/sign_in, then /oauth_clients to register a new client application. You just need to give a name for your application, your URL, and a callback URL.

In the next post, we will build a consumer, and this consumer will access the provider’s data.

Yet another authentication scheme

Recently, I was asked to design a new authentication protocol for a web service. I know that I shouldn’t do reinvent the wheel, so I immediatly proposed OAUTH. It turns out that it can’t be used in this situation. Here are the constraints:

-calls to the webservice must be authenticated: I can keep the tokens and signature from OAUTH here. The problem is: how do I get that token?

-calls are made from devices or applications without access to a webbrowser (embedded devices, phones, etc.). The redirection dance of OAUTH is not acceptable here

-communications are done over an untrusted network, without SSL.

-I can’t use application keys and secrets to encrypt and sign the authentication process: clients include open source software and smartphone applications. You can’t hide a secret key in these.

-the protocol has to be simple to implement, on a lot of languages

-the server must not store the password in cleartext (I shouldn’t have to precise this…), the client must not store the password

Summing it up: no preshared keys, no browser, no SSL, untrusted networks, no passwords stored, and an OAUTH-like environment once the client is authenticated (tokens, authorizations, revoking, etc)

Apparently, I should just give up. But I like to play, so I’ll try!

First, I must say that I am not an expert in security nor cryptography. But I’m really enthusiastic about these subjects, and my day job is at a company providing strong authentication solutions (no, this protocol is not related to my day job). So, I know a bit about the subject, and I know that I should ask for reviews, hence this post.

Rough ideas

We need a safe communication over an untrusted network. TLS immediatly comes to mind, but the targeted applications might not have access to a TLS implementation. I’d like to use SRP, but I don’t think I’m able to implement it correctly (and it has to be SIMPLE). Using Diffie-Hellman to establish a shared key is another idea, but it is not safe against MITM.

Here’s my idea: we don’t need to generate a shared secret, we already have it. It’s the password!

But how can I use the password if the server doesn’t store it in cleartext?

The trick: key derivation functions

Decveoplers are finally understanding that they should not use MD5 nor SHA1 to store their passwords, even with a salt, because computing power is so cheap these days that anyone could crack easily a lot of passwords.

It is now recommended to use other functrions tro store passwords. The key derivation functions are a class of functions that create a key from a password. Basically, they do it by interating a lot of times. That makes them very slow, which is an interesting property if you want to stpre passwords: it is too expensive to “crack” the password. PBKDF2, bcrypt and scrypt are well known key derivation functions. They’re simple to use and available in a lot of languages.

With these functions, I can safely store the passwords, and generate a key shared with the client.

In short: if I store kdf(password, N) with N the number of iterations, I can send any M > N to the client and ask him to compute the key, without compromising what I store.

Designing the protocol

Now that we have a way to use a shared key, we can look at what will go over the wire to establish it. If I use directly kdf(pass, M), anybody getting access to the client storage will be able to obtain the key for any L > M. So, the key establishment has to use a nonce. That way, the client will only use the password once and forget it, and store the derivated key.

I would rather use a truly random key that has no relation with the password. It could be given to the client, encrypted with the derivated key. The derivated key could then be thrown away. But I still do not know if it is really necesary.

The server still needs to authenticate the client. The client will make a second call to the web service, signing it with HMAC and the key.

That’s it! It is really simple, so if there are flaws I did not see, you will surely catch them.

TL; DR

The protocol is based on key derivation functions, like PBKDF or bcrypt.

  • The server stores login and H = kdf(pass, N), with N integer
  • The client wants to authenticate and makes a call to the server with the login as argument
  • The server replies with M > N and i nonce
  • The client calculates k1 = kdf(kdf(pass, M)+i, 1)
  • The server calculates k2 = kdf(kdf(H, M-N)+i, 1)
  • The client calls the server with args “user=login&sign=”.HMAC(“user=login”, k2)
  • If k1=k2. The signature matches and the client is authenticated.