Skip to content
This repository has been archived by the owner on Aug 25, 2020. It is now read-only.

Assertions for non-JWT tokens, users without access #20

Open
pacovell opened this issue May 10, 2012 · 11 comments
Open

Assertions for non-JWT tokens, users without access #20

pacovell opened this issue May 10, 2012 · 11 comments

Comments

@pacovell
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor Author

e915882

@pacovell
Copy link
Contributor Author

pacovell commented Jun 1, 2012

Any thoughts here?

@bploetz
Copy link
Collaborator

bploetz commented Jun 2, 2012

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.....

@pacovell
Copy link
Contributor Author

pacovell commented Jun 2, 2012

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.

@bploetz
Copy link
Collaborator

bploetz commented Jun 4, 2012

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.

@pacovell
Copy link
Contributor Author

pacovell commented Jun 4, 2012

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:
#20 (comment)

@assaf
Copy link
Owner

assaf commented Jun 4, 2012

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:
#20 (comment)

@bploetz
Copy link
Collaborator

bploetz commented Jun 4, 2012

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

@edgar
Copy link

edgar commented Jul 2, 2012

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

Thanks

@pacovell
Copy link
Contributor Author

pacovell commented Jul 4, 2012

@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!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants