Restrict Delivery API access using API key — give us feedback
Good news for those of you, who hijack the Preview API to provide private content or who turn down deals because of the Delivery API being public-only. We are up to introducing security mechanism that allows you to secure your inventory and provide paid or member-only content. So, let me validate our design with you using this article.
In short, we plan to add the possibility to enable a Delivery API key. As a result, all Delivery API requests are going to need to bear an API key, similarly to the case of the Preview API. However, this enabling Delivery API key will have the following impact on your website's architecture:
- Server-rendered apps (e.g. .NET MVC) — Your server app will communicate with Kentico Cloud using the API key. Since you will not share the API key, no one else will have access to your Delivery API. If your project requires managing app users and roles, you will need to implement it individually because Delivery API contains only a single API key without the native ability to handle roles.
- Client-rendered apps (e.g. React) — Your React app will communicate with a proxy service developed by you. It might be a small node.js server that proxies all website requests and securely communicates with the Cloud's Delivery API.
> Note that the Delivery API security will be opt-in. Therefore, it can't break your current app and you can decide if and when you want to introduce security.
To summarize, all Delivery API requests will need to go through a server proxy. So, there is one important performance impact for the client-rendered apps. In order not to leak Delivery API key, even public content such as homepage will need to go through a proxy, without getting the content from our high-performance CDN. In practice, if you needed to get secured content with the global availability and speed of our CDN, you might end up integrating with your own CDN.
Potentially, we might implement a functionality which allows you to define that specific section of content inventory such as items of specific content types or items assigned to specific sitemap locations should remain accessible without the API key (publicly).
- What content should remain public? Why?
Last but not least, assets need to be secured as well. However, an asset URL contains it is ID. Since there's no asset listing endpoint, the asset ID can't be guessed so quickly. Therefore, as long as the asset is a part of member-only content items, it remains private.
Let us know your opinion on the new secured Delivery API idea. Honest feedback is more than welcomed. Feel free to comment here or reach out to me at firstname.lastname@example.org.
Stay tuned for other Kentico Cloud improvements!