Feature Request: Custom API KEY

[bboure]

In the Api Gateway service, you can easily create custom Api keys with a specific value (See AWS::ApiGateway::ApiKey)

That is something that is currently missing in Appsync (See AWS::AppSync::ApiKey)

It would be useful to be able to set API keys with custom values, to ensure that re-creation of the service will not break any client using those keys.

This is slightly related to https://github.com/aws/aws-appsync-community/issues/5 In general, AppSync is currently a quite dangerous service to use if for any reason the API needs to be re-created.

EDIT: In addition to this, I would like to add that we need true unauthenticated access with AppSync. The only only reason we use API_KEY is because we need anonymous access to the api. I know using API key is the "recommended"way of handling unauthenticated access, but this sounds more like a workaround to me. Api key, by definition, IS authentication. This has already been discussed many times. The api key solution comes with several issues. One of them is what I just described in this post.

[Sunac]

• 1 for custom API KEY. Have that issue now, due to recreation. Custom domain is fine for the switch to new service, but losing the existing key will break clients.

[Sunac]

I think this feature is essential. In the last few weeks, we hit several CloudFormation limits so needed to recreate the stack and apply a better split map. And since we have several different clients with the keys generated for each of them, we had to overcome this issue by adding logic in lambda@edge that will switch their keys with the new one, because it wasn't possible for them to change it at that moment when we had to do stack switch without any production issue. Luckily, in front of our API is CloudFront with the lambda@edge so this was possible, otherwise, we'll be in real trouble.

[dmr121]

@Sunac The scenario you described is the exact same one that I'm facing right now. Could you explain how you switched the keys with lambda@edge?

[Sunac]

@Sunac The scenario you described is the exact same one that I'm facing right now. Could you explain how you switched the keys with lambda@edge?

Of course, @dmr121. Basically, we already had CloudFront in front of our AppSync with lambda@edge already in place for some other reason, so we reused the same lambda for switching keys as well. So the setup is as follows:

• CloudFront -> Origin -> add custom headers with e.g. new-key(s) and old-key(s) as a key-value pair. We need this as lambda@edge doesn't support environment variables so this was the way to pass a different set of keys per env. -> Behaviours -> attach your Origin request lambda@edge
• Lambda@Edge Origin request with switching logic that gets your keys from a request origin custom customHeaders and sets new value in a x-api-key header e.g. delete headers['x-api-key']; headers['x-api-key'] = [{ key: 'X-Api-Key', value: yourValidApiKey, }];

Before returning a request, you could delete your customHeaders from a request if you don't want to expose it, pay attention to methods as you probably want to exclude OPTIONS from this switch, validation, or whatever is important to you.

This way, your clients don't need to change their keys as key switching will be done before request reach AppSync.

[dmr121]

Thank you so much for the quick reply and explanation! This is very clear and will be incredibly helpful. Appreciate it!

On April 4, 2022, GitHub @.***> wrote:

@Sunac https://github.com/Sunac The scenario you described is the exact same one that I'm facing right now. Could you explain how you switched the keys with @.***?

Of course, @dmr121 https://github.com/dmr121. Basically, we already had CloudFront in front of our AppSync with @.*** already in place for some other reason, so we reused the same lambda for switching keys as well. So the setup is as follows:

• CloudFront -> Origin -> add custom headers with e.g. new-key(s) and old-key(s) as a key-value pair. We need this as @.*** doesn't support environment variables so this was the way to pass a different set of keys per env.  -> Behaviours -> attach your Origin request @.***
• @.*** Origin request with switching logic that gets your keys from a request origin custom customHeaders and sets new value in a x-api-key header e.g.   delete headers['x-api-key']; headers['x-api-key'] = [{ key: 'X- Api-Key', value: yourValidApiKey, }];

Before returning a request, you could delete your customHeaders from a request if you don't want to expose it, pay attention to methods as you probably want to exclude OPTIONS from this switch, validation, or whatever is important to you.

This way, your clients don't need to change their keys as key switching will be done before request reach AppSync.

— Reply to this email directly, view it on GitHub <https://github.com/aws/aws-appsync-community/issues/130#issuecomment- 1087766154>, or unsubscribe <https://github.com/notifications/unsubscribe- auth/AKWMT5UZ4ZTJXGESYMPIJZLVDMKB5ANCNFSM4Q2UCVTQ>. You are receiving this because you were mentioned.Message ID: <aws/aws- @.***>

[Sunac]

@dmr121 you're welcome. Glad if it helps :)

[jzybert]

Any update on this? It would be a very helpful feature in order to rotate the API key automatically

[jbschooley]

I would love this too. I need to move our AppSync to a separate stack, but doing so will break clients because we can't customize the key. Additionally, there isn't a warning when an API key is deleted, so it's too easy to accidentally wipe the key and you can't get it back...which means possible emergency work as the frontend team stays late to build a new version of the app and then a few days of downtime while Apple and Google approve the update.

Interestingly enough, you can specify an ApiKeyId in cfn to make changes to it, but that isn't exposed to the cdk L2 construct, and if the key doesn't already exist it'll throw a NotFoundException.