APIs have established and solidified a place in business model reshaping as they make data, mobile and cloud applications, and Internet of Things (IoT) more available to larger audiences. Delivering the clearly structured configurations and flows, APIs turn a service or app into a scalable, secure, and reliable system. Thus, the digital era brought technological enhancement along with the skills to crack the open systems, networks, and APIs aren’t the exception.
During few hours the personal data, trade secrets, as well as private information, can be disposed if your API security is poorly planned and implemented. The malicious assaults and Denial of Service (DoS) attacks are growing threats to enterprises back-end systems. Kicking off new initiatives should be walked through simple, actionable techniques that actually correlate with product strategy and doesn’t violate the company and customer data.
What Stands behind “API Security”?
Companies adopting new tactics to stay relevant and APIs come as a double-nature thing: (a) they drive innovations and enhancement along with (b) opening a vulnerability spot by providing the programming access to the external developers. For good note-taking, if your organization relies on the network solutions in securing APIs, you should be surprised at having API breach in the system.
Building the API strategy and architecture of the app or solution, ensure the API security matter takes the place of a major element. The concept isn’t new, as APIs themselves, but there is shared a perpetuate an understanding of security as the ‘fit-all-sizes’ approach. Indeed, APIs utilize the web technologies over the internet and developers are destined to deal with the common web threats.
The unique nature of RESTful API expands the risk area by enabling API consumer with
the wider and deeper exposing of back-end functionality, and
more flexibility in data type and amount fetching than web applications do.
Many security woes of API space depend on how actually the APIs were written (i.e. they can expose the back-end data, architecture, etc.) There are 4 aspects required to build the efficient API security strategy: authorization, authentication, federation, and delegation. Plus, the clear understanding of protocols, methodologies, and concepts backs up the growth-oriented business development.
Authentication vs. Authorization Controversy
The security breaches and hackers attacks are neither desirable nor appropriate for business models. So, the authorization and authentication are forming the separate layers, yet they are often got misunderstood or thought about as similar notion. In a way, our tech savviness started to work against us, the figuring out the exact meaning for relevant applying into the API security, and strategy.
Authentication deals with the identifying the party requesting the access. Roughly speaking, this is a form that demands the name and password to ensure the 2 aspects:
(a) the user is identified as only this very user (i.e. John Doe is identified as John Doe), and
(b) the user is allowed to get the access.
You can also use the various protocols, sign-in or verification services to lead the safe trip down the highway to your APIs.
Authorization checks what the access rights the requester has. In contrast to authentication, that verifies who is the requesting party; the authorization defines what access level should be provided for this very user.
It is critical to note that this step in API security is overlooked. Usually, API developers provide the users with the full access while the average consumer may require fewer calls and functions than a developer. So, continuing this line of thought, the leaving the access operations open drives system vulnerability and encourage hacks and unauthorized access.
Federation & Delegation: Shedding Light on Credential Set
The credentials are a mere cog in a complex, multi-facet Internet space. Nevertheless, this very thing plays a critical role in a security of data, and API security as well. Applying the federation helps to reduce the extra data entrance, and allows the user to utilize the same set of credentials across multiple services.
What does it mean? Once you have authenticated in a domain, other realms (i.e. security domains that support single sign-on) that trust this primary domain may reuse the authentication as they depend on the established identity authenticity. So, any system of the specified federation will accept the credentials of the identity provider (primary domain).
The term delegation describes itself to some extent. This is another security process allows offering the limited amount of access and rights to the authorized users. Contrary to the federation that supplies you with a token to utilize in multiple domains, the delegation gives a partial authorization and treats you like another user.
To cut it short, under the federation, you log on a specially designed page for getting the access to the available resources in this very federation by means of the granted token. While under the delegation system, the site which you are trying to log on will search for the given rights and on behalf of whom you are acting. With that information in hand, make sure you include these aspects into API security development.
Reaching out oAuth Characteristics
Being a part of securing your APIs, the oAuth can be named as a “meta-protocol” that builds a foundation for other protocols. This security layer helps API providers to deal with
(a) the delegated access,
(b) the reducing the password sharing, and
(c) the revocation of access.
The oAuth allows the user to revoke the access to a certain app preserving the connection to other apps that are supposed to work on the behalf of this very user. In essence, this API security element gives a delegated access for use when the actual user is absent on the client and requested resource. So, it enhances the authorization while impacts negatively on authentication.
This oAuth can be represented by the following 4 main actors:
Resource Owner is an entity that controls the exposed data by the API (the end user);
Client is an app or website, etc., that tries to access in aid of the resource owner;
Authorization Server is a server that requires tokens;
Resource Server is a service that exposes API, data, etc.
Plus, the oAuth provides the 2 types of tokens:
Access token (you present it to the API) creates a kind of session when a user log on the app, and it supports the interaction until this session is expired;
Refresh token (is used to receive a new access token from authorization server) plays a role of a password the user needs to keep in the secure place. If this token is lost, there must be the revocation of all performed consents.
It’s also important to build a shared understanding of the oAuth use cases during proceeding with the API security tactics. Here are few points to consider:
oAuth isn’t used for authorization as it says absolutely nothing about the users and their presence.
The authentication via oAuth may lead to breach if the data are valuable.
oAuth also shouldn’t be used for federation.
Authorization Matters in Data2CRM.API
Inspiring innovations and transformation, the APIs also should provide the security and encourage the problem-solving experience. Keeping the idea of user-centric service in mind, Data2CRM.API offers its users the authentication and authorization to ensure the security of their credentials and data.
Getting down to the point, let’s define how exactly these aspects are implemented. For the authentication, you need 2 parameters in the header of a request.
X-API2CRM-USER-KEY defines the client who makes the request. It must be used for all requests sent to Data2CRM.API. Besides, this key is always can be found on your API Credentials Page at the Developers’ Portal.
X-API2CRM-APPLICATION-KEY defines the application you are going to work with. It must be used for all resources apart from application and platform. This key is automatically created and given to you after the performing the successful request to add a CRM platform into Data2CRM.API system.
API security, as well as APIs themselves, is a highly elaborative environment, and each CRM platform has its own peculiarities. Regarding these systems specifications, Data2CRM.API enables the 4 types of authorization of the supported CRMs:
Key: you need to provide the API key or API token of the CRM platform;
User: requires a CRM email and a password to authorize;
oAuth internal: consists of (a) instance URL (to which API call should be sent), (b) access token (acts as a session ID that the application uses for making requests), and (c) refresh token (that can be used in the future to obtain new access tokens).
- oAuth external refresh: consists of (a) instance URL (to which API call should be sent) and (b) access token (acts as a session ID that the application uses for making requests).
While with the key and user type things are fairly clear, the oAuth internal runs authorization process via Data2CRM.API app and oAuth external refresh does it via your app. Check out the sample how this can be done on Salesforce:
During the oAuth internal authorization, you need to redirect the user to https://api.api2crm.com/authorization/oauth/Salesforce/authorize?redirect=<redirect>. Here <redirect> stands for the address where we should drive the user back and transfer into URL hash the authorization parameters: instance_url, access_token, refresh_token. After that, they can be used as the access credentials for Data2CRM.API system. That allows us to refresh the authorization parameters on our side by using refresh_token.
During oAuth external refresh authorization, you need to receive the access parameters using <a href="https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_understanding_web_server_oauth_flow.htm" target="_blank">this instruction</a>: instance_url, access_token, refresh_token. After that, instance_url and access_token can be used as the access credentials for Data2CRM.API system. When the access_token expires, the system will give the authorization error, and then you will need to renew access_token by means of refresh_token. So make sure you have saved this token outside the system.
When you get the new authorization parameters, you should update them in Data2CRM.API system. Use "Update application information" methods for that.
Another thing worth to highlight is despite the type of authorization you use, the role of the user influences on the sent API calls. It means that all the capabilities: create, view, edit, and delete records via API will be equal to the permissions granted to this very user.
API Security as a Strategic Endeavor
The data comes ahead as a differentiating force in business, and both - privacy and security matters play a vital role in the service providing. Here, at Data2CRM.API, the CRM API integration is built on the innovative and security-focused approaches. Data2CRM.API stores all fragile, personal data using TLS 1.2 + SHA-256 with RSA Encryption and SSL connection.
The high-quality service and API security represent an integral part of the SaaS; there is three-layer protection on
physical layer (security logs, 2-factor authentication, and processes tracking to guarantee the maximum security),
network layer (proven practices and preventive measures against network firewalls DDoS prevention, and network posture assessment), and
application security (HTTPS-encrypted communication, role-based authorization, and validation of all requests).
Aiming to prevent any vulnerabilities of the system, the team runs security audits on the regular basis. Besides, Data2CRM.API is constantly updated, and all the connections to the previous version are limited, logged and checked.
The CRM API integration service ensures the seamless and secure connection to multiple CRMs and complies with the requirements you meet in the scalable business infrastructure. You can register for a free trial or contact our expert and figure out more about the integration development.
Improvements in any area can result in deterioration in others if you neglect the wider scope. The API strategy allows you reap the substantial benefits, yet it also involves planning, execution, iteration, and security. Ensure your APIs have corresponding security levels, and let them be a valuable advancement instead of a short-sighted innovation.
Latest posts by ivan (see all)
- API Design Recap: Lessons Worth Remembering [Infographic] - July 7, 2016
- How Lead Generation Can Benefit with CRM Integration - July 5, 2016
- Reasoning for Sales Enablement Integration with CRM Development - June 27, 2016