Contact Us 1-800-596-4880
  1. Homepage
  2. Access Management
  3. Connected Apps in Anypoint Platform
  4. Anypoint Platform Connected Apps for Developers

  5. Creating Connected Apps in Anypoint Platform

Creating Connected Apps in Anypoint Platform

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. 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.

  • 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

      Based on the grant type you select, additional information might be requested. For more information about grant types, see 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.

  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.

  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:

For more information and examples on how to use each grant type, see the Connected App Examples 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.

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:

    Attribute Description

    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.

Endpoint Scopes

Most of the scopes in the discovery endpoint 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.

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:

<anypoint-signin scopes="full"
redirecturi="...."
clientid="….">
</anypoint-signin>

For more information about how to embed the button, see the developer playground.

See Also