Store different third party API keys/credentials using SSM parameter store

Question

I have a SAAS based application on AWS cloud built using AWS Amplify as server less technology. I am utilizing at least 2-3 third party services like WordPress, JWplayer and communicate via their APIs to carry out any operations on them and for which I require API credentials. Since, this is a multi tenant application hence for each user I have separate user accounts for the third parties as well like User A of my application has accounts for both WordPress and JWPlayer and User B has different accounts on these third party apps. Hence, User A and B have different API credentials for their third parties. I want to securely save and retrieve the API credentials for each user in my application level. I have explored SSM parameter store in order to store and retrieve the credentials as something like an object:

{
    "[email protected]" : 
                     {
                           "wordpress_api_key": "abcd",
                           "wordpress_api_value": "1234",
                           "JW_api_key": "qwer",
                           "JW_api_value": "5422",
                      }
}

I am thinking of having the object containing the different API credentials for each separate user put as the one above in the SSM parameter store and further retrieved via the unique email id in my Lambdas and react front end using an SSM library.

Or is there a better way of doing this? Like storing in DynamoDB in encrypted form and retrieving it from their and then decrypting?

Answer 1

I would stick to Parameter Store because it provides out-of-box and transparent encryption support, well integrated with KMS.

As to the storage scheme, there are a few different ways to store them. You could create a tree of Parameter Store entries, and store each key or value individually as a SecureString parameter, e.g.:

/myapp/user-key/wordpress/key
/myapp/user-key/wordpress/value
/myapp/user-key/JWAPI/key
/myapp/user-key/JWAPI/value

I personally would prefer the above option as it is flexible and lets you access each credential separately. You can also store non-credentials as String entries so they won't go through encryption. But there is a limit of 10k parameters per account, so if you are expecting handle lots of users, you might go over the limit.

Another option is to store an entire user "profile" as one entry, as you alluded to in the question. This option is less flexible because you always have to retrieve/save the entire object even only some part of it changed. While this option allows you to store more user profiles before you hit the 10k limit, each user profile must be under 4KB in size as that is the AWS limit for each entry.