API Key Security Considerations

In a previous post, I gave a few hints about API Key security. In this post, I'll expand on those hints to give a more comprehensive list of security considerations for handling your API Keys. But first an executive summary so you can decide whether you want to read on ...

An API Key is the mechanism by which your application identifies itself to the Autodesk Forge server. If someone gets hold of your API Key, then they can access all of the data you stored using that key, and can also make API calls that consume your cloud credits (i.e. they can spend your money). If your data is valuable, and you don't like people spending your money, then you should protect your API Keys.

Or - to put it another way -

How many people do you share your online banking login with?

All of the considerations I list below are some form of the Principle of Least Privilege. The Principle of Least Privilege is that you only ever give someone enough access to your systems and data so that they can perform their job, and only for the length of time needed to do that job. As an example of this principle in a non-software environment, the last car I bought had two 'normal' keys (one for me and one for my wife), and a 'valet' key. The normal key gives me access to everything - driving, unlocking the glove box, unlocking the fuel cap, opening the trunk. The valet key allows the car to be driven a short distance, but it won't open the glove box, fuel cap or trunk. (Ferris Beuller's Day Off must have made a big impression on me when I was young).

#1 - Limit the number of people who have access to your API Keys (or create Apps in Forge parlance).

That means limiting access to your Forge developer account where keys can be created or viewed (and copied). But it also means limiting who can embed an API Key into your production applications, or see the API Keys that someone else has embedded. 

It may be very convenient to give your entire development team access to your Forge account by sharing the username and password for your Autodesk Id. That way, anyone can create an API Key whenever they need it - and without having to ask you to do it for them. But everyone who has access to your API Keys also has access to all the data you've stored using those keys.

• What if a disgruntled employee deletes all your API Keys before they leave your company, which causes you to lose access to all your stored data?
• What if one of your developers accidentally uploads a key to a public GitHub repository with some source code they wanted to share?
• What if an employee falls for a phishing attack, and hands over an API Key to a hacker?

You might want to give more than one person access to your Forge account - people go on vacation and get sick sometimes - but don't give it to everyone. And make sure you explain your security rules to anyone you do give access.

#2 - Store your keys securely.

Your application will have to access its API Key in order to use the Forge APIs, but make sure you store the key in a secure place. For example, encrypt a key you store in a desktop application or use a proxy server. Similarly, when issuing a new key to someone, consider how you'll securely send them the key. (Hint - Is email really a secure communication mechanism?)

Once upon a time, a new member of my team was learning node.js. He was really proud as he showed us the live sample he'd just launched. Until his colleague pointed out that he'd put all his source code and API Keys into a publicly-readable folder on his webserver. (No-one in the team ever made that mistake again).

#3 - Use one API Key per application.

(And - depending on your applicaton architecture - possibly one API Key per 'customer/user').

You want to limit the damage caused should a hacker steal the API Key from one of your apps, or if one of your developers accidentally posts it on StackOverflow. If you use a single API Key for all your web applications, then one API Key being compromised means someone can access all your web applications. But if you use a different API Key per web application, then you only have to update the one application that used the compromised API Key. (And you only have to notify the users of that one application that their data might have been stolen).

#4 - Regularly regenerate your Secret Key.

Just like you should regularly change your personal passwords, you should regularly regenerate your API Secret Key. Consider implementing a process to do that at least every three months. 

Note that your public (consumer Key) will stay the same. There is a 'regenerate secret' button on the 'Edit App' page on the Forge developer portal.

#5 - Limit the 'scope' of your API Keys.

When you create a new App on the Forge developer portal, you can select the Forge APIs that the App will have permission to access. For example, if you only select the Design Automation API when creating your App, then you can never use that API Key to Access the Model Derivative API, or the Data Management API, etc. (Unless you later edit it to add access to more APIs).

Similarly, when you use your API Key to 'authenticate' your application, the authentication process gives you an Access Token that you use to prove your application's identity when making any Forge API call. During this process, you specify the 'scopes' (or permissions) for the Access Token. Permissions include read, write and view. For example, when using the Forge Viewer to display a file, you should scope the Access Token you generate for the Viewer only for 'view' (not 'read' or 'write'). This ensure that, for example, that Access Token can't be used to list and then download all the files you're storing on the Autodesk server.

This is important, because if a hacker manages to get hold of an Access Token, then they can use it for 60 minutes before it expires. If you had enabled all APIs for your API Key and enabled all 'scopes' during authentication, then the hacker has full access to your data and can call any APIs until the token expires.

#6 - Use Separate 'Development' and 'Production' API Keys.

When your programmers are developing a new application, they won't necessarily know which APIs they will need. You also might not want to be pestered for a new API Key every time a developer wants to try an experiment. To make life easier for you, you might consider creating a few fully scoped API Keys that your team can use (and reuse) during the development phase. 

However, if you do this, you should replace your fully scoped development key with a brand new (least privilege scoped) key when you move your application to production. 

And you should still regularly regenerate the Secret keys for your 'development' API Keys.

#7 - You should only ever pass your Secret key during authentication.

The most important part of your API Key to protect is your Secret Key. You will only ever pass this to the Autodesk server during the authentication process. Never attach your secret key to any other API calls, and always use HTTPS in your API calls (including if you're communicating with a proxy server you've setup).

#8 - Some data can only be accessed using the API Key used to store it.

If you're using two-legged authentication and storing data on the Forge Object Storage Service, then you can only access your data using the same API Key you stored it with. If you accidentally delete your API Key, then you've lost access to your data.

This is an important point to remember when you switch over from a 'development' API key to a 'production' API Key.