Introduction

The Criteo API allows you to build custom apps that help the world's advertisers grow their businesses. So whether you are a brand, agency, retailer or 3rd party partner, the Criteo API supports different authentication methods that fit your application needs.

When getting started, in order for your application to function, your users will have to delegate permissions for one or more of the Criteo advertisers that they oversee.

Criteo supports OAuth client credentials and authorization code grant types. On this page, we will explain the benefits of each grant type to help you make the best decision that fits your application needs.

---

NOTE

In this guide, we assume you have created a developer account, and your application has access to a organization within Criteo. Instructions for getting started can be found here.

---

OAuth 2.0 Grant Types

Criteo offers OAuth client credentials grant types

Client Credentials

Client credentials grant type is intended for simple API connections and for apps that are granted consent to one or a few advertiser accounts. This grant type involves authenticating the client (application or service) itself rather than an end-user. It makes it particularly suitable for machine-to-machine communication or server-to-server interactions.

Additionally, client credentials are tied to a specific client application or service; using this grant type helps isolate the resources accessed by different applications. Each application can have its client credentials and associated permissions, so if you plan to have different applications with different levels of permissions, this may be a better option.

• Case scenarios: The Client Credential workflow is most appropriate when the data owner and the application developer is the same, or when there is only a single data owner. There is no segregation of data depending on which account is being accessed.

For more information check out the app setup process for Client Credentials

Authorization Code

The Authorization code grant type follows the process of obtaining an authorization code by exchanging it for an access token. This grant type is used when an application needs access to a user's (resource owner) resources and performs actions on a user's behalf.

The application initiates the authorization process by redirecting the user to the authorization server's login page. After successful authentication and authorization, the user is redirected to the application with an authorization code provided by the authorization server.

The application will proceed to exchange the authorization code for an access token and a refresh token. The access tokens will then allow the application to access user-specific resources.

It's worth noting that the authorization code grant type may introduce additional steps or complexity compared to the client credentials grant type, especially in terms of managing the authorization code and token exchange process. However, it offers features that are particularly suitable for scenarios where user consent and interaction are required.

• Case scenarios: The Authorization Code workflow is most appropriate when the application owner is managing data for more than one data owner. This is because this workflow segregates data behind separate access tokens that the client API application manages. The data is segregated through the consent-granting process, with each consent granter’s data being bundled together.

For more information check out the app setup process for Authorization Code