We are building an API and I am confused as to what kind of security we need? There are so many out there being used (OAuth 1.0a, OAuth 2.0, SAML, username/password, API Key, JWT, and plenty of others) and I am not sure what the best practices are for implementing API authentication. What advice to you have?
— OVERWHELMED BY SECURITY OPTIONS
There are several things to take into consideration when looking at security for APIs and it is important to make sure it aligns with your organization’s overall security strategy.
Let’s look at a few of the most frequently used methods of API authentication.
You may be thinking about opening up your API to everyone with no security. I would not do this. API security risks are more common than you think. Even if your data is non-sensitive and you may not care who sees your data, you should be thinking about rate limiting in order to protect your resources.
Instead, look into using
API Key, which I talk about next.
This is an option if the data you are presenting is non-sensitive. An
API Key is a unique value generated for use by an API client.
API Key is not really authentication as it is a way of filtering requests by client. You still have no idea who is using your API with that
API Key. Adding an
API Key requirement to your API will at least allow you to limit the number of requests per registered client.
Allowing the client to reset the API Key is an important feature as the key might become compromised.
Most APIs will require true authentication which is when a lot architects find themselves looking at
OAuth 2.0 which I cover next.
You will see this form of Authentication used on a lot of APIs. This involves an end user authenticating and getting a token that can be used by the client to authenticate with your API. I won’t go into details here as the
OAuth 2.0 process can be challenging to understand if you’re new to this. I will tell you that there are several different OAuth flows and you will need to work with your
OAuth 2.0 provider to see which flows they support.
OAuth 2.0 does have flows that support server-to-server communication but not all organizations and providers will have these flows enabled.
The one downside to some
OAuth 2.0 flows is that it can get pretty ugly. You probably have some awesome designs showing a nice branded login flow for your app or website. But the reality is you will get thrown out of that into something much less branded before completing and getting back to your app.
The other downside is the additional screens themselves. Depending on what the timeout is for your app or website. You might have 3-5 screens and a lot more clicks just to open a link.
There is not much you can do about the downsides as security is more important than aesthetics.
My only point to pointing out the downsides is that you do want to be aware of what
OAuth 2.0 flows are supported (and enabled) for your API and what it means for your clients if they are turned off.
Some APIs authenticate with username and password, often in the form of Basic Auth in the header. Even when combined with SSL, this is not a recommended solution for securing your API. You will often see this with older APIs that were created using a webpage paradigm. This also often led to APIs being created that were session-based (or worse, session-based with cookies).
Speaking of session-based APIs. Please don’t do this! RESTful APIs are designed to be stateless!
If you are thinking about doing this, first see if your API falls into the one exception to this rule:
THERE IS NO EXCEPTION.
Don’t do it.
For the love of all that is good. Just don’t.
Here are a few of the other authentication methods you might find out there.
|JWT||Uses a JWT to authenticate. Easy to setup and use but user must manually manage token creation, etc. More secure alternative to API Keys.|
|OAuth 1.0a||Less secure than OAuth 2.0. Just use OAuth 2.0|
|SAML||Used for some SSO system. Difficult to use and manage for APIs|
API Authentication Recommendations
OAuth 2.0but with flows enabled to support server-to-server, device authorization, etc., so you can ensure your API Client are secure while also enabling a great user experience!
- Use API Key authentication with caution if publishing non-sensitive data
- Avoid username/password authentication.
- Avoid maintaining state in your API calls.
Ask-a-Geek questions are answered by Brenton House, an API and Mobile Geek who has been working in the development community for 25+ years.
Want to learn more about practical to-do’s when developing APIs? Read the top 10 security considerations for APIs.