AEM Authentication Patterns: Encapsulated Tokens vs CUG

By Alberto Zarza Martín · · 6 min read

Encapsulated Token authentication and Closed User Groups (CUG) both restrict access to AEM content, but they solve different problems, and picking the wrong one usually shows up later as a scalability or user-experience issue rather than an immediate failure.

Closed User Groups

CUG is JCR-permission-based: content under a CUG-protected path is only visible to members of a configured user group, enforced through standard AEM/Sling authentication (typically a login form or SSO redirect). It integrates naturally with AEM's existing user and group management and is the more "native" mechanism.

CUG works well when: access boundaries map cleanly to actual user groups, content structure aligns with permission structure, and you are comfortable with a traditional login flow.

Encapsulated Tokens

An Encapsulated Token approach issues a signed, time-bound token (often generated by an external system) that grants access to specific content without requiring the requester to be a registered AEM user. This is common for scenarios like sharing a preview link, gating content behind a business system's own authentication (a CRM, a partner portal), or machine-to-machine access.

Encapsulated Tokens work well when: the authorization decision genuinely lives outside AEM's own user directory, you need time-limited or single-use access, or the consumer is a system rather than a logged-in person.

Decision guide

A common mistake

Teams sometimes implement CUG for what is actually an external-system authorization problem, then bolt on workarounds to synchronize AEM user accounts with an external directory that was never meant to be AEM's source of truth. If the authorization decision does not naturally belong in AEM's user directory, an Encapsulated Token pattern is usually the more honest architecture.