---
title: Non-interactive applications
description: Non-interactive applications support the client_credentials, authorization_code, implicit, and refresh_token grant types to obtain an access token. For information about authentication flows for applications using the authorization_code and implicit grant types.
component: pingone-api
page_id: pingone-api:foundations:authentication-concepts/authorization-and-authentication-by-application-type/non-interactive-applications
canonical_url: https://developer.pingidentity.com/pingone-api/foundations/authentication-concepts/authorization-and-authentication-by-application-type/non-interactive-applications.html
---

# Non-interactive applications

Non-interactive applications support the `client_credentials`, `authorization_code`, `implicit`, and `refresh_token` grant types to obtain an access token. For information about authentication flows for applications using the `authorization_code` and `implicit` grant types.

|   |                                                                                                                                                                                                                                                                                                                                                          |
| - | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|   | When configuring an internal application, the grant type must be a `client_credentials` grant. Internal applications using a `client_credentials` grant do not call `/{{envID}}/as/authorize` to initiate an authorization request. They bypass the authentication flow steps and call the `/{{envID}}/as/token` endpoint directly to acquire the token. |

The following sample shows the `POST` request to the `/{{envID}}/as/token` endpoint to acquire the access token. Note that the application must have its `tokenEndpointAuthMethod` attribute value set to `client_secret_post`.

```bash
curl --request POST \
  --url 'https://auth.pingone.com/{{envID}}/as/token' \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data 'grant_type=client_credentials&client_id={{appID}}&client_secret={{secret}}'
```

The request URL contains the following parameter values:

* `grant_type`

  Specifies the grant type for the authorization request, which for non-interactive applications must be a `client_credentials` grant. This parameter is required.

* `client_id`

  Specifies the application's UUID, returned from a `GET /environments/{{envID}}/applications/{{appID}}` request. This parameter is required.

* `client_secret`

  Specifies the application's client secret, returned from a `GET /environments/{{envID}}/applications/{{appID}}/secret` request. This parameter is required.

For `client_credentials` requests in which the application's `tokenEndpointAuthMethod` attribute value is set to `client_secret_basic`, the `client_id` and `client_secret` attributes cannot be part of the request body. In these cases, the `client_id` and `client_secret` are passed in as a Base64 encoded authorization header in the request:

```bash
curl --request POST \
 --url 'https://auth.pingone.com/{{envID}}/as/token' \
 --header 'Content-Type: application/x-www-form-urlencoded' \
 --user 'client_id:client_secret' \
 --data 'grant_type=client_credentials'
```

The `--user 'client_id:client_secret'` option tells curl to use a BASIC authentication header with the specified credentials in the request, which is similar to this:

```none
Authorization: Basic <base64 encoded "client_id:client_secret">
```