Inbenta offers a range of products that allow you to create Chat apps, manage searches and contents, or set up agents to support your clients and end-users. A critical element in all these integrations is the security of your user accounts and your data. Inbenta uses a number of APIs to authorize and authenticate users, and gives you several ways to implement these processes. This gives you greater control over the level of security of your integration, based on your actual needs. 

The purpose of this section is to present and explain the different authorization processes that Inbenta works with and the different security implications of each solution. Inbenta strongly recommends that you get familiar with, and understand, the following concepts.

Types of integrations

For the purpose of this document, integrations must be considered from two different perspectives:

The source of the API Requests

There are two types of integrations, depending on the origin of the request to the Inbenta APIs:

• Server side integrations: The requests to the API are executed in the server. This is the most secure scenario, as the API data is not exposed to the end users.
• Client side integrations: The requests to the API are executed in the browser (usually through the SDKs provided by Inbenta). You must be careful not to expose sensitive data in this scenario, because it can be seen by the end users.

The nature of the data

There are two types of integrations, depending on whether you consider the data completely public or not:

• Public data: All the data that the API returns is considered public. This means that any end user with access to the internet can search and consult this data.
• Private data: All or some of the data must be visible only to authorized users. The integration provides a way to restrict which users can see what data. Inbenta does not provide this kind of feature in the API endpoints.

With these concepts clearly defined, you can now look at the Authorization flows available.