---
category: [Administration & Integrations, Platform and Product Extensions, Platform and Product Extensions/Integration, Administration & Integrations/Custom Integrations & Apps, Platform and Product Extensions/Workday Extend]
keyword: [Extend, OAuth]
nav: wcp_docs
parent_url: /wcp_docs/
title: Authenticate Using PKCE with the Authorization Code Grant Type
layout: subsection
---

### Prerequisites

<a id="prereq_N10022_N1001F_N10001"></a>
[Register your API Client](/wcp_docs/zwx1518028675482.html) on the Workday Developer Site.

### Context

<a id="context_N10029_N1001F_N10001"></a>
The Proof Key for Code Exchange (PKCE) extension describes a technique for public clients to mitigate the threat of having the authorization code intercepted.

When the app initiates the authorization request, instead of immediately launching a browser, the client first creates a code verifier. This is a cryptographically random string between 43 and 128 characters long. The code verifier can use alphanumeric characters and the hyphen, period, underscore, and tilde punctuation characters.

After the client has created the code verifier, it uses this to generate the code challenge. The code challenge is a base64URL-encoded string of the SHA256 hash of the code verifier. The client includes the code challenge and a parameter that indicates the method used to generate the code challenge (SHA256) in addition to the standard parameters of the authorization request.

### Steps

1.  <a id="step_N10035_N10032_N1001E_N10001"></a>Submit the initial request to the authorize endpoint. Use these query parameters:

    -   response_type: `code` (for authorization code grant).
    -   client_id: Use the value received at client registration.
    -   redirect_uri (Optional): Indicates the URL to return the user to after authorization is complete. Use the value you configured on the client at registration.
    -   code_challenge: The `code_challenge` is a base64URL-encoded string of the SHA256 hash of the code verifier.
    -   code_challenge_method: `S256` (for the SHA256 hash of the string).
    -   state: A random string generated by your app, which you’ll verify later.

    Example:

    ```
    GET https://auth.api.workday.com/v1/authorize?response_type=code&client_id=ODQ4ZDdkNzItMzhiMC00YmFmLTgyNzAtNzljNjM0MDlmNmY2&redirect_uri=https://example.com&code_challenge=base64URL-encodedStringGeneratedFromcode_verifierHash&code_challenge_method=S256&state=xyz
    ```

    The authorization server accepts the `code_challenge` parameter in the request, and associates that with the authorization code it generates. The server returns the authorization code, and doesn't include the challenge in the data returned.

    For this example, the redirect URI was set to https://example.com during client registration:

    ```
    HTTP/1.1 302 Found Location: https://example.com/#code=88xr1xk2snm6u6pk5yc6yqef0&state=xyz
    ```

2.  <a id="step_N10123_N10038_N1001F_N10001"></a>Build the Authorization header.

    Encode the Client ID value into Base64 format, and then populate the header of the request with `ID [Encoded Value]`. You must add a space after ID. Populate the header of the request with:

    -   Content-Type: `x-www-form-urlencoded` (specifies that the values will be encoded inside the URL itself).

3.  <a id="step_N100B2_N1004A_N1002D_N10001"></a>Build the Authorization body.

    Populate the body of the request with the:

    -   grant_type: `authorization_code` (indicates the grant type of this token request).
    -   client_id: Use the value received at client registration.
    -   redirect_uri (Optional): Use the value you configured on the client at registration.
    -   code: The authorization code returned from the authorization endpoint in the previous step.
    -   code_verifier: The cryptographically random string that was used to generate the `code_challenge` passed to the authorization endpoint in the previous step.

    The authorization server also validates the `code_verifier` in the request by calculating the SHA256 hash of the verifier, base64URL encoding it, and then comparing it to the stored `code_challenge` string.

    -   If the `code_verifier` matches the expected value, the server issues an access token.
    -   If the `code_verifier` doesn't match the expected value, the server issues an `invalid_grant` error.

4.  <a id="step_N10163_N10038_N1001F_N10001"></a>Submit the POST request to the token endpoint. Example:

    ```
    POST https://auth.api.workday.com/v1/token 
    ```

    ```
    Authorization: Basic ID T0RRNFpEZGtOekl0TXpoaU1DMDBZbUZtTFRneU56dE56bGpOak0wTURsbU5tWTI6YmtteGNveWg1M29kOXg3dmZ6andvbWVoN2ozejJwZ2hucHRpeHdmcHB5eGxmeG8ybDY0bmx1M3V2aTR5bGgxNXphZGZ0YXB3dnBibTk4bmFrMjZ2OGpwamQzNnhyanlu== 
    ```

    ```
    grant_type=authorization_code&code=88xr1xk2snm6u6pk5yc6yqef0&client_id=ODQ4ZDdkNzItMzhiMC00YmFmLTgyNzAtNzljNjM0MDlmNmY2&redirect_uri=https://example.com&code_verifier=asDfghJKLpOiUytreWQzxcVbnm0987654321awsedRFtgyhu
    ```

    The token endpoint returns the access token and refresh token:

    ```
    {
        "access_token": "7c3obrknwd6nnkxv0r64jdpbx",
        "refresh_token": "yxsiqvdkakj0tp9a4i2xe1fbg4blgrq1noqz2nt1cr4f8dfjpazw0jwe18a2wn656854pzb5vmcqnhpqspytg0cf5jlidyjgnfg",
        "token_type": "Bearer"
    }
    ```

5.  <a id="step_N1007F_N10032_N1001E_N10001"></a>To subsequently access Workday resources, set the Authorization header in the requests you send to the Workday REST API endpoint. Set the Authorization header to the token_type value and access_token value. Example:

    ```
    GET https://api.workday.com/common/v1/workers Authorization: Bearer 7c3obrknwd6nnkxv0r64jdpbx
    ```

    The token timeout is tied to the session timeout configured for the user by the Workday administrator. When the token expires, submit another request to the authorize endpoint.



### Related Information

[Reference: Workday Extend API Gateways and Authorization Base URLs](/wcp_docs/dlh1653340161856.html)

[Proof Key for Code Exchange by OAuth Public Clients](https://tools.ietf.org/html/rfc7636)