Generating Access Tokens for Server-Side APIs generating-access-tokens-for-server-side-apis

Some architectures rely on making calls to Adobe Experience Manager (AEM) as a Cloud Service from an application hosted on a server outside of AEM infrastructure. For example, a mobile application calls a server, which then makes API requests to AEM as a Cloud Service.

Use the AEM as a Cloud Service Developer Console to create an OAuth Server-to-Server technical account. Your application exchanges its client ID and client secret for an access token using the Adobe Identity Management Services (IMS) client_credentials grant. No signed JWT, private key, or certificate is required.

The Server-to-server Flow the-server-to-server-flow

Users with an IMS organization administrator role who are also members of the AEM Users or AEM Administrators product profile on AEM Author can create a technical account. The client secret is shown only to the user who creates it, at creation time. A user with the AEM as a Cloud Service Environment administrator role can view the account’s details, which do not include the client secret.

The server-to-server flow involves these steps:

Create a Technical Account and Retrieve Its Credentials fetch-the-aem-as-a-cloud-service-credentials

To review a secret’s details later, open the client secret’s row menu and select View. The credentials dialog shows the IMS endpoint, scopes, client ID, technical account email, secret ID, and revocation status. It does not show the client secret value.

Install the AEM Service Credentials on a Non-AEM Server install-the-aem-service-credentials-on-a-non-aem-server

Make the credentials available only to the server-side application that calls AEM. Use a secret manager or another access-controlled storage mechanism.

Do not put a client secret in browser-side code, mobile applications, source control, or logs. Treat access tokens as secrets as well.

Request an OAuth Access Token request-an-oauth-access-token

Send an HTTPS POST request to https://<imsEndpoint>/ims/token/v3. The imsEndpoint in your credential JSON is an IMS hostname. For example, ims-na1.adobelogin.com uses https://ims-na1.adobelogin.com/ims/token/v3. Use the hostname supplied in your credentials, including the stage hostname when using stage credentials.

Use Content-Type: application/x-www-form-urlencoded and include these form fields in the request body:

URL-encode each form value. Send secrets in the request body, not in the URL or query string.

The response includes access_token, token_type, and expires_in. Use access_token to call AEM. The expires_in value is the token lifetime in seconds. Use that value rather than assuming a fixed expiration time.

Cache and reuse the access token until it approaches expiration, then request a new token with the same client credentials. This grant does not require a JWT exchange or a refresh token.

Node.js Authentication Example nodejs-authentication-example

For a minimal OAuth Server-to-Server implementation, see the AEM-CS API Client Library example. It uses built-in Node.js APIs and requires Node.js 18 or newer, with no additional dependencies.

The example expects the credentials inside an integration object. The aem-s2s-credentials.json file downloaded from the AEM Developer Console contains the credentials without this wrapper. Wrap its content before using it with the example, for example with jq:

jq '{integration: .}' aem-s2s-credentials.json > downloaded_integration.json

Alternatively, edit the file so that its complete content becomes the value of a top-level integration field. From a checkout of the example repository, run:

node oauth-s2s-cli.js downloaded_integration.json

For programmatic usage, the OAuth helper accepts the wrapped object as requestAccessToken(credentials). It uses the IMS hostname, client ID, client secret, and scopes inside integration.

Keep the credential file private. The CLI prints an access token. Do not send its output to shared logs or publish it. The example’s README also shows how to use the token in an AEM API request.

Calling the AEM API calling-the-aem-api

Include the access token in the Authorization header of requests to your AEM as a Cloud Service environment, using the value Bearer <access_token>.

curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
  "https://author-p<program-id>-e<environment-id>.adobeaemcloud.com/content/dam.json"

Use the hostname for the environment and tier that your application accesses. Only call resources that the technical account is authorized to access.

Set the Appropriate Permissions for the Technical Account User in AEM set-the-appropriate-permissions-for-the-technical-account-user-in-aem

For more information about IMS and AEM users and groups, see IMS support.

Developer Flow developer-flow

For local testing, developers can generate a development access token directly in the AEM Developer Console without creating an OAuth Server-to-Server technical account. The token can be used to call AEM environments that the developer can access. Use OAuth Server-to-Server credentials, rather than a local development token, for unattended server-side applications.

See the Developer Guidelines for the permissions required to use the AEM Developer Console.

Generating the Access Token generating-the-access-token

Call the AEM Application with an Access Token call-the-aem-application-with-an-access-token

Use the local development access token as a bearer token in the Authorization header, as described in Calling the AEM API.

For an AEM project running on your local machine, an IMS access token is not needed.

Rotate Client Secrets refresh-credentials

OAuth Server-to-Server credentials do not require annual certificate renewal. Rotate client secrets periodically and whenever a secret is exposed. Create a new secret, switch your applications to it, and only then revoke the old secret.

Creating and revoking secrets requires the secret values that you saved. The AEM Developer Console uses an entered secret only to authenticate the request with IMS and does not store it.

Credentials Revocation credentials-revocation

Revoke disables a selected secret for new token requests. It requires the value of the secret being revoked. Revocation can take time to propagate. Do not assume that revoking a secret immediately invalidates access tokens that were already issued.

Delete on a revoked secret removes its metadata, such as the secret ID and revocation status, from the AEM Developer Console. It does not perform a separate IMS revocation and is not available for active secrets.

Delete a Technical Account delete-a-technical-account

Deleting a technical account revokes the account and all of its client secrets in IMS immediately. No new access tokens are issued for any credential under the account, and integrations that use it stop working once their current tokens expire. To restore access, you must create a new technical account, update your applications with its credentials, and assign the required permissions in AEM again.

Account deletion cannot be undone. Confirm only after checking which applications depend on the account, and do not use it as an individual-secret rotation step.

Migrate a JWT-Based Integration migrate-a-jwt-based-integration

For certificate and private-key operations on the old account, refer to the JWT legacy guide. Do not remove the old account before the replacement integration is verified.