---
title: Worker applications
description: Worker applications are administrator applications that interact with platform APIs. This application type supports only the OPENID_CONNECT protocol.
component: pingone-api
page_id: pingone-api:foundations:authentication-concepts/authorization-and-authentication-by-application-type/worker-applications
canonical_url: https://developer.pingidentity.com/pingone-api/foundations/authentication-concepts/authorization-and-authentication-by-application-type/worker-applications.html
---

# Worker applications

Worker applications are administrator applications that interact with platform APIs. This application type supports only the `OPENID_CONNECT` protocol.

We strongly recommend that when you create your new PingOne tenant (the first time you login to your PingOne account), you create a Worker app in the intial PingOne environment (an administrator environment). Use this Worker app to create new environments, and perform other organization level administration tasks.

Each new environment you create should have its own Worker app that's used to perform environment level administration tasks (such as, create populations and users). This is in accord with the general PingOne recommendation to apply the principle of least privilege for all applications and permissions.

When creating a new Worker application, by default the application inherits the same role assignments as the actor that created the application. This is another case where the principle of least privilege should be applied. As a best practice, disable this inheritance using the `assignActorRoles` parameter when creating the Worker app. This is for security purposes, to ensure you assign only the minimal set of permissions necessary for the Worker app. Refer to [Applications OIDC settings data model](../../../platform/applications/application-management.html#applications-oidc-settings-data-model) in the *PingOne Platform APIs* for more information.

When getting a token using the `client_credentials` grant type, the application's role assignments are used.

Worker applications that use a user-based grant type such as `implicit` or `authorization_code` let you assign only OIDC scopes to the application. When getting a token using a user-based grant type, the user's role assignments are used.

The following sample shows the `/{{envID}}/as/token` request with a `client_credentials` grant to return an access token with no platform scopes.

```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 response returns the `access_token`, the `token_type`, and the `expires_in` property values. It does not list any scopes.

```json
{
  "access_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6InRlc3QifQ.eyJzY29wZSI6IiIsImNsaWVudF9pZCI6ImlkZW50aXR5LW...",
  "token_type": "Bearer",
  "expires_in" : 3600
}
```