API Authentication - JWT vs OAuth

In my current project, we were designing a system with multiple APIs. The APIs we are building will be used by other systems as well. Whenever there is an API call we need to secure that API from external users so that we know only authenticated users are making use of our APIs and that is nothing but API authentication.

API Authentication

In simple terms, API authentication is all about proving or verifying the identity of the people accessing your system.

Its goal is to prevent attacks from cybercriminals who snoop around websites looking for the slightest vulnerability to take advantage of.
There are various methods that can help us to prevent our APIs.

Methods of API Authentication

Our requirement was quiet simple that we need to secure our APIs in a way that other systems can easily use it. But at the same time we don't want to share our username and password with other systems. Also in future there can be a case that we implement federated identity management so whatever approach we choose now for API authentication can be used when we switch to federated identities.

So taking in consideration all the requirements we drill down to two API authentication methods -

• API Key Authentication
• OAuth Authentication

In this article I will be sharing in detail about these two authentication methods.

API Key Authentication -

API Key is a code used to identify and authenticate an application or user.

IP84UTvzJKds1Jomx8gIbTXcEEJSUilGqpxCcmnx

API Keys are very simple to use from the consumer perspective:

1. You get an API key from the service.
2. Add the key to an Authorization header.
3. Call the API.

On the other hand, simplicity may raise security concerns. Here are its limitations -

• Shifting of Responsibility - What happens if someone else comes upon an API key that is not their own? In most cases, they can use the API key with all the privileges of the rightful owner. Depending on the API, they may be able to retrieve all the data, add incorrect content, or delete everything. This way the security of the system as a whole is entirely dependent on the ability of the developer/consumer to protect their API keys and maintain security.

• Lack of Granular Control -
  One precaution that some API designers take is to use API keys for read-only data. For APIs that don’t need write permissions, this is especially useful, while limiting risk. However, this approach limits the APIs that may require more granular permissions.

*What it comes down to is that API Keys are, by nature, not a complete solution. *

There comes the JWT(JSON Web Token) in picture that can be used along with API key authentication.

JSON Web Token

Both API key and JWT can provide authentication and authorization. API key is on project scope and JWT is on user scope.
A JWT token can contain information like its expiration date and a user identifier to determine the rights of the user across the entire ecosystem.

JWT authorization offers flexibility, reliability, and more security.
Any API that requires authentication can easily switch over to JWT’s authorization. With JWT authorization, you get a user-based authentication. Once the user is authenticated, the user gets a secure token that they can use on all systems. You set up access rights and you give each user different rights for each system. The JWT authorization endpoint authenticates the user and creates the token.
In sum, sometimes JWT is absolutely needed and sometimes it’s overkill.
JWT is overkill in two situations:

• A simple ecosystem with only a few APIs
• Suppliers of third-party APIs.

OAuth Authentication -

OAuth is the answer to accessing user data with APIs.

If you’ve ever seen one of the dialogs below, that’s what I'm talking about. This is an application asking if it can access data on your behalf.

This is nothing but OAuth.
OAuth is a delegated authorization framework for REST/APIs. It enables apps to obtain limited access (scopes) to a user’s data without giving away a user’s password.

You can think of this like hotel key cards, but for apps. If you have a hotel key card, you can get access to your room. How do you get a hotel key card? You have to do an authentication process at the front desk to get it. After authenticating and obtaining the key card, you can access resources across the hotel.

To break it down simply, OAuth is where:

• App requests authorization from User
• User authorizes App and delivers proof
• App presents proof of authorization to server to get a Token
• Token is restricted to only access what the User authorized for the specific App.

OAuth, specifically OAuth 2.0, is a standard for the process that goes on behind the scenes to ensure secure handling of these permissions.
With a federated system module, OAuth Authentication 2.0 offers security scalability and the best user experience.
However, it’s also more work for developers and API providers to implement and maintain.

Another tool to consider that complements OAuth 2.0 is OpenID Connect. It works as an identity layer you can deploy on top of the protocol so the API can verify a client’s identity and profile via authentication performed by the authorization server.

Conclusion

You can use any authentication method to secure your APIs but the choice should be made depending on your system's requirements.
As we have seen all these authentication methods aren't mutually exclusive so you can use all of them at once. Or, each could be used independently of the others.
But securing your APIs and choosing right level of authentication is very important.

I hope this helps you to choose better API authentication method!

Happy Reading :)