The purpose of this page is to help you better understand when to use each Authorization flow, and how the SDKs fit in them. The following scenarios and their possible use cases are listed from the most secure to the least secure.

Full server side integration

In this scenario, the entire integration with the Inbenta API lives exclusively in a server side environment. This scenario is developed entirely from scratch and uses the Secret flow for authorization.

This is, by far, the most secure scenario.

The authorization and user process goes like this:

1. A user wants to access the integration
2. The server requests a new or refreshed access_token if needed.
3. The Auth API will return a valid access_token for the server to store.
4. The server uses the access_token to send requests to other Inbenta API.
5. The requested API returns a response (e.g. a list of found contents).
6. The server returns the request (optionally filtered or modified) to the browser. The browser shows it to the end user.

Use cases

Private data with different access levels

Inbenta strongly recommends that you use this scenario when the integration is contained behind a login screen, and some of the data that the API can return is private with different levels of access.

“Hiding” the API use in the server allows you to control who can access your content, set what kind of content they can access, and prevent data leaks. 

Higher Access Control Policies

You should consider this scenario if you need to apply restriction to how your users access the data (such as a VPN, geolocalization restriction, etc.). When you proxy the Inbenta APIs behind the server, it gives you the flexibility to apply any specific restrictions you may need.

Case Management API

This is the only scenario applicable for the Case Management API, because it literally is a “private data with different access levels” scenario as described above.

SDK Integration

As there is no API consumption from the browser, it does not make sense to integrate the SDKs in this scenario.

Mixed use: server side authorization + client side use 

In this scenario, the authorization process happens server side, but the APIs are consumed client side (preferably using the SDK). Only use the Secret flow authorization for the authorization process when you use this scenario.

This is a less secure approach than the previous scenario, but it is far more secure that using only the domain key.

The authorization and user process goes like this:

1. A user enters the integration. A javascript command sends a request for an access_token to the server (because the SDK does not do that for you).
2. The server requests a new or refreshed access_token if needed.
3. The Auth API will return a valid access_token for the server to store.
4. The server returns the access_token to the javascript. The JS builds the SDK.
5. The SDK sends a request to Inbenta APIs
6. The requested API returns the data. The SDK shows the data to the user.

Use cases

Private data with good access control

You can implement this scenario when your data is private but without different levels of access, as it provides good security and allows the use of the SDK. 

Having a large list of domains we want to restrict

If you plan to use domain keys, but the number of domains exceeds the allowed limits, you could implement this scenario and control which ones of your domains may be authorized through the server against the Inbenta Auth API.

SDK Integration

To apply this scenario, build the SDK with the createFromAccessToken method and use the access_token that the server provides. For more information, see the SDK setup page of your product.

Full client side integration

In this scenario, both the authorization and the consumption of the APIs are done in the browser client (preferably using the SDK). This means you can delegate the entire process to the SDKs. This makes it the easiest way to integrate Inbenta.

Because the SDK uses the domain key authorization flow, it is also the least secure of the three scenarios presented here.

The authorization and user process goes like this:

1. The SDK sends a request to the Auth API with the domain key to obtain a new or refreshed access_token.
2. The Auth API will return a valid access_token for the SDK to store in the browser.
3. With a valid access_token, the SDK performs requests to a specific Inbenta API.
4. The requested API returns the data. The SDK shows the data to the user.

Use cases

Private data with a good logged environment

This scenario may fit your needs if your data is private but the integration is contained behind a login screen with a good security level. Remember that this delegates the real security to your own environment.

Public data

When all your API instance data is considered public, you may use the domain key flow and the client side integration scenario. This is the fastest way you can integrate Inbenta.

SDK integration

To apply this scenario, build the SDK with the buildWithDomainCredentials method and use the domain key directly. For more information, see the SDK setup page of your product.