Adobe Experience Manager (AEM), formerly known as CQ5, is an enterprise Content Management System (CMS) used for Digital Asset Management (DAM). We’ll only use the acronym “AEM” from the previous sentence in the rest of this blog post, so don’t worry about the others. The major takeaway is that AEM enables contents and assets to be created and managed in a central storage repository.
Older versions of AEM only support basic authentication. However, versions 6.1 through 6.3 greatly enhance AEM’s OAuth support. Today, OAuth is the preferred way to connect to AEM. In this blog post, we will demonstrate how to connect to Adobe Experience Manager via OAuth and make API requests to users’ accounts.
Preparing the AEM Server
AEM doesn’t enable OAuth 2.0 connectivity out of the box. Developers must first request an AEM administrator to enable OAuth 2.0.
The administrator must first navigate to Tools > Web Console to find the configuration described below. The admin then edits Adobe Granite OAuth Server Authentication Handler and sets the
1100, to not collide with other Login Modules on the AEM server.
Verify the configuration in JAAS (Main -> JAAS). The
com.adobe.granite.oauth.server.auth.impl.OAuth2ServerLoginModuleFactory LoginModule should possess the rank
The next step is to adjust the OAuth resource scope on the AEM server. The admin edits the Adobe Granite OAuth Resource Server in the Adobe Experience Manager Web Console Configuration (OSGi -> Configuration) to add
/ to the
Some earlier versions of AEM don’t provide refresh tokens. In this case, adjust the lifetime of an OAuth Access Token on the AEM server if you’d like to control its expiry, since refresh tokens are not available. To do this, request the admin to edit the Adobe Granite OAuth Token Endpoint section in the Adobe Experience Manager Web Console Configuration (OSGi -> Configuration). Change
OAuth Access Token Expires In to
31536000 or some other large number to prevent it from expiring quickly. This represents the number of seconds after which the user must reconnect their account.
The AEM server is now set up to issue access tokens via OAuth 2.0!
Create Developer Apps on the AEM server
Unlike cloud ECM and file sync and share services, AEM requires OAuth apps to be created on the server the user grants access to in the first place. This is common for self-hosted services as they function as both the resource and authorization server. Therefore, developers must request an AEM admin to head to Tools > Operations > Security > OAuth Clients and add a new client that represents their application.
The AEM admin must provide the Client ID and Secret the server displays to the developer to use to authorize end-user accounts.
Connect user accounts and make API requests
At this point, a developer app can guide a user through the regular OAuth 2.0 flow to connect an account and receive a Bearer token to make requests to the account with. The OAuth authorization URL is at
/oauth/authorize, and the authorization code obtained can be exchanged for a token at
/oauth/token. Be sure to use the scope
/ during the OAuth process!
AEM supports connectivity via both WebDAV as well as a more versatile JCR API. Describing the API requests themselves is out of scope of this blog post.
Kloudless supports AEM
Check out Kloudless for an easier API to use to access your users’ AEM data. The Kloudless unified Storage API supports a uniform protocol to access several different storage services with a single implementation.
For example, here is an API request to access the contents of the root folder of an AEM account:
curl -X GET -H 'Authorization: Bearer TOKEN' \
The Kloudless AEM connector currently supports several operations on files and folders, with more advanced support for Search on the roadmap.
Feel free to reach out to us at firstname.lastname@example.org or in the comments below with any feedback or questions!