Register API Clients

Security: These domains in the System functional area:

Set Up: Tenant Setup - Security

Security Administration

Workday supports OAuth 2.0 as part of the Workday API Infrastructure. OAuth 2.0 enables Workday users to authorize third-party clients to access their Workday data securely on their behalf.

To access the Workday API, register OAuth 2.0 clients with Workday. You can enable OAuth 2.0 clients to access the Workday API for each tenant.

Access the

Edit Tenant Setup - Security

task.

In the

OAuth 2.0 Settings

section, select the

OAuth 2.0 Clients Enabled

check box.

Access the

task.

Enter the

Client Name

Select the

Client Grant Type

Opción	Descripción
Authorization Code Grant	Use for clients that can persist data, such as mobile applications.
Implicit Grant (Do Not Use)	Necessary for applications that don't include a server-side component, such as JavaScript applications. Workday plans to retire this client grant type in a future release. We recommend that you use these client grant types instead: Authorization Code Grant with PKCE support. JWT Bearer Grant.
JWT Bearer Grant	Use the JSON Web Token (JWT) for clients such as your Salesforce integration. This grant type enables you to restrict the exchange of security assertions for access and refresh tokens to Integration System Users (ISUs) you select in the Integration System User field. Provide an x509 Certificate for validating signatures. You can also select the Allow Integration Messages check box to ensure that Workday receives necessary information about the status of the integration.
SAML Bearer Grant	Use for applications that use SAML SSO for authentication. Also select an Assertion Verification . Select: Use Configured IdPs to use the X.509 public certificate of the SAML IdP configured on Edit Tenant Setup - Security for validating signatures. The issuer in this case is the IdP. Use Certificate (x509 option) to specify an x509 Certificate for validating signatures. The issuer in this case is the API Client ID. You can also optionally select ISUs in the Integration System User field, to restrict the exchange of security assertions for access and refresh tokens to those ISUs. You can also: Select the Allow Access to All System Users check box to enable all users, rather than just Integration System Users (ISUs), to use the SAML bearer assertion flow. Select the Allow Integration Messages check box to ensure that Workday receives necessary information about the status of the integration.

(Optional) Select the

Support Proof Key for Code Exchange (PKCE)

check box when using the

Authorization Code Grant

client grant type to add PKCE support to your client.

PKCE enables the client to mitigate the threat of having the authorization code intercepted. Select this check box if the client will be supporting Cross Origin Resource Sharing (CORS)-enabled cross-origin requests.

(Optional) Select the

Enforce 60 Minute Access Token Expiry

check box to enable the API client to return bearer tokens that:

Have a 60-minute expiry.

Don't invalidate when sessions end, as long as they haven't expired.

Once you select this check box and click

, you can't clear it.

Select an X.509 public key in the

x509 Certificate

field.

This field is active when you select:

Jwt Bearer Grant

as the

Client Grant Type

SAML Bearer Grant

as the

Client Grant Type

and

Use Certificate (x509 option)

as the

Assertion Verification

(Optional) Select 1 or more ISUs in the

Integration System User

field.

This field displays when the

x509 Certificate

field is active. If you don't select any ISUs in this field, the API client won't restrict access based on ISU user accounts. If you select 1 or more ISUs, sign-in attempts using other users will fail. Workday recommends that you restrict the access of the client to specific ISUs.

Select the

Access Token Type

Opción	Descripción
Bearer	Enables simpler development.
MAC (Do Not Use)	Provides increased security. Workday plans to retire this access token type in a future release. We recommend that you use bearer tokens instead.

Enter the

Redirection URI

Use a comma as the delimiter to specify more than 1 redirection URI.

For

Authorization Code Grant

client grant types, only secure URIs starting with https are valid.

For

Implicit Grant

and

Authorization Code Grant

with

Proof Key for Code Exchange (PKCE)

enabled, only secure URIs starting with https and custom domain URIs are valid. Example: officeconnect://test.com and https://google.com.

(Optional) Select the

Refresh Token Timeout (in days)

. You can select a value between 1 and 365 days. The default value is 30 days. Refresh tokens are rate limited to 1 token per second, per user.

(Optional) Select the

Non-Expiring Refresh Tokens

check box to prevent the refresh token from timing out.

(Optional) Select the

Disabled

check box to prevent the client from requesting access to Workday.

Select the

Grant Administrative Consent

check box when you want to grant OAuth consent to a REST API Client tenant-wide. When selected, users don't need to grant client access explicitly to Workday functional areas.

From the

Scope (Functional Areas)

prompt, select the functional areas to which your OAuth 2.0 client requires access.

Select the functional areas that Workday enables for the Workday REST API. Also select the functional areas for the domains of any custom objects to which you might require access. Use caution to expose only those functional areas that you specifically require access to.

(Optional) When your OAuth 2.0 client requires access to core Workday domains that aren't in any functional areas, select the

Include Workday Owned Scope

check box.

(Optional) When you want Workday to authorize OAuth 2.0 client access only from specified IP address ranges, select the ranges from the

Restricted to IP Ranges

prompt.

You can also select

Create IP Range

to create a named, comma-separated list of IP addresses using one of these formats:

X.X.X.X.

CIDR notation. Example: 192.168.0.1/24.

X.X.X.X - Y.Y.Y.Y.

Workday has a limitation on IP ranges that include a dash. If you experience sign-in errors in the

Signons and Attempted Signons

report after you begin using an IP range that you entered in that format:

To see if the range breaks down to a series of smaller segments, use a tool that converts IP address ranges to CIDR notation. Such third-party CIDR calculator tools are available online.

Reenter the

IP Range

in Workday as a comma-separated list of the segments returned by the tool. Example: 199.67.128.0/18, 199.67.192.0/24 or 199.67.128.0-199.67.191.255, 199.67.192.0-199.67.192.255.

Add a row to the

Allowed Origin

grid for each domain enabled for cross-origin requests. The domains must start with

https://

chrome-extension://

and use the CORS format.

Workday might add CORS headers when responding to cross-origin requests from

Allowed Origin

domains. Workday only supports cross-origin requests for clients using the Authorization Code grant type with PKCE support.

Workday generates a Client ID and a Client Secret for the OAuth 2.0 client. Copy the Client Secret before you navigate away from the page, and store it securely. If you lose the Client Secret, you can generate a new one using the

Generate New API Client Secret

task.

Workday can deliver OAuth 2.0 clients as part of an update. All OAuth 2.0 clients delivered by Workday are disabled by default.

If you want to generate a new Client Secret for an OAuth 2.0 client:

Access the

Generate New API Client Secret

task.

Select the

API Client

from the prompt.

Select the

Confirm

check box.

When the OAuth 2.0 client is already in use, generating a new Client Secret will cause the client to become unusable.