Service API key

[fflorent]

Currently a user is offered the ability to create an API key so they can connect their external applications to Grist. This key grants the same access than the user one.

However, in some case, one may wants to:

• create an API key with restricted access for security concerns;
• be able to create an API key for each app which would use the Grist API (so they can be revoked at some point by the user);

Also it would be great to assign these keys a name so the user can identify which API key is used for which app.

What do you think?

---

TODOs:

• [ ] Back-end implementation + API + header support
• [ ] UI / UX implementation

[paulfitz]

Agree that it would be desirable for a single user to possess a set of keys, the have some overall control over limits that apply to those keys, and to name them. We did the bare minimum we could get away with for Grist so far. I think we've gotten away with it for so long only because it is easy enough to create extra users with distinct api keys, and control access granted to those users. But that isn't particularly convenient.

[combinatorist]

Seconding this as a consultant who frequently builds Grist docs and integrations for clients. Easiest if I can fully hand them off when I'm done, but that would mean giving me their grist API key up front. Alternatively, I would set it up with mine, which could potentially access other clients. I'll pursue a service email address only for this purpose and see how easy it is to transfer in the integrations accounts (Pabbly) after the fact (without breaking any workflows). That should be safe enough if I only have one client at a time and remember to transfer at the end, but it's a little gross.

For my use case, it would be sufficient to add API keys for each document (since integrations only access one anyway) and then I could hand off in an appropriate way. Perhaps only owners of the doc could view, refresh, or revoke api keys - IDK. But, it might not work for more granular/complex restrictions.

[combinatorist]

I was pleased to see Grist accepts username+tag@gmail.com so I don't even need separate email addresses to get my separate API keys. :)

[CamilleLegeron]

I will begin to work on this feature My idea is to create docAPIKeys that are new api keys that allow the use to only make requests on the specific doc linked to the docAPIKeys. What the user can do on this specific doc will be based on the user rights. With this docAPIKeys the user will be not able to make request on api/profile/apikey or orgs/ etc.. @fflorent @vviers @paulfitz seems to be a good first step to you ?

[paulfitz]

If the keys are just for a specific doc, you could very nearly do this with the new shares table. The structure of that table is:

• A key
• A doc id
• A link id
• Some options

You could add an apiKey flag to the options which, if set, meant the key could be used as an api key. There's already an access level option that can be viewers or editors.

The only weird thing is the link id. It is there as part of WYSIWYS plans, to allow shares to be configured within a document, and for the configuration to follow a document if it is duplicated or moved between installations. That has proven useful for forms, but not sure if it matters for the use-case in this issue.

I just mention it because if you use shares a lot of things will "just work" that could take quite a lot of time to implement again. But if in future api keys might operate at a level beyond individual documents, it is a bad match, and a dedicated api_keys table might be the way to go, with some keys restricted to individual documents.

[CamilleLegeron]

After some reflection it seems to be a good options, and the document level it's the use case of service API key. Wdyt about adding the UI/UX of this functionality in the settings page inside the API part, and only owners would have the ability to see it ?

[vviers]

Our plan is to implement #1217