Which Authentication method to use

When deciding which authentication method to use, consider the following:

Which Authentication method to use?

User Authentication (Web App or Single Page App) should be the default choice whenever AEM user context is involved. This ensures that all actions in the repository are properly attributed to the authenticated user and that the user is restricted to only the permissions they are entitled to.
Using the Server-to-Server (or technical system account) to perform actions on behalf of an individual user bypasses the security model and introduces risks such as privilege escalation and inaccurate auditing.

Difference between OAuth Server-to-Server vs Web App vs Single Page App credentials

The following table summarizes the differences between the three OAuth authentication methods supported by OpenAPI-based AEM APIs:

OAuth Server-to-Server
OAuth Web App
OAuth Single Page App (SPA)
Authentication Purpose
Designed for machine-to-machine interactions.
Designed for user-driven interactions in a web app with a backend.
Designed for user-driven interactions in a client-side JavaScript application.
Token Behavior
Issues access tokens that represent the client application itself.
Issues access tokens on behalf of an authenticated user via a backend.
Issues access tokens on behalf of an authenticated user via a frontend-only flow.
Use Cases
Backend services needing API access without user interaction.
Web applications with frontend and backend components accessing APIs on behalf of users.
Pure frontend (JavaScript) applications accessing APIs on behalf of users without a backend.
Security Considerations
Securely store sensitive credentials (client_id, client_secret) in backend systems.
After user authentication, they are granted their own temporary access token via a backend call. Securely store sensitive credentials (client_id, client_secret) in backend systems to exchange authorization code for access token.
After user authentication, they are granted their own temporary access token via a frontend call. Does not use client_secret, as it’s unsafe to store in frontend apps. Relies on PKCE to exchange authorization code for access token.
Grant Type
client_credentials
authorization_code
authorization_code with PKCE
Adobe Developer Console Credential Type
OAuth Server-to-Server
OAuth Web App
OAuth Single-Page App

Before accessing Adobe APIs, it’s essential to understand these key constructs:

  • Adobe Developer Console: The developer hub for accessing Adobe APIs, SDKs, real-time events, serverless functions, and more. Note that it is different from the AEM Developer Console, which is used for debugging AEM applications.

  • Adobe Developer Console Project: Central place for managing API integrations, events, and runtime functions. Here, you configure APIs, set authentication, and generate required credentials.

  • Product Profiles: Product Profiles provide a permission preset that allows you to control user or application access to Adobe products such as AEM, Adobe Target, Adobe Analytics, and others. Every Adobe product has predefined product profiles associated with it.

  • Services: Services define the actual permissions and are associated with the Product Profile. To reduce or increase the permissions preset, you can deselect or select the services associated with the Product Profile. Thus, allowing you to control the level of access to the product and its APIs. In AEM as a Cloud Service, services represent user groups with predefined Access Control Lists (ACLs) for repository nodes, allowing granular permission management.