---
schema_version: "1"
id: ed08e247b9e2b1c319e0d55966bad6c9f3039a066824d248fd85a7e92c9ac325
title: OAuth 2.0 Dance and OAuth 2.0 Access Token Enforcement
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/api-manager/latest/oauth-dance-about.md
canonical_url: https://docs.mulesoft.com/api-manager/latest/oauth-dance-about
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 4d6f806563e6b510a698b8de59e564a8018f0e5b03cd1618e63a25ebab92b353
description: MuleSoft Documentation Site
release: 2.x
latest: true
---
---
product: API Manager
version: 2.x
is-latest-version: true
---

# OAuth 2.0 Dance and OAuth 2.0 Access Token Enforcement

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The OAuth dance is the authentication process performed by the Mule OAuth 2.0 provider, API, and
client application. This authentication process conforms to RFC 6749.

## OAuth Dance Authentication Flow

The OAuth dance authentication flow is illustrated in the following screenshot:

![oauth+policy1](/mulesoft/current/en-us/api-manager/latest/_images/mule-oauth-provider-dance.png)

1.  A token request is sent to the provider, specifying client application credentials as needed.

    The credentials correspond to a client ID and secret generated by Anypoint Platform.

2.  The Mule OAuth 2.0 provider returns a token.

3.  An HTTP request is performed against the protected resource to which the OAuth 2.0 Access Token
    Enforcement policy is applied.

    The protected resource must be linked with the API definition through Autodiscovery.

4.  The OAuth 2.0 Access Token Enforcement policy intercepts this request and communicates with the
    provider to validate the token.

5.  If the token is correctly validated:

    1.  The token is allowlisted and kept on the record until it expires.

        Any further request that contains this token is not validated against the OAuth provider.

    2.  The associated client ID of the client application credentials is verified to ensure that
        the application has an active contract with the API.

        This is not applicable to OpenAM providers.

6.  The request is then forwarded to the resource.

7.  An HTTP response is generated.

The requester obtains the authorization from an OAuth provider, instead of directly gaining access
to the credentials of the client application. The client application owner owns the credentials and
authorizes the provider to interact with the API. The protected resource determines that the user is
authorized because it has a valid access token.

## Example HTTP Request to a Protected Resource Using curl

In the following example, the protected resource is set to
`[http://localhost:8081/simple](http://localhost:8081/simple)`.

### Using an HTTP Authorization Header

```console
curl -H "Authorization:Bearer <access token>"  "http://localhost:8081/simple" -vvv
```

### Using an HTTP Query Parameter

```console
curl "http://localhost:8081/simple/?access_token=<access token>" -vvv
```

## See Also

- [OAuth 2.0 Grant Types](https://docs.mulesoft.com/api-manager/latest/oauth-grant-types-about)

- [Mule OAuth 2.0 Provider](https://docs.mulesoft.com/api-manager/latest/mule-oauth-provider-landing-page)