Connected Apps for Developers

Anypoint Platform provides a comprehensive set of APIs that developers can use to extend functionality. With the Connected Apps feature, developers can delegate access to applications that use APIs to interact with Anypoint Platform programmatically. While some might use the Connected Apps feature to build CI/CD pipelines, others can productize additional third-party use-cases on top of Anypoint Platform.

In addition to enabling new flows to authenticate users, developers can enable or disable clients and view client usage. For example, developers can see how many organizations are using the app and how many users have access.

The Connected Apps feature supports OAuth 2.0 and OpenID Connect, so developers must ensure their app can use tokens to request access to user data. To find out what specific OpenID Connect capabilities are supported, refer to the information provided in the discovery endpoint. All scopes in the endpoint map directly to permissions available in Anypoint Platform, with some exceptions noted in the Endpoint Scopes section.

To foster a consistent authentication experience for end users, third-party developers with their own websites or web apps can allow users to sign in using the Sign in with Anypoint Platform option.

When you create connected apps, note the following:

Your organization can own up to 2000 connected apps at the root organization or business group levels.
Each connected app can have up to 1000 scopes.
Your organization owns your app. Any organization administrator over the root organization or the business group in which it resides can control it.
A unique clientID is automatically assigned and can’t be modified. The clientSecret has no expiration date by default but can be modified.

Before You Begin

You need the Organization Administrator permission at the level you want to create apps and specify access scopes.
You must determine whether the app is internal to your company or is a third-party app that can be distributed outside of your organization.

Create a Connected App

In the Access Management navigation menu, click Connected Apps.
In the Owned Apps section, click Create App.
In the Create App page, complete the following fields:
1. Name
  A unique name for the application
2. Type
  The type of Connected App to be created. Based on the type selected, the required fields varies.
3. Grant types
  The grant types to be used with this app.
  Note: Additional information might be requested based on the grant type you select. For more information about grant types, see Grant types and token flow.
4. Website URL
  Users can visit this URL to learn more about the app.
5. Redirect URIs
  Configure which URIs users are directed to after authorization. Type the URL and click Add to add it to the list.
6. Audience
  Configure whether the app is internal to your organization or is a third-party public app that can be distributed outside of your organization.
7. Scopes
  The level of permissions to provide to the app. Click Add Scopes to select the scopes. For more information, see Endpoint Scopes.
Click Save

The connected app ownership gets transferred to the root organization owner when the user who created the connected app:

is deleted.
is removed from the root organization.
loses administrative privileges over the organization.

Organization administrators can edit the owner of the connected app and transfer the ownership to other administrators. To do so, click the app name in Access Management > Connected Apps > Owned Apps and make the appropriate edits.

Modify the Client Secret for a Connected App

In the Access Management navigation menu, click Connected Apps.
Click a connected app from the list to enable Edit mode.
In the Secret field, enter a secret of your choice.
Click Save.

1	The name and username of the owner of the connected app
2	The name of the connected app
3	The ID of the connected app
4	The client secret of the connected app

Application Allowlist

Users with the Organization Administrator permission can enable an allowlist to control which apps can access their users' data. When your app is added to an allowlist, only the set of scopes associated with the app are reviewed and approved by the administrator. If you add new scopes to your app at a later date, you are unable to request those scopes from users until the admin re-approves your app. Existing authorizations and new authorizations using the previously allowlisted set of scopes continue to work. For more information, see connected apps for administrators.

Grant Types and Token Flow

OAuth framework specification describes several grant types for acquiring access tokens for different use cases. Anypoint Platform supports authorization_code, refresh_token, password, jwt_bearer, and client_credentials grant types. For more information and examples on how to use each grant type, see the Connected App Examples in the Access Management API.

Authorization Code

The authorization_code grant type is commonly used to authorize the app to access a user’s data. A sample flow for the authorization code grant type could be as follows:

A developer creates the connected app that acts on behalf of a user with the authorization_code grant type.
An end user authorizes the app to act on their behalf.
The authorization server sends a temporary authorization code back to the redirect URI.
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

The refresh_token grant type is used to grant access to user data when the user isn’t signed in. To work with OpenID Connect, apps have to exchange refresh tokens for new access tokens after the initial authorization to continue accessing user data. Refresh tokens expire after 90 days. Access tokens expire after the user’s session expires. 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, you must 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

The password grant type is used when the application exchanges the user’s username and password for an access token. Because the app has to collect the user’s credentials and its limitation with no mechanisms for things like multi-factor authentication, it is not recommended to use this grant type.

JWT Bearer

The jwt_bearer (urn:ietf:params:oauth:grant-type:jwt-bearer) grant type is used when the application wants to receive access tokens without transmitting sensitive information, such as the clientSecret. It is suitable for use with trusted clients to gain access to protected resources without user authorization. A sample flow for the JWT Bearer grant type could be as follows:

A developer creates the connected app that acts on behalf of a user with jwt_bearer as the grant type.

JWT token exchange occurs with the following 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, identityProvider_id 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.

The app calls the authorization server with the generated assertion.

Client Credentials

The client_credentials grant type is suitable for machine-to-machine authentication where a specific user’s permission to access data is not required. It uses the clientId and clientSecret of the client to authorize and access protected data. CI/CD pipelines using service accounts to programmatically call Anypoint Platform can be configured to use connected apps to prevent service disruptions when configuring 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 defined as follows:

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 ID.
profile: Read-only access to the user’s Anypoint profile.
email: Read-only access to the user’s email.
offline_access: Access to the user’s data when they are not signed in.
openid:google_wif: Enables you to configure Anypoint as an IdP for Google Cloud by providing an id_token and an access token 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 client_credentials grant type always have the profile scope assigned to them implicitly. The data returned by queries using the scope that corresponds to the user who created the connected app.

For more information on scopes and permissions in the Connected Apps feature, see the scopes documentation page in Access Management:

In the Access Management navigation menu, click Connected Apps.
In the Connected Apps page, click the Scopes Documentation tab.
The Scopes Documentation page appears, displaying scopes, their respective permissions, and the products to which they belong.
Use the search bar and filters to locate a scope based on the name, display name, permission methods, supported app type, or product label.
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.

For seamless implementation, developers can integrate a button into the front end of their apps with a pre-built template and set of components. They can add this widget using the following code:

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

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