DO Ideas 2

Support multiple API keys.

Support for multiple api keys per account allows for individual revocation, and allowing access to multiple apps. Also, granting permission from certain keys, to certain servers (or multiple servers) would allow even greater control, without much added implementation.

  • Ian Wizard
  • Sep 11 2018
  • Shipped
  • Sep 11, 2018

    Admin Response

    We've shipped the new version of the API. It is now available for all customers as a beta release under the API section and documentation can be found at: https://developers.digitalocean.com With the new v2.0 API we have moved over to a fully RESTful architecture and also made OAuth the default. Customers can now create multiple access tokens to the API and specify the level of access as either READ or WRITE. With OAuth third party developers can also better leverage the API and customers can determine what level of access to grant to applications that are created by other developers. This will improve the security of the API as well as using third party applications by determining the level of trust that you want to give them. We also have a changelog up for the new API on Github along with that we are also requesting any feedback, comments, or bug reports as well: https://github.com/digitaloceancloud/api-v2 Thanks!
  • Attach files
  • Moisey Uretsky commented
    September 11, 2018 19:34

    V2 of the API is all OAuth and we will be releasing the beta test this week or next week to users who have requested access and most likely the grandfathered users as well.

    Public release to follow 2-4 weeks after we have a chance to collect feedback and flesh out all of the documentation.

    Thanks!

  • Ronen commented
    September 11, 2018 19:34

    Any ETA on oauth support?

  • Francis Lavalliere commented
    September 11, 2018 19:34

    One of the Usecase I can see, is for reselling that could ensure that the end-user get the same IP address for his droplet.

    Yes our account get the same IP but if we have 30 users creating a new droplet using our service instead of DO directly, the IP will be gave back by default to another user. Otherwise we would need to spawn the vm and leave it running in case the user wants to spawn a new VM..

    Maybe a possible option would be to add to the /droplet/new a "tag parameter" or "ip parameter" like "new", "specific", "lastused_if_available"

  • Michael commented
    September 11, 2018 19:34

    One thing of great value is to allow e.g. user "ops-centre" to have access to list machines in their console whiulst user "admin-team" have access to create and delete machines. This protects the Ops centre from accidentally deleting things they were just trying to monitor.

  • Anonymous commented
    September 11, 2018 19:34

    Any ETA on oAuth support on the API for giving third party apps the ability to spin up servers, etc.?

  • Terrence O'Connor commented
    September 11, 2018 19:34

    Yes, I would like to add that the keys should have access control levels as well. At the very least, read-only keys that can be deployed to less restricted areas to monitor machines.

  • Anonymous commented
    September 11, 2018 19:34

    I would really appreciate an OAuth way of consuming the API instead of having users copy and paste their API keys into an external service. Is there any progress or plans for this?

  • Travis Beck commented
    September 11, 2018 19:34

    I am kind of leery of using basin until I know that I won't be able to delete my droplet on accident.

  • Automatic commented
    September 11, 2018 19:34

    I would love this, I want to use my API key to control my domain's DNS, but, I don't really want the same key being able to charge me loads of money by creating loads of droplets.

  • Moisey Uretsky commented
    September 11, 2018 19:34

    Thanks for making a separate suggestion I think this will get rolled out as separate permission roles and we'll see how to integrate that with an API, perhaps a READ-Only API key can be generated so stats can be read but servers not destroyed.

  • Jean-Philippe Boily commented
    September 11, 2018 19:34

    Sorry, just saw your answer, even if it was like 4 minutes after my previous post. Probably got in my spam.

    Anyways, I think this does make sense to review the API auth to possibly use xAuth or oAuth.

  • Moisey Uretsky commented
    September 11, 2018 19:34

    Was mis-classified this was for multiple SSH keys during droplet creation.

    We are in the process of reviewing API authentication and looking into support for xAuth or oAuth to allow third party apps to be built without the need to authenticate with API credentials since those are difficult to pass into mobile apps for example, so a more refined API auth scheme is something we will add into the review.

  • Darrin Wortlehock commented
    September 11, 2018 19:34

    Please re-classify this. it is not completed, it appears it has been rejected.

  • Moisey Uretsky commented
    September 11, 2018 19:34

    Why cant you add another key?

  • Jean-Philippe Boily commented
    September 11, 2018 19:34

    Hi,
    it seems that this is marked as being completed by I can't add a second API key to my account right now as it would reset the current one. I don't see anything in API doc about that either.

    Having more than one API key is essential to me if I want to, say, test an app and revoke rights after. One API key for Android app, one for custom stuff.

    Did I miss something?

    Thanks!

  • Moisey Uretsky commented
    September 11, 2018 19:34

    SSH keys support has been added to the API through the new parameter:

    &ssh_key_ids=ssh_key_id1,ssh_key_id2,etc.

    Thanks

  • Moisey Uretsky commented
    September 11, 2018 19:34

    Hi Ian,

    Can you give me a few use cases to better understand what you are looking to achieve and how you would like this to function.

    Reason being that creating more granular access for API keys to act on specific servers would move the API interpretation out of the user model and into the droplet model to determine whether a specific key pair would have authority to act on a server.

    Given that the most common way to access this would be through a user instead it would overlap with that so it would a significant amount of overhead both in terms of code and also in maintaining the functionality going forward.

    Want to make sure that I understand the use cases first to see what's the ultimate result you are looking to achieve in the real world to see if perhaps there's another approach that could be used that would have less overhead.