rack-oauth2-server icon indicating copy to clipboard operation
rack-oauth2-server copied to clipboard

Assertions for non-JWT tokens, users without access

Open pacovell opened this issue 13 years ago • 11 comments

Use Case:

  1. Mobile device authenticates with Facebook, receives access_token.
  2. Mobile device sends access_token to the server as an assertion
  3. If the server recognizes that Facebook access_token as belonging to an existing user, return our oauth access_token as a normal access_token request; if it doesn't return unauthorized 401.

oauth2-provider (https://github.com/songkick/oauth2-provider) covers this use-case by having an assertion handler:


OAuth2::Provider.handle_assertions 'https://graph.facebook.com/me' do |client, assertion|
  facebook = URI.parse('https://graph.facebook.com/me?access_token=' + assertion)
  response = Net::HTTP.get_response(facebook)

  user_data = JSON.parse(response.body)
  account   = User.from_facebook_data(user_data)

  account.grant_access!(client)
end

[Edited]: My thought is to do the same thing:

    config.oauth.assertion_handler['my_assertion_type'] = lambda do |client, assertion, scope|
      # ... behave the same as authenticator()
    end

This totally bypasses the register_issuer configuration, which may be seen as a Bad Thing, so please let me know your thoughts.

To avoid mucking anything up with JWT tokens, I'll skip the assertion_handler in this case, but it may be useful later, as I can't see right now how a JWT token would be associated with an local identity unless the original creator knows our identity data. Maybe I am missing something?

Thoughts, better ways to handle, or other comments?

pacovell avatar May 10 '12 17:05 pacovell

For completeness, it seems that if I were able to get ahold of the facebook signed_request parameter from the login, I would be able to use that directly with the existing JWT structure, excepting (3), which could still benefit from the callback.

Unfortunately, I don't seem to be able to get that token from the login library my mobile developer is using.

pacovell avatar May 10 '12 19:05 pacovell

e915882bcbc610a526b604a8d5bdf69aa1c489ee

pacovell avatar May 10 '12 20:05 pacovell

Any thoughts here?

pacovell avatar Jun 01 '12 21:06 pacovell

Sorry, I'm not sure I understand this scenario. Can you include the request that would be made to the rack-oauth2-server instance in this flow (step 2 above)? Maybe that will help me understand.....

bploetz avatar Jun 02 '12 02:06 bploetz

Sure, the request looks like this:

client_id:...
client_secret:...
grant_type:assertion
assertion_type:facebook.com
assertion:AAADh2hKj0ZAUBALSvzY7HB3CIb0Y0ZAOB82bFZBvBCBGsZBOUTtM9dfZAbEc3YX9NHE0HvXmauQ26prlbh670Iab2vqNm1aId624t7QvqbQZDZD

It serves the same purpose as sending the signedRequest from Facebook, except in this case the Facebook wrapper I have access to doesn't make the signedRequest available, so I only have the accessToken. It is what is sent in the assertion field, validated by the server, which then issues its own credentials if the accessToken is valid and the user is known to the server.

pacovell avatar Jun 02 '12 03:06 pacovell

While I see that what you're suggesting is a hook to allow users of rack-oauth2-server to add support for arbitrary assertion types via configuration (which is a good idea), your Facebook example doesn't seem very secure to me. Obviously if you want to use that approach in a real app that's your call....

@assaf, any issues with this feature? If not I'll merge it in.

bploetz avatar Jun 04 '12 18:06 bploetz

Brian, I'd like to understand more why it's not secure, provided I send the token over an HTTPS link. I'd of course like to make sure I am roughly within best practices for security. Thanks.

On Mon, Jun 4, 2012 at 2:31 PM, Brian Ploetz < [email protected]

wrote:

While I see that what you're suggesting is a hook to allow users of rack-oauth2-server to add support for arbitrary assertion types via configuration (which is a good idea), your Facebook example doesn't seem very secure to me. Obviously if you want to use that approach in a real app that's your call....

@assaf, any issues with this feature? If not I'll merge it in.


Reply to this email directly or view it on GitHub: https://github.com/assaf/rack-oauth2-server/issues/20#issuecomment-6106560

pacovell avatar Jun 04 '12 19:06 pacovell

No issue that I can see.

On Monday, June 4, 2012 at 11:31 AM, Brian Ploetz wrote:

While I see that what you're suggesting is a hook to allow users of rack-oauth2-server to add support for arbitrary assertion types via configuration (which is a good idea), your Facebook example doesn't seem very secure to me. Obviously if you want to use that approach in a real app that's your call....

@assaf, any issues with this feature? If not I'll merge it in.


Reply to this email directly or view it on GitHub: https://github.com/assaf/rack-oauth2-server/issues/20#issuecomment-6106560

assaf avatar Jun 04 '12 20:06 assaf

@pacovell can you send a formal pull request from a topic branch in your repo containing only this change?

bploetz avatar Jun 04 '12 21:06 bploetz

@pacovell I'm looking exactly for this kind of assertion feature, do you have an example on how to use them?

Thanks

edgar avatar Jul 02 '12 23:07 edgar

@edgar I've added comments on Issue #21, please review and let me know if anything is missing -- then it will be easy to wrap up any loose ends and add it to the readme as planned. Thanks!

pacovell avatar Jul 04 '12 22:07 pacovell