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.
|
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.
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.
In the Access Management navigation menu, click Connected Apps.
Optionally, select the business group to create the connected app in.
Click Create App and enter a unique name for the application.
For Type, select App acts on behalf of a user.
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.
In Website URL , enter the URL where users go to learn more about the app.
In Redirect URIs, configure which URIs users are directed to after authorization.
Type the URL and click Add to add it to the list.
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
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.
In Add Scopes, select the scopes to apply and click Add Scopes.
If applicable, select the business groups to apply the scopes to and click Next.
If applicable, select the environments to apply the scopes to and click Next.
Click Add Scopes, and then click Save.
In the Access Management navigation menu, click Connected Apps.
Optionally, select the business group to create the connected app in.
Click Create App and enter a unique name for the application.
Select App acts on it’s own behalf (client credentials).
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.
In Add Scopes, select the scopes to apply and click Add Scopes.
If applicable, select the business groups to apply the scopes to and click Next.
If applicable, select the environments to apply the scopes to and click Next.
Click Add Scopes, and then click Save.
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.
Use the authorization_code
grant type to authorize the app to access a user’s data.
This is an example of the development flow:
A developer creates the connected app that acts on behalf of a user with the authorization_code
grant type.
The end user authorizes the app to act on their behalf.
The authorization server sends a temporary authorization code back to the specified 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.
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.
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. |
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:
A developer creates the connected app that acts on behalf of a user with jwt_bearer
as the grant type.
The JWT token exchange occurs with these claims in the payload:
Attribute | Description | ||
---|---|---|---|
|
The issuer of the claim. This value must be same as the connected app’s |
||
|
The subject of the token, such as: {version}|{identityProviderId}|{username}|{firstname}|{lastname}|email|externalgroups
|
||
|
The authentication server. For example, the authentication server for the US region is |
The app calls the authorization server with the generated assertion.
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 using service accounts to programmatically call Anypoint Platform to use connected apps when configuring multi-factor authentication.
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.
|
For more information about 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 Connected Apps, click the Scopes Documentation tab.
Scopes Documentation shows the scopes, their respective permissions, and the products they belong to.
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, 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.