--- schema_version: "1" id: d16be46f82047b35d02fd16d9772e873ff9345c04ce76b0c60c5d048e241c94d title: Creating Connected Apps in Anypoint Platform collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/access-management/creating-connected-apps-dev.md canonical_url: https://docs.mulesoft.com/access-management/creating-connected-apps-dev source_site: docs.mulesoft.com content_type: documentation content_hash: 44e610c59b09b86d9d74c883b01ce711ce5af6a31234c6dab9c54d3bb5558075 description: MuleSoft Documentation Site latest: true --- --- product: Access Management version: master --- # Creating Connected Apps in Anypoint Platform > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Create connected apps to integrate external or internal applications with Anypoint Platform using OAuth 2.0 and OpenID Connect. Configure app type and grant types, define redirect URIs and scopes, and manage credentials for least-privilege access. When you create connected apps, keep in mind: - Your organization can own up to 2000 connected apps at the root organization or business group level. - Each connected app can have up to 1000 scopes. - All scopes in the endpoint correspond directly to permissions available in Anypoint Platform, except for exceptions noted in [Endpoint Scopes](#endpoint-scopes). Scopes determine the level of permissions to provide to the app. - Your Anypoint Platform organization owns your app. Any organization administrator of the root organization or business group in which the app resides can control it. - A unique `clientID` is automatically assigned and can’t be changed. - The `clientSecret` has no expiration date by default but you can change the expiration date. ## Before You Begin - You need the Organization Administrator permission at the business group level you want to create connected apps in and specify access scopes for. For more information, see [Access Management Permissions](https://docs.mulesoft.com/access-management/permissions-by-product#access-management). - Determine whether the app is internal to your company or is a third-party app that’s distributable outside of your organization. ## Create a Connected App That Acts on Behalf of a User 1. In the Access Management navigation menu, click **Connected Apps**. 2. Optionally, select the business group to create the connected app in. 3. Click **Create App** and enter a unique name for the application. 4. For **Type**, select **App acts on behalf of a user**. 5. Select the grant types to use with the app: - Authorization Code - Password - JWT Bearer > [!NOTE] Based on the grant type you select, additional information might be requested. For > more information about grant types, see > [Grant Types and Token Flow](#grant-types-and-token-flow). 6. In **Website URL** , enter the URL where users go to learn more about the app. 7. In **Redirect URIs**, configure which URIs users are directed to after authorization. Type the URL and click **Add** to add it to the list. 8. In **Audience**, select either: - **Members of this organization only** if the app is internal to your organization - **All Anypoint Platform users** if it’s a third-party public app that can be distributed outside of your organization 9. Click **Add Scopes**. Scopes are roles with associated permissions, which determine the actions the app can perform within a business group and environment. For more information, see [Endpoint Scopes](#endpoint-scopes). 10. In **Add Scopes**, select the scopes to apply and click **Add Scopes**. 11. If applicable, select the business groups to apply the scopes to and click **Next**. 12. If applicable, select the environments to apply the scopes to and click **Next**. 13. Click **Add Scopes**, and then click **Save**. ## Create a Connected App That Acts on Its Own Behalf 1. In the Access Management navigation menu, click **Connected Apps**. 2. Optionally, select the business group to create the connected app in. 3. Click **Create App** and enter a unique name for the application. 4. Select **App acts on its own behalf (client credentials)**. 5. Click **Add Scopes**. Scopes are roles with associated permissions, which determine the actions the app can perform within a business group and environment. For more information, see [Endpoint Scopes](#endpoint-scopes). 6. In **Add Scopes**, select the scopes to apply and click **Add Scopes**. 7. If applicable, select the business groups to apply the scopes to and click **Next**. 8. If applicable, select the environments to apply the scopes to and click **Next**. 9. Click **Add Scopes**, and then click **Save**. ## Grant Types and Token Flow The OAuth framework specification describes grant types for getting access tokens for different use cases. Anypoint Platform supports these grant types: - [Authorization Code](#auth-code) - [Refresh Token](#refresh-token) - [Password](#password) - [JWT Bearer Token](#jwt-bearer) - [Client Credentials](#client-credentials) For more information and examples on how to use each grant type, see the [Connected App Examples](https://dev-portal.mulesoft.com/apis/access-management.html) in the Access Management API documentation. ### Authorization Code Use the `authorization_code` grant type to authorize the app to access a user’s data. This is an example of the development flow: 1. A developer creates the connected app that acts on behalf of a user with the `authorization_code` grant type. 2. The end user authorizes the app to act on their behalf. 3. The authorization server sends a temporary authorization code back to the specified redirect URI. 4. The app calls the authorization server with the temporary code to receive the access token. The access token can now be used to call Anypoint Platform APIs on the user’s behalf. ### Refresh Token Use the `refresh_token` grant type to grant access to user data when the user isn’t signed in. Refresh tokens expire after 90 days. Access tokens expire after the user’s session expires. To work with OpenID Connect, apps exchange refresh tokens for new access tokens after the initial authorization to continue accessing user data. If the app is using the authorization code grant type, the `offline_access` scope is required to use refresh tokens after the original access tokens expire. To request a new access token, send a request to the token endpoint using the `refresh_token` grant type. When authentication is successful, a refresh token is exchanged for an access token. ### Password Use the `password` grant type when the application exchanges the user’s username and password for an access token. > [!NOTE] This grant type isn’t recommended, as it reveals user credentials directly to the > connected app. This type also precludes the use of additional security measures, such as > multi-factor authentication. ### JWT Bearer Token Use the `jwt_bearer` (`urn:ietf:params:oauth:grant-type:jwt-bearer`) grant type when the application receives access tokens without transmitting sensitive information, such as the client secret. The `jwt_bearer` grant type is suitable for use with trusted clients to gain access to protected resources without user authorization, for example: 1. A developer creates the connected app that acts on behalf of a user with `jwt_bearer` as the grant type. 2. The JWT token exchange occurs with these claims in the payload:
AttributeDescription

