> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-actions-triggers-prototype.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# API Access Policies for Applications

export const AuthCodeBlock = ({filename, icon, language, highlight, children}) => {
  const [displayText, setDisplayText] = useState(children);
  const [copyText, setCopyText] = useState(children);
  const wrapperRef = React.useRef(null);
  useEffect(() => {
    let unsubscribe = null;
    function init() {
      if (!window.autorun || !window.rootStore) {
        return;
      }
      unsubscribe = window.autorun(() => {
        let processedChildrenForDisplay = children;
        let processedChildrenForCopy = children;
        for (const [key, value] of window.rootStore.variableStore.values.entries()) {
          const escapedKey = key.replaceAll(/[.*+?^${}()|[\]\\]/g, (String.raw)`\$&`);
          let displayValue = value;
          if (key === "{yourClientSecret}" && value !== "{yourClientSecret}") {
            displayValue = value.substring(0, 3) + "*****MASKED*****";
          }
          processedChildrenForDisplay = processedChildrenForDisplay.replaceAll(new RegExp(escapedKey, "g"), displayValue);
          processedChildrenForCopy = processedChildrenForCopy.replaceAll(new RegExp(escapedKey, "g"), value);
        }
        setDisplayText(processedChildrenForDisplay);
        setCopyText(processedChildrenForCopy);
      });
    }
    if (window.rootStore) {
      init();
    } else {
      window.addEventListener("adu:storeReady", init);
    }
    return () => {
      window.removeEventListener("adu:storeReady", init);
      unsubscribe?.();
    };
  }, [children]);
  useEffect(() => {
    if (!wrapperRef.current) return;
    const originalWriteText = navigator.clipboard.writeText.bind(navigator.clipboard);
    let isOverriding = false;
    const handleClick = e => {
      const button = e.target.closest('[data-testid="copy-code-button"]');
      if (!button || !wrapperRef.current.contains(button)) return;
      isOverriding = true;
      navigator.clipboard.writeText = text => {
        if (isOverriding) {
          isOverriding = false;
          navigator.clipboard.writeText = originalWriteText;
          return originalWriteText(copyText);
        }
        return originalWriteText(text);
      };
      setTimeout(() => {
        if (isOverriding) {
          isOverriding = false;
          navigator.clipboard.writeText = originalWriteText;
        }
      }, 100);
    };
    const wrapper = wrapperRef.current;
    wrapper.addEventListener('click', handleClick, true);
    return () => {
      wrapper.removeEventListener('click', handleClick, true);
      if (navigator.clipboard.writeText !== originalWriteText) {
        navigator.clipboard.writeText = originalWriteText;
      }
    };
  }, [copyText]);
  return <div ref={wrapperRef}>
      <CodeBlock filename={filename} icon={icon} language={language} lines highlight={highlight}>
        {displayText}
      </CodeBlock>
    </div>;
};

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  API Access Policies for Applications is currently available in [Early Access](/docs/ja-jp/troubleshoot/product-lifecycle/product-release-stages). By using this feature, you agree to the applicable Free Trial terms in Okta’s [Master Subscription Agreement](https://www.okta.com/legal/?_gl=1*agihqh*_gcl_au*NjM2NjA1MDg4LjE3NTM5ODE4NjY.*_ga*MTgyNDA4MjM2Ny4xNzE1MTAyMjQy*_ga_QKMSDV5369*czE3NTQ0NzQ3NTAkbzM1MyRnMSR0MTc1NDQ3NjU5MCRqNiRsMCRoMA..).
</Callout>

API Access Policies for Applications enables you to control how applications access your APIs registered in Auth0. These policies define how applications interact with an API, such as whether they can successfully obtain an access token to access the API’s resources.

You can configure the application API access policy for each API registered in the Auth0 Dashboard. To learn more, read [Configure API application access policy](#configure-api-application-access-policy).

## User-delegated access vs. client access flows

You can configure separate application API access policies for user-delegated access and client (machine-to-machine) access flows:

* **Client access**: used for machine-to-machine access, which corresponds to the [Client Credentials Flow](/docs/ja-jp/get-started/authentication-and-authorization-flow/client-credentials-flow).
* **User-delegated access**: used for all access flows that generate an access token associated with an end-user, allowing the application to access an API on the user’s behalf. User-delegated access flows do not include the Client Credentials Flow. To learn more about user-delegated access flows, read [Authentication and Authorization Flows](/docs/ja-jp/get-started/authentication-and-authorization-flow).

## Application API access policies

The application API access policies are:

| Policy                 | Description                                                                                                                                                                                                                                                                                                                                                                                               | Access Flow                                                                                                                            |
| ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| `allow_all`            | When configured for an API, any application in your tenant can get an access token to the API. No specific grant is required.                                                                                                                                                                                                                                                                             | The default for user-delegated access flows when you create an API. You can only configure allow\_all for user-delegated access flows. |
| `require_client_grant` | When configured for an API, only applications with a client grant defined can get an access token for the API. The client grant establishes the maximum permissions an application can request from the API. To learn more about how to create and manage client grants, read [Application Access to APIs: Client Grants](/docs/ja-jp/get-started/applications/application-access-to-apis-client-grants). | The default for the Client Credentials Flow when you create an API.                                                                    |
| `deny_all`             | When configured for an API, no application can get an access token to the API, regardless of any other settings or grants. Access is completely restricted.                                                                                                                                                                                                                                               | You can configure `deny_all` for both user and client access flows.                                                                    |

When configuring an API’s application access policy, Auth0 recommends using `require_client_grant`, which follows a least privilege principle approach. To learn more, read [Application Access to APIs: Client Grants](/docs/ja-jp/get-started/applications/application-access-to-apis-client-grants).

When you set the application access policy for an API to `require_client_grant`, you must explicitly provide the required scopes as part of the token request. This does not apply to refresh token requests, where if you omit the scopes, the authorization server assumes the application wants all the scopes it was granted in the original access token. As a result, the authorization server returns an access token with the same scopes originally granted by the resource owner.

## Configure API application access policy

You can configure an API’s application access policy by updating its `subject_type_authorization` property on the `resource-servers` collection.

The `subject_type_authorization` object contains two nested objects, `user` and `client`, each with a policy attribute that you can set to one of the three access policies defined in [Application API access policies](#application-api-access-policies).

### Existing API

To configure the application access policy for an existing API, make a `PATCH` request to the `/resource-servers/{id}` endpoint and pass a `subject_type_authorization` object that specifies the policies for both user and client access types.

The following code sample demonstrates how to set different access policies for user and client access types for an existing API:

* The user policy is set to `require_client_grant`, meaning applications must have a client grant to access the API on the user’s behalf.
* The client policy is set to `deny_all`, which restricts machine-to-machine access to this API.

export const codeExample1 = `curl --location --request PATCH 'https://{yourDomain}/api/v2/resource-servers/{RESOURCE_SERVER_ID}' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \
--data '{
    "subject_type_authorization": {
        "user": {
            "policy": "require_client_grant"
        },
        "client": {
            "policy": "deny_all"
        }
    }
}'`;

<AuthCodeBlock children={codeExample1} language="bash" />

### New API

To configure the application access policy when creating a new API, make a `POST` request to the `/resource-servers` endpoint and pass a `subject_type_authorization` object that specifies the policies for both user and client access types.

The following code sample demonstrates how to set different access policies for user and client access types when creating a new API:

* The user policy is set to `require_client_grant`, meaning applications must have a client grant to access the API on the user’s behalf.
* The client policy is set to `deny_all`, which restricts machine-to-machine access to this API.

export const codeExample2 = `curl --location 'https://{yourDomain}/api/v2/resource-servers' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \
--data '{
  "name": "{YOUR_NEW_API_NAME}",
  "identifier": "{YOUR_NEW_API_IDENTIFIER}",
  "scopes": [
    {
      "value": "{SCOPE_VALUE}",
      "description": "{SCOPE_DESCRIPTION}"
    }
  ],
  "subject_type_authorization": {
    "user": {
      "policy": "require_client_grant"
    },
    "client": {
      "policy": "deny_all"
    }
  }
}'`;

<AuthCodeBlock children={codeExample2} language="bash" />

## Learn more

* [Application Access to APIs: Client Grants](/docs/ja-jp/get-started/applications/application-access-to-apis-client-grants)