Scoped API Access
Mark Wylde
When creating an API token, allow fine grained scoped control.
An example use case is, when using LetsEncrypt to generate your certificates, you can perform a DNS challenge to authenticate control of the domain. This adds a TXT record to your domain, confirming you have access to that domain.
You currently need to give your "god-mode" API token to do this using DigitalOcean.
With scoped access, you could create an API token with "dns:modify" and that's all that API token would be allowed to do.
This would reduce the attack surface if the API token gets leaked from your droplet.
John Mulhausen
Merged in a post:
support granular OAuth2 scopes
Jackson
Currently the OAuth2 API only supports the very coarse scopes of "read" or "read write". It'd be great if we could request much more granular scopes. Really, any more granularity would be appreciated.
In the ideal, there'd be a way to request OAuth2 permissions for a very specific set of actions, and the authorizing user can see the price upfront before accepting. Ex:
<Application> is requesting permission to
* Read account SSH keys
* Read droplet information
* Create a 100gb data Volume in SFO2
* Create a 1gb Droplet in SFO2
Total cost: $20/month.
Currently, if you're using the API to create your own one-click applications, you need to educate the user about what you'll do with the full read/write access API token & the cost of the API actions you'll take. That can be pretty tricky. DO should be the source of truth on pricing.
John Mulhausen
Merged in a post:
Fine grained API tokens
Zowie
The new API is great and being able to create multiple access tokens is too, but it feels extremely dangerous to save an API token that can potentially destroy ALL my droplets for all my clients on just a single droplet that only needs the API for a specific use case.
My example: a weekly task that consumes a large amount of memory: my client has to contact me to resize 4GB -> 32GB before initiating the task (or pay for a 32GB instance all the time, which doesn't make sense). It feels strange that I have to do all this, just because I'm refusing to do something that's dangerous.
Hope you'll be able to do something about it :-)
Merged in a post:
More Granular control of api
D
Duncan Berriman
Currently the api key is either read or write.
A more granular approach would be good which allows you to specify for each feature (snapshots/droplets/images/block storage etc) whether you have read/create/delete privilege.
So for instance you could then create an api key with access to read/create and delete snapshots but nothing else.
Merged in a post:
API - Personal Access Tokens rights enhancements in stead of only full admin rights
r
roel.vandermade@ortec.com
Currently there's no way to differentiate in rights for the Personal Access Tokens, if you create a write token, it basically is full admin access to the account. I'd like to have a possibility to limit the access to certain parts, specifically in my case to the DNS management tools. I am renewing some SSL certificates with LetsEncrypt and DNS authentication verification and am currently forced to give the renewal-script full admin rights to do so.Is there any planning to add this functionality to choose certain options with the tokens?Thanks!Roel.