Authentication
Cisco AppDynamics API requests adhere to a standard OAuth2 request format. You need a Service Principal and a valid JSON Web Token (JWT) to use this API. Service Principals are identities, represented as code, used by created applications, services, and automation tools to access specific resources.
Create Service Principals
Note
To create a Service Principal you must be a Company Administrator and own a Cloud Tenant.
You must create a Service Principal for use in generating OAuth2 tokens.
- Log in to the Account Management Portal as a Company Administrator. For more information on roles and associated permissions, see Manage User Accounts.
- Navigate to Access Management > Service Principals. This option displays only if you have a Tenant associated with the account.
- Select a Tenant from the dropdown if you have more than one associated with your account.
- Click
to create a new service principal.
- Enter a meaningful Name that represents the intended use.
- Enter a meaningful Description.
- Select an Authentication Type. a. Basic—credentials pass in the basic authorization header as part of the token request. b. Post—credentials pass in the request body as part of the token request.
- Click Create to obtain a Client ID and Secret.
Note
This is the only time you can view, copy, or download the Secret. If you close the modal, you must rotate the secret to generate a new one.
If you believe that your secret has become compromised, you can revoke the secret or delete the Service Principal which prevents the generation of a new token with that secret.
8. Select either to Download a secret.csv file or Copy the Client ID and Secret.
9. Close the dialog.
Get an Access Token
You generate and use an access token for API access calls into your Cloud Tenant. Access tokens are valid for one hour and are reusable during the validity period. Access tokens use the JSON Web Tokens (JWT) open industry standard, therefore decoding them will not show sensitive information.
Info You cannot view or revoke API-generated tokens that have Default API-generated Token Expiration through the UI or REST API.
Generate a Token
Application principal token requests for your application adhere to a standard OAuth2 request format. The authentication method you select when creating the application principal determines the method you supply the client credentials in the token request.
You can use this URL to obtain your tenantId, where tenantName is the name of your Cloud Tenant. curl "https://observe-tenant-lookup-api.saas.appdynamics.com/tenants/lookup/{tenantName}.observe.appdynamics.com"
For a client configuration using Basic authentication, the client credentials are sent in the basic authorization header. For example:
curl -X "POST" "https://{tenantName}.observe.appdynamics.com/{tenantId}/default/oauth2/token" \ -H 'Content-Type: application/x-www-form-urlencoded; charset=utf-8' \ -u '{client_id}:{client_secret}' \ --data-urlencode "grant_type=client_credentials"
If the client configuration uses Post authentication, the client credentials are sent in the request body. For example:
curl -X "POST" "https://{tenantName}.observe.appdynamics.com/{tenantId}/default/oauth2/token" \ -H 'Content-Type: application/x-www-form-urlencoded; charset=utf-8' \ --data-urlencode "grant_type=client_credentials" \ --data-urlencode "client_id={client_id}" \ --data-urlencode "client_secret={client_secret}"
Any method you use to pass the credentials returns a standard OAuth 2 token response. For example:
{ "access_token": "{JWT accessToken}", "expires_in": 3599, "scope": "introspect_tokens revoke_tokens", "token_type": "bearer" }
You can use the returned access token in requests to permitted APIs in the authorization header as a Bearer type. For example:
curl "https://{tenantName}.observe.appdynamics.com/{someAPI}" \ -H 'Authorization: Bearer {accessToken}'
Manage Service Principals
Service Principals are Cloud Tenant-specific. Any management you perform on a chosen Cloud Tenant will not convey to another Tenant. In other words, if you have multiple Cloud Tenants and want to write code that can act on each one, you must create and maintain a Service Principal and secret per Cloud Tenant in your system code to perform the desired functions.
Note
To create a Service Principal you must be a Company Administrator and own a Cloud Tenant.
Log in to the Account Management Portal as a Company Administrator and navigate to Access Management > Service Principals.
View, Edit, and Delete Service Principals
- Select a [Tenant Name]
to view a list of Service Principals for that Tenant.
- (Optionally) Search for a Service Principal within the Tenant selected.
- Check the box for the preferred Service Principal.
To View:
Click to view:
- Name
- Description
- Authentication Type
- Client ID
To Edit:
- Click
to open the Details page.
- Edit the Name and/or Description.
- Update the Authentication Type. a. Basic—credentials pass in the basic authorization header as part of the token request. b. Post—credentials pass in the request body as part of the token request.
- Click Save.
To Delete:
- Select the row of a Service Principal to reveal actionable options.
- Click
.
- Click Delete to confirm.
Note
Deleting a Service Principle causes any integration using it to fail immediately and cannot be reversed. You must create a new client ID and secret to reinstate the integration.
Rotate or Revoke a Secret
Rotating a secret keeps two secrets valid for a period of time. When you Rotate the secret, the system sends a call to the authentication server which provides a new secret and deprecates the old one. The old secret remains viable for 30 days unless you revoke it prior to that time period.
- Select a [Tenant Name]
to view a list of Service Principals for that Tenant.
- Check the box for the preferred Service Principal.
- Click
.
- Click Rotate to generate and display a new secret you can copy or download.
Info Rotating a secret does not disable the older one. An old secret remains active for up to 30 days unless you revoke it prior to that time period.
- Click Revoke Old Secret to revoke the secret. Calls using revoked access tokens fail to authenticate with a '401 Unauthorized error' HTTP status code.