4

I have 3 web apps - A, B and C. App A contains the user database. If accessing App B and App C, I would like the user to be redirected to App A to be authenticated, and then be returned back to whichever app they tried to access. At the same time, they should be logged in to all apps. Unless anyone has a better solution, I have gone with an OmniAuth/Devise combo solution as described in this blog post.

I have forked and updated to Rais 3.1.2 a sample App A and a sample app B/C.

App A - Provider - https://github.com/RobZolkos/sso-devise-omniauth-provider

App B/C - Client - https://github.com/RobZolkos/sso-devise-omniauth-client

These sample apps work, and I am get redirected to the Provider App to authenticate however it doesn't seem to authenticate. I have attached the log here. The provider seems to go through the motions, but then on line 26 of the log you can see that there seems to be an authentication issue.

Am I missing something simple to make these sample apps work?

robzolkos
  • 2,196
  • 3
  • 30
  • 47
  • the provider get and post seem to work fine, do you return a token and secret from the provider after the post? – Ben Nov 21 '11 at 01:59
  • After the post I return a token but no secret. The json render line is : render :json => {:access_token => access_grant.access_token, :refresh_token => access_grant.refresh_token, :expires_in => Devise.timeout_in.to_i} – robzolkos Nov 21 '11 at 04:33
  • I tried to do this exact same thing, and ran into the same problem. It seems like the user never actually gets logged in. If I try to output `warden.session` into the log (in the provider app), I get a `Warden::NotAuthenticated` exception. That is, the `authenticate_user!` before filter returns false, and that's why it doesn't work. – Frost Dec 01 '11 at 13:54

2 Answers2

2

I've found two issues:

  1. Since 0.2.1 version omniauth has changed auth parameter name from access_token to oauth_token while fetching access (POST /oauth/token request).
  2. Since 0.3.0 version omniauth has changed method of passing oauth_token in auth request (GET /auth/josh_id/user.json). Prior 0.3.0 token have been passed through request parameter oauth_token, but since 0.3.0 it become passed through HTTP_AUTHORIZATION header.

I don't know how to nicely get token from header (I think it can be fetched by devise), so I ugly hack client for sending oauth_token through GET parameter like this (in lib/josh_id.rb):

def raw_info
  @raw_info ||= access_token.get("/auth/josh_id/user.json?oauth_token=#{access_token.token}").parsed
end

You can find fully workable code in our github repos:

Dmitry Lihachev
  • 504
  • 6
  • 20
  • This patch already applied in https://github.com/joshsoftware/sso-devise-omniauth-provider I highly recommend you to use https://github.com/applicake/doorkeeper – Dmitry Lihachev Mar 12 '13 at 08:13
1

I have no experience with oauth in rails, but i'll explain the flow I used to create my own provider in Java. It should be easy to apply this in rails. If you use Devise with omniauth you need to find out, how they provide OAuth support and which version.

Basics

  • Consumer logs in to the app, and gets a consumer_key and consumer_secret. This is done with a regular form, usually on a developer account.

  • (optional)Provider approves the created account

  • All OAuth requests depend on a proper OAuth header in the request. A proper header means:

    1. All oauth attributes and their values have been alphabetically sorted
    2. All keys/tokens active for the particular Consumer request are provided.
    3. The request is signed using all relevant secrets. Secrets are known to the Provider and Consumer but are not included in the header.
    4. The Provider generates the same signature. If so, the request is valid. A nonce can be used to prevent replay attacks.

2-legged flow (consumer vs provider)

  1. Consumer requests a resource, providing consumer_key.
  2. Provider checks signature based on consumer_key and consumer_secret
  3. Access to resource is granted

3-legged flow (person vs consumer vs provider)

  1. Consumer request resource providing its consumer_key
  2. Consumer gets a unsigned oauth_token and oauth_token_secret from Provider
  3. User(person with user account on the provider) logs in at provider to authorize the oauth_token providing the oauth_request_token and consumer_key
  4. Consumer has a authorized request_token
  5. Consumer uses the request_token to request a access_token providing the oauth_request_token and consumer_key
  6. Provider gives a access_token and access_token_secret for the specific resource
  7. Consumer uses access_token to do something
  8. Provider invalidates access_token after a certain duration
  9. Consumer uses the request_token again to get a new access_token if expired

A decent resource for oauth is the official site. For 3 legged examples you can have at the google oauth playground

Ben
  • 13,297
  • 4
  • 47
  • 68