Updated on by Daniel Twigg
Continuing our API Interview series, this month we speak to Ben Ashing, one of Cyclr’s Connector Development Team, about his experiences with an array of API authentication types.
How many types of API Authentication have you worked with?
I’ve worked with a fair few of the available authentication types. Anything from OAuth 1, OAuth 2, 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, and 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 would probably be API keys. 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 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 safety.
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.
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. 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?
Ha! If I’m completely honest, I wouldn’t want to build one from scratch!
Authentication is a beast 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 OAuth 2.
But if you are going to implement your own auth type, please document it well.