Could we have OAuth 2.0 with generic access tokens?

Discussion in 'Shapeways API' started by frknsweetknots, Jun 6, 2013.

  1. It's much simpler for many cases. bit.ly's API is a good example. They use OAuth 2.0 which uses SSL to guarantee security and all that's necessary for most requests is an access_token parameter. You can jump through the hoops of getting an access token for the end-user if you need to, but for applications that will only be using the application's user (the one that owns the app) it's much easier to just store a generic access token.

    For example, the specific case that I'm thinking of is as follows:

    The site myawesome3dprintingsite.com allows you to design awesome 3D models with just a few clicks by their users. To make money the site publishes the users' creations to My Awesome 3D Printing Shapeways shop, where the user can be directed to order it. There shouldn't be a need for an OAuth handshake in this example. myawesome3dprintsite.com should be able to have an access token stored on their server which would be provided to any Shapeways API calls. The end-user isn't involved until they are directed to an item on Shapeways, so an OAuth handshake isn't necessary.

    Anyway, I think this sort of setup would allow more people to get off the ground faster. I bring up bit.ly because when you create an application there it provides you with an access token that you can immediately use to get up and running.
     
  2. hans_lambermont
    hans_lambermont Shapeways Employee Dev Team
    Hi jallwine,

    We can add OAuth-2, or OAuth-3 when it arrives, side-by-side with OAuth-1.

    OAuth-2 may look simpeler than OAuth-1 for specific use cases but it really is a much broader and more complex framework than OAuth-1.

    Only a very limited subset of OAuth-2 may be considered simpeler than OAuth-1, but then the API would not really be OAuth-2 anymore as it is
    not complete.

    The generic access token idea can be used in OAuth-1 as well : in your example the myawesome3dprintingsite.com has its regular OAuth-1 Consumer
    Key but also requests an Access Token. This is the generic access token.
    The Access Token is used by myawesome3dprintingsite.com to upload its users' creations to the "My Awesome 3D Printing Shapeways shop" at
    Shapeways. There is no OAuth exposure to the myawesome3dprintingsite.com users here.
    Set the model upload to Shapeways to 'private' and use the secretKey which the API returns with which the user can get access to the model to order it.

    -- Hans
     
  3. Well, the idea would be that you wouldn't need to request it in code. You'd be able to just copy it from the same page that you copy the app key and secret and possibly even revoke it and get another one if needed. They you wouldn't really even need to know anything about OAuth, you could just make requests with your access token to use the API.

    But anyway, since that's not an option currently, how does a server request an access key from Shapeways? Doesn't it still need to jump through the same hoops that a user would have to? So the server would make a request for an access token, it would get redirected to login and then asked for permission to allow the app access and then you'd finally have an access token? Or is there an end point that can avoid the redirect loop by logging in directly?
     
  4. hans_lambermont
    hans_lambermont Shapeways Employee Dev Team
    Hi jallwine,

    Here's a workaround for you :
    - Download the API reference clients from https://github.com/Shapeways/shapeways-api
    - Save the Consumer Key you got from https://developers.shapeways.com/manage-apps and save it in php-pecl/consumer_key.php
    - Use php-pecl/Authorize-oauth1-pecl.php to get an Access Token

    Use this Access Token as a generic Access Token together with the Consumer Key in myawesome3dprintsite.com to use the Shapeways API.
    The users of myawesome3dprintsite.com do not have to deal with anything OAuth and can order the models you uploaded to Shapeways for them (from myawesome3dprintsite.com) via the secretKey feature.

    -- Hans
     
  5. This seems like a security hole to me. Since the API isn't over SSL the access token and key is sent in plain text so then anyone who knows how to sniff packets could gain access.
     
  6. hans_lambermont
    hans_lambermont Shapeways Employee Dev Team
    Hi jallwine,

    That is correct. Though the private key parts of the Consumer Key and the Access Token are only transmitted once ever, and in your case only between Shapeways and myawesome3dprintsite.com . The RFC has this to say on the matter "the server MUST require the use of a transport-layer mechanisms such as TLS or Secure Socket Layer (SSL) (or a secure channel with equivalent protections)." Securing this is on my todo-list. Here's more on OAuth1 security -> http://tools.ietf.org/html/rfc5849#section-4

    Btw, you might be interested to know that Oauth-2 is considered less secure than OAuth-1 by the former OAuth-2 lead author, see http://en.wikipedia.org/wiki/Oauth#Controversy

    -- Hans
     
  7. Hm, well I'm not all that concerned with the specifics. I've just used OAuth 2.0 in the past and it requires SSL. If you feel OAuth 1 is better, that's fine by me, but adding SSL would make me feel a lot better! Any idea when that might get rolled out?
     
  8. Also, I understand that the private key is only transmitted once, but does the access token need to be sent every time? And the access token gives a lot of permissions to anyone with it. So ideally, that would be transmitted over SSL.
     
  9. hans_lambermont
    hans_lambermont Shapeways Employee Dev Team
    Hi jallwine,

    We're certainly looking into improving the security as well as the user and developer experience.
    Adding a subset of OAuth-2 has always been an interesting option and I hope we do get to adding it.
    The OAuth-1 generic Access Token procedure I described above should allow you to proceed. Right ?

    -- Hans
     
  10. Yes, thanks you! This will definitely get me started.
     
  11. hans_lambermont
    hans_lambermont Shapeways Employee Dev Team
    The Access Token consists of a public/private keypair. Only the public key is transmitted on every API request, together with the public key part of the Consumer Key. The private key parts are used to digitally sign the API call and the Shapeways server validates the signature on every request.
    This is in fact much like how SSL/TLS works.

    -- Hans
     
  12. I'm not sure I follow what you're saying. If I sent you the access token that I just had generated and the consumer key of my app you would have complete access to the Shapeways API using my account. Don't I need to include both those in every request I make to the API in plain text?
     
  13. hans_lambermont
    hans_lambermont Shapeways Employee Dev Team
    Hi jallwine,

    No :) Here's why : The Consumer Key consists of a public part and a private part. Once myawesome3dprintsite.com has them it will never expose the private part to anyone. The Access Token also consist of a public part and a private part. Also for the Access Token once myawesome3dprintsite.com has them it will never expose the private part to anyone The private parts are only used to digitally sign the entire API request, that is it calculates a signature string of the API call with them and adds that signature string to the API call. So the private part of the Consumer Key and of the Access Token stay 'private' at myawesome3dprintsite.com . I hope this helps. If not feel free to ask new quesions :)

    -- Hans
     
  14. I think I'm just stuck in an OAuth 2.0 mindset. I'm used to just forming my own GET requests than I can easily test just by going to a given url in a browser or REST client. With OAuth 1.0 I guess I'm stuck using an OAuth client?
     
  15. Alright, I found a chrome app called Postman which can do the OAuth signature calculations for quick debugging. I'm up and running! Thanks Hans :)