iss

The issuer of the claim. This value must be same as the connected app’s clientId.

sub

The subject of the token, such as:

{version}|{identityProviderId}|{username}|{firstname}|{lastname}|email|externalgroups
At minimum, identityProviderId and username are required for sub, as these subjects identify the user in the system.

aud

The authentication server. For example, the authentication server for the US region is https://anypoint.mulesoft.com/accounts/api/v2/oauth2/token.

3. The app calls the authorization server with the generated assertion. ### Client Credentials Use the `client_credentials` grant type for machine-to-machine authentication when a specific user’s permission to access data isn’t required. The `client_credentials` grant type uses the `clientId` and `clientSecret` of the client to authorize and access protected data. To prevent service disruptions, configure CI/CD pipelines to use service accounts that call Anypoint Platform with connected apps, especially when enabling [multi-factor authentication](https://docs.mulesoft.com/access-management/multi-factor-authentication). ## Endpoint Scopes Most of the scopes in the [discovery endpoint](https://anypoint.mulesoft.com/accounts/api/v2/oauth2/.well-known/openid-configuration) map directly to existing permissions in Anypoint Platform. Other available scopes are: - `full` Full access to anything the user can do. - `read:full` Read-only access to anything the user can read. - `openid` Read-only access to the user’s username and unique Anypoint Platform ID. - `profile` Read-only access to the user’s Anypoint Platform profile. - `email` Read-only access to the user’s email. - `offline_access` Access to the user’s data when they’re not signed in. - `openid:google_wif` `id_token` and an access token used to configure Anypoint Platform as an IdP for Google Cloud during the OAuth2 token flow for `client_credentials` connected apps. This ID token conforms to the IdP requirements as outlined in the [GCP’s WIF requirements](https://docs.cloud.google.com/iam/docs/workload-identity-federation-with-other-providers). > [!NOTE] Apps that use the `client_credentials` grant type always have the `profile` scope assigned > to them implicitly. The data returned by queries uses the scope that corresponds to the user who > created the connected app. ### Access Scopes Documentation For more information about scopes and permissions in the Connected Apps feature, see the scopes documentation page in Access Management: 1. In the Access Management navigation menu, click **Connected Apps**. 2. In **Connected Apps**, click the **Scopes Documentation** tab. **Scopes Documentation** shows the scopes, their respective permissions, and the products they belong to. 3. Use the search bar and filters to locate a scope based on the name, display name, permission methods, supported app type, or product label. 4. In the list of scopes, click a scope name to view the associated permissions and learn more about the scope. You can filter and sort the contents of the **Scopes Documentation** page, and you can also click a scope name to view namespaces, methods, and actions. ## Sign In with the Anypoint Platform Widget For seamless implementation, you can integrate a button into the front end of your apps with a prebuilt template and set of components. To add this widget, use this code: For more information about how to embed the button, see the [developer playground](https://anypoint-web-components.github.io/anypoint-signin/). ## See Also - [Access Management API - Connected App Examples](https://dev-portal.mulesoft.com/apis/access-management.html) - [Anypoint Platform Connected Apps for Developers](https://docs.mulesoft.com/access-management/connected-apps-developers) - [Anypoint Platform Connected Apps for Organization Administrators](https://docs.mulesoft.com/access-management/connected-apps-org-admin)