Feature Request: OOTB ID Token Storage for OIDC in AEMaaCS publisher

Forum|Forum|1 day ago
February 3, 2026
3 replies
47 views

Hi Everyone,

Recently, Adobe shipped a feature (SITES-33594) that enables out-of-the-box OIDC support, removing the need for custom authentication handlers. While this works well for standard flows, we’ve encountered a limitation when integrated with Identity Providers like Okta.

The Issue:
When implementing RP-initiated logout, Okta (and similar providers) requires the id_token_hint=<id_token> request parameter to successfully terminate the session on the IDP side.

Technical Gap:
Currently, org.apache.sling.auth.oauth_client.impl.SlingUserInfoProcessor is only designed to store the access_token and refresh_token on the user node. Since the ID token is not persisted, we cannot retrieve it to complete the logout handshake OOTB.

Requirement:
We need a standardized process within the OIDC implementation to store and access ID tokens on the user node, similar to how access and refresh tokens are handled.

Thanks,

Martin

Experience Manager Sites

M

martin_knyazyanAuthor

Level 2

cc: @katuk_sahni

Vishal_Anand

Level 4

@martin_knyazyan Hi Martin - Short answer: we should extend the OIDC flow to persist the ID token on the user node (same pattern as access/refresh tokens) and use it for RP-initiated logout (id_token_hint).

Key points to implement:

Persist id_token via an updated SlingUserInfoProcessor (or an opt-in config) to a secure user property.
Ensure encryption/secure storage, TTL/expiry and cleanup on logout or token rotation.
Update the logout handler to read id_token and call the IDP with id_token_hint.
Add config and migration path, unit/integration tests, and review privacy/ACL implications.

This keeps OOTB OIDC behavior intact while enabling Okta-style RP logout. Hope this helps.

@kautuk_sahni

M

martin_knyazyanAuthor

Level 2

Hi @Vishal_Anand . Thanks for your response.
This post is just a feature request for Adobe, to extend the OOTB user info processor, supporting to store id tokens. The current workaround is to create custom UserInfoPostProcessor and implement whatever is implemented now + store id_token, which is not a practical solution in this case.

cc: @kautuk_sahni