As a part of creating an origin, you will provide us with credentials to access your data store. Needless to say, this information is highly sensitive.

Cloud State doesn't permanently store these credentials in our own servers.

Instead, we (oversimplifying this a bit):

1. Encrypt your credential
2. Break it into two parts
3. Send you the first part, and we store the second part

This ensures that even if the token or our encryption keys were compromised, the 3rd party cannot decrypt the token without having access to your part of the token, our database that stores the token, and the encryption key.

We expect the token to be passed in via the Authorization header for every read and write.

We conduct just-in-time decryption and parsing of the token to satisfy the reads and writes.

We may store the encrypted token in our replication queue for up to a few minutes, until the replication is complete.

Generating multiple tokens per data store

You can generate as many tokens as you want per data store, with different settings. Cloud State doens't impose a theoretical limit on the number of tokens you can generate.

Generating read-only or write-only tokens

If you want to generate tokens that can only read, or only write, you can do so via generating a token that has the corresponding access level credential, embedded in the token.

For example, if you want to generate a read-only token for an S3 bucket, you can do so via generating AWS credentials for the said S3 bucket that has only the required permissions.