Introduction
As with web applications, APIs operate on the web, but many require some sort of authentication or authorization before you can access the valuable resources available within each API path. API providers use a variety of different authentication mechanisms to make sure that only the applications and systems that should have access are able to successfully make an API call.As a means of bringing new life into API authentication. Depending on the API provider, platform, and the types of resources being made available, you will encounter a variety of authentication methods which are applicable to both rest and soap API, such as API keys, Basic Auth, HMAC, and OAuth.
Defining Terms
- Authentication: Refers to proving correct identity
- Authorization: Refers to allowing a certain action
Different types of authorization
API Keys
For most APIs, registering an API key is a prerequisite to using the API. The API key can be included in the URL or request header in two ways.User identification is usually accomplished by using an API key (authenticating you to use the API). As an alternative, an app can be registered with a unique API key. To approve requests, APK keys make use of a header property string.
Public and private keys may be provided through APIs. The private key is solely used for server-to-server communication and is not often provided in the request.
Basic Auth
An alternative to the more traditional forms of permission is known as Basic Auth.A username and password pair is included in the request headers when this technique is used.
For security reasons, the username and password are encoded using Base64, which transforms the username and password into a set of 64 characters.An example of a request header using Basic Auth is as follows:
Authorization: Basic bG9sOnNlY3VyZQ==
An HTTPS connection will be required for any APIs that require Basic Auth to work, which means that the content of messages will be encrypted.In the absence of HTTPS, anyone might easily decipher the user name and password.
Upon receipt, the message is decrypted and examined by the API server.Finally, it makes a decision on whether or not to accept or refuse it after decoding the string and examining user and password information
The Base64 encoding is handled automatically by Postman when you submit a login and password and choose Basic Auth.
The Base64 encoding is handled automatically by Postman when you submit a login and password and choose Basic Auth.
HMAC(Hash-based message authorization code)
Authentication using HMAC, or hash-based message authorisation code, is more frequent in financial APIs since it is more secure.
HMAC uses a secret key that only the sender and receiver have access to.A message is created by the sender based on the properties of the system (for example, the request timestamp plus account ID).
Afterwards, the secret key is used to encrypt the data, which is subsequently hashed using a highly secure technique (SHA).Signatures are stored in the request header and are the result of a cryptographic hashing operation.
In order to reconstruct the hash, the sender and receiver must each know the secret key.Not even the requester has access to the private key.You can use HMAC security if you want to confirm that the request is authentic and has not been tampered with at the same time.
In order to reconstruct the hash, the sender and receiver must each know the secret key. Not even the requester has access to the private key.You can use HMAC security if you want to confirm that the request is authentic and has not been tampered with at the same time.
OAuth 2.0
In order to authenticate and authorise users, OAuth 2.0 is one of the most commonly used options.An authentication server communicates with the API server in order to give access to this method.
When we're logging in to a site using a service like Twitter, Google, or Facebook, we're likely to see OAuth 2.0 pop up.
There are mainly two varieties of OAuth -
1. One-legged OAuth - You can use one-legged OAuth when you don't need to protect sensitive data.It's possible that this is the case if you're only trying to retrieve read-only, non-sensitive data.
2.Three-legged OAuth - A three-legged OAuth is used to protect sensitive information.
Three groups are interacting in this scenario:
a .The authentication server
b .The resource server (API server)
c .The user or app
Here’s the basic workflow of OAuth 2.0:
First, the consumer application sends over an application key and secret to a login page at the authentication server. If authenticated, the authentication server responds to the user with an access token.
The access token is packaged into a query parameter in a response redirect (302) to the request. The redirect points the user’s request back to the resource server (the API server).
The user then makes a request to the resource server (API server). The access token gets added to the header of the API request with the word Bearer followed by the token string. The API server checks the access token in the user’s request and decides whether to authenticate the user.
Access tokens not only provide authentication for the requester but also define the permissions of how the user can use the API. Additionally, access tokens usually expire after a period of time and require the user to log in again.
Authorization based on OWASP 10
Broken Object-Level Authorization
Object identifiers used to access resources are frequently exposed by APIs. When access control is not properly implemented on these endpoints, broken object-level authorisation occurs.The attackers can then access resources that they should not have access to.
Example - https://api.example.com/v1.1/users/payment_methods/show?user_id=1237962
Using object-level authorization flaws, an attacker may be able to access, update, remove, or create data without the owner's consent.An exposed critical object, such as user PII and credentials, could result in a data breach or the denial of service attack on the system. Attackers may be able to get millions of bank account data, credit card numbers, and addresses from an online shopping site, for example.If this flaw was discovered on a bank's website, hackers would have access to everyone's credit and tax information.
Broken Function-Level Authorization
Authentication based on OWASP 10
Applications that don't properly restrict access to sensitive functions are known as "function-level authorization broken."
An example of this flaw is when an unauthorised user can gain access to restricted or sensitive functions that they are not supposed to have access to. It's possible for a non-admin user to edit another user's account, or for a non-admin user to have access to administrative functions on a site.These problems stem from a lack of or a misconfiguration of access controls.
Broken user Authentication
This vulnerability can be exploited if an API's authentication procedures are incorrectly configured.One mistake could allow attackers to take over users' accounts and gain access to data and features that are supposed to be secure.
APIs have a difficult time with authentication.Many API calls cannot be secured by requesting user credentials or utilising multi-factor authentication.As a result, API systems frequently use access tokens to verify the identity of their users.In each API call, tokens are inserted into the code.It is possible for an access token to be compromised for a variety of reasons, including incorrect generation, invalidation, or compromise by another vulnerability.These flaws could be exploited by attackers pretending to be someone else.
Consequences if an API lacks security
The purpose of requiring API authentication is a mystery to me.
Authentication is not always necessary for read-only APIs. In most cases, commercial APIs require some form of authentication in the form of an API key or other method.In the absence of API security, users could use your API indefinitely without registering.Allowing unrestricted access to your API would complicate your business model.
Requests cannot be linked to specific users if authentication is not used.Mischievous or nefarious users could easily delete the data of another user (for example, by making DELETE requests on another account).Finally, you couldn't track who was using your API or which endpoints were the most popular.There's no denying that API developers have to think about authentication and authorization when creating new APIs.For the following purposes, API authentication and authorization are necessary.
- Restrict API usage to only authorised parties
- Track who is making the requests
- Track usage of the API
- Any requester who exceeds the rate limit will be blocked or throttled.
- Apply different permission levels to different users
Conclusion
There is a difference between authentication and authorization when it comes to protecting an application.Verifying the identity of an entity it claims to be is what authentication is all about.When determining whether an entity can perform a specific action or access specific data, the process of authorising that entity is called "authorization".Requests cannot be linked to specific users if authentication is not used.
By making DELETE requests on another user's account (for example), a malicious user would have access to the data of the other user. API’s should be well secured as they may be entry points for malicious hackers. We here at Briskinfosec, secure your API with a thorough VA/PT & deliverables like none other. Reach out to us for mor information.
