OAuth App – Authorization Code & PKCE Setup

PKCE Overview

Proof Key for Code Exchange (PKCE) is an extension of the OAuth 2.0 Authorization Code flow that enhances security for public or mobile clients that cannot safely store a client secret. It adds a verification step between the authorization request and token exchange to prevent intercepted authorization codes from being reused by malicious actors.

You should use PKCE if your application is a mobile app, single-page app (SPA), or any client that cannot securely store a client secret. If your application is a traditional server-side (confidential) client, you can continue using the standard Authorization Code flow.

📘

PKCE (RFC 7636) is also available to developers as an extension of the authorization code flow. To enable it, toggle PKCE in the App details page.

⚠️

Once PKCE is enabled, the application can only use the PKCE workflow. If PKCE parameters are not provided, the authorization code flow will fail. To switch back the toggle, the application should have no active keys.

Step 1. Consent URL

Once your app parameters are set, you can implement the authorization code flow.

Consent URL

To request access, create a Consent link that redirects the user.

📘

Authorization Code vs. Client Credentials Consent URLs

If you're familiar with the Client Credentials workflow, you might notice that the Generate Consent URL button is not present in the partner portal for the authorization code workflow. This is because, with the authorization code method, you need to provide a redirect URI specific to your organization. Therefore, these URLs must be configured directly within your workflow.

⚠️

If the redirect URI is not declared in the application, the redirection will be blocked.

You will need to construct a consent URL similar to the example below while passing the required parameters for your application:

https://consent.criteo.com/request?response_type=code
&client_id={client_id}
&redirect_uri={redirect_uri}
&state={state}

With PKCE Enabled

If you have PKCE enabled, then the consent URL will require additional parameters:

https://consent.criteo.com/request?response_type=code
&client_id={client_id}
&redirect_uri={redirect_uri}
&state={state}
&code_challenge={code_challenge}
&code_challenge_method={code_challenge_method}

Step 2. Exchanging Access Code for Access Token

With an authorization code, you can request an access token via the following POST request:

curl -X POST https://api.criteo.com/oauth2/token \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=authorization_code
&code={code}
&redirect_uri={redirect_uri}
&client_id={client_id}
&client_secret={client_secret}"

📘

You can find more details about the OAuth endpoint in our API Reference.

With PKCE Enabled

If you have PKCE enabled and made the consent request with PKCE parameters, your access token request must have one more parameter, which is code_verifier:

curl -X POST https://api.criteo.com/oauth2/token \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=authorization_code
&code={code}
&redirect_uri={redirect_uri}
&client_id={client_id}
&client_secret={client_secret}
&code_verifier={code_verifier}"

Example Request

curl -L 'https://api.criteo.com/oauth2/token?grant_type=authorization_code&client_id=<MY_CLIENT_ID>&client_secret=<MY_CLIENT_SECRET>&redirect_uri=<MY_URI>' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'client_id=<MY_CLIENT_ID>' \
-d 'client_secret=<MY_CLIENT_SECRET>' \
-d 'redirect_uri=<MY_URI>' \
-d 'code=<MY_CODE>' \
-d 'grant_type=authorization_code' \
-d 'code_verifier=<MY_CODE_VERIFIER>' # only with PKCE enabled

Example Response (Success)

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "token_type": "bearer",
  "expires_in": 3600,
}

Parameters