Introduce Service Accounts

[vviers]

Describe the problem to be solved

Following up on #579, @paulfitz @hexaltation @jonathanperret and I sat down to outline a solution to the more granular API keys feature request. Here is what we discussed :

Describe the solution you would like

We offer to introduce the concept of "Service accounts", partly inspired by what GCP is doing

At a high level, a service account is just like a regular user in Grist -- it can be added to any number of documents, workspaces, or orgs. ACL apply to this user and it has its own API key.

Service account lifecycle

• Lyfecycle of a Service account follows the same rules as that of a user
  • The owner of a document can CRUD a Service account and add it to that document (note : technically, the user then becomes a "Guest" in the document's org/team site)
  • The owner of a workspace can CRUD a Service account at the workspace level
  • The owner of a team site can CRUD a Service account at the team site level
  • other roles (EDITOR or VIEWER) cannot CRUD a service account
• There should be an admin panel at the team site level where all service accounts in the org can be listed (along with the documents they have access to) and managed centrally by team site owners
• The Service account's API Key can only be accessed by the creator of the Service account (important : Owners of the team site should not be able to get the API key of Service accounts via the admin panel)

UI/UX considerations

• The creation panel for a Service account could be a separate panel in the "Manage users" menu
• There should be a way to describe what the service account will be used for (e.g. "Connect Grist to Mattermost", "Integrate with our marketing ETL pipeline", ...)
• The UI should make clear that Service account are robots
• The UI should show who created the service account in the first place
• The new Service account admin panel should make it easy to provision, audit and delete Service accounts
• (maybe) There should be a UI to re-generate a Service account API key (or maybe deleting the Service account and creating a new one would be enough ?)

Technical considerations

• Service account key is shown at creation time only. If you need to read it again, you should regenerate it.
• There should be a boolean column in the users table to differentiate Service accounts from regular accounts
• Service accounts don't necessarily need to have an email address, especially if Using OIDC, the email is used to identify the user instead of the 'sub' claim #759 is implemented. If they do, they could look like sa-{team-site}-{uuid}@getgrist.com

---

Here are the concrete next steps we agreed on :

• have @lusebille provide us with Figma mockups to inform our decision regarding the functionality : Provide mockups for Service accounts #1218
• have @hexaltation implement a light technical proof-of-concept for Service accounts against the API only : Make a light proof-of-concept implementation of Service accounts in the API #1219

[dsagal]

Question about regenerating keys. Firstly, creating a new service account + deleting old is not equivalent to regenerating, because the existing account could have been manually added to certain documents, or mentioned in certain access rules.

If we support regenerating the secret key and associating it with the existing service account, should we support a grace period when both keys work? For example, Stripe offers this option. Stripe calls it "Rolling API Key", it's documented here: https://docs.stripe.com/keys#rolling-keys. At the time of regenerating a new key, you get to specify expiration for the previous one, which could be "Now" or after a certain time.

Asking this now, because if we need to support two secret keys for the same service account, this may affect the schema.

[lusebille]

Just let you know mocks are linked to the ticket #1218 ( style work in progress) but close to the final version