We are continuing our API Interview series, in this second interview we chat with Ben Ashing one of Cyclr’s Developers. We are talking about his experiences with an array of API integrations and API authentication types.
API Authentication Type Interview
How many types of API Authentication have you worked with?
I’ve worked with a fair amount of available authentication types, from OAuth1, OAuth2, HTTP Basic, API Key, to more obscure solutions such as Kerberos, AWS Security Token Service and custom implementations.
We regularly work with HTTP Basic, a simple auth scheme that sends the users username and password credentials in an authorisation header as a Base64 encoded string. We also use OAuth 2.0, an open framework for authenticating an API where the user swaps their credentials for a token which will then be to authenticate the API calls.
Within Cyclr we have the templates set out for the most common types which allow us to easily setup connector authentication in most cases.
Do you have a preferred authentication type to work with? If so, which type and why?
The easiest API authentication type would probably be API Keys, as you just plug it in and go. However, this ease of implementation introduces a myriad of potential security holes.
For security and relative ease I would always rather work with OAuth 2 authentication, when implemented to the standard, due to the security benefits. It tends to be fairly easy to work with due to most working from the standard spec, however some make changes which can trip you up. I’ve had some where they’ve added non standard fields that have caused a lot of problems in the past.
OAuth also has the added benefit of scoping so can limit permissions to certain aspects of the API for added security.
If you were designing a new API which authentication type would you use to provide the best user experience?
Unless I was creating an API for an internal use case, something that I’d only be using in my home for example, I’d most likely use OAuth2.0 authentication type.
Whilst it’s fairly complicated to set up properly, it’s easy to connect to and offers a decent level of security.
What type of API authentication do you find most problematic?
Mainly when an API implements its own unique authentication method, which often aren’t particularly secure, and are often poorly documented.
The authentication scheme that caused me the most problems was Amazon’s AWS Security Token Service which we implemented for our S3 Connector. However, with the difficulty to implement comes a great measure of security which is vital when considering the type of data that is often stored with AWS.
If you were to create your perfect API authentication type what features would it include?
If I’m completely honest, I wouldn’t want to build an API authentication type from scratch.
Authentication is tough and should only be tackled in-house if you really know what you’re doing. If not, there are plenty of secure ready made solutions which implement the security features for you.
If your API is going to be used externally and you don’t have the credentials to secure your API with a homebrew solution, just use OAuth2. If you are going to implement your own auth type, you should document it well.
If you are using our Cyclr platform or just interested in how it works feel free to check out our documentation.
Looking for more about working with APIs, read our two other interviews with members of Cyclr’s connector development team where we talk about the challenges of working with APIs, and the do’s and don’ts of API documentation.
