Best Practice for Securely Storing OAuth Access Tokens in AEM as a Cloud Service | Community
Skip to main content
S
Shivasri
Level 1
July 30, 2026
Question

Best Practice for Securely Storing OAuth Access Tokens in AEM as a Cloud Service

  • July 30, 2026
  • 2 replies
  • 56 views

Hi everyone,

I'm looking for guidance on the recommended approach for securely storing OAuth access tokens in AEM as a Cloud Service.

We're evaluating different options for storing an access token that is used for outbound API integrations. The approaches we're considering include:

  • In-memory cache: This avoids persistent storage, but since AEM as a Cloud Service runs multiple author/publish pods, each pod maintains its own cache. As a result, a pod without the token may need to perform an additional OAuth token request.
  • JCR storage under /var: Store the encrypted access token under /var with appropriate ACLs and access it only through a dedicated service user.

I'd like to understand:

  • Which of these approaches is generally recommended for AEM as a Cloud Service?
  • Are there Adobe-recommended best practices for securely storing and managing OAuth access tokens?
  • Has anyone implemented a different approach that works well in a cloud-native, multi-pod AEM environment?

Any guidance, recommendations, or references to Adobe documentation would be greatly appreciated.

Thank you!

    2 replies

    partyush
    Community Advisor
    partyushCommunity Advisor
    Community Advisor
    July 30, 2026

    Hi ​@Shivasri

    The In-Memory Cache is the 100% recommended best practice. Storing transient OAuth tokens in the JCR (under /var) is a cloud anti-pattern in AEM as a Cloud Service (AEMaaCS).

    Credentials: Store your static Client ID and Secret in Cloud Manager Secret Environment Variables. Never in the JCR or Git.

    Retrieval: Map those secrets to an OSGi configuration ($[env:MY_SECRET]).

    Caching: In your OSGi service, use a Caffeine Cache to hold the token in-memory.

    Lifecycle: Set the Caffeine cache Time-To-Live (TTL) to expire 5 minutes before the actual IdP token expires. This acts as a buffer so no pod attempts to use an expired token.

    Thanks
    Partyush.

    Thanks
    Partyush

    S
    ShivasriAuthor
    Level 1
    August 11, 2026

    Thanks for the clarification, Partyush.

    One question regarding the in-memory cache approach: since AEM as a Cloud Service can dynamically scale the author/publish instances, each pod/instance would have its own in-memory Caffeine cache.

    In a scenario where new instances are created, those instances would initially have an empty cache and would therefore need to request a new OAuth access token from the IdP. Similarly, different instances could independently refresh their tokens when their respective cache entries expire.

    Wouldn't this potentially result in multiple OAuth token requests across instances and increase the number of calls to the OAuth/IdP endpoint, particularly during auto-scaling events?

    Is this additional token-request overhead considered acceptable/recommended for AEMaaCS, or is there an Adobe-recommended approach for sharing/caching OAuth tokens across instances while still avoiding persistent storage of the access token?

    Thanks!

    Terms & ConditionsAccessibility statement

    Loading footer...