[Feature New Product] Custom Page SSO - Support for Login As Impersonation

[i-am-rad]

🌟 Describe the Feature

When agency admins and users are using the "login-as" feature our SSO iframes are not being given this information. Often agency type users are trying to help or support their clients. The SSO only delivers the agency type users information. Ideally we get additional fields to let us know they are actively impersonating a user.

🚀 Justification

This would help ensure that apps with user specific settings can enable agency admins/users to modify those settings on behalf of their users. This is something that would need to be explicitely built by the app owner to support this, so there is less of a concern here about security/impersonation.

📝 Suggestions

Add additional fields to SSO object to indicate the userId, user name, user, email, user type the agency admin/user is impersonating.

Product Area

marketplace-modules

📋 Use Case

App owner has user specific profile settings. These are only accessed by that apps user that we are decrypting the SSO object. The agency type user is unable to assist their client because the impersonation does not carry through the SSO.

🚨 Why Should This Be Prioritized?

Higher quality of support and more trust in the app marketplace that agency type users can help their clients configure 3rd party applications that are tied to user accounts. This helps agencies provision 3rd party products on behalf of their clients if the app developer supports this new feature.

🧠 Additional Context

No response

[github-actions]

✅ Issue processed successfully!

Your issue has been reviewed and assigned to the appropriate team.

[i-am-rad]

Related:
#230
#225

[ved-go-high-level]

After reviewing the request internally, we won’t be moving forward with this change. Exposing impersonated user details through the SSO payload would introduce the risk of exposing personally identifiable information (PII) of our users to third-party applications. Even in scenarios where an agency admin is using the “login-as” functionality for support, passing the underlying user’s identity (such as userId, name, email, or user type) to external SSO consumers creates a broader surface for unintended data exposure.

From a platform and privacy standpoint, we have to ensure that SSO payloads only contain information that the authenticated user has directly consented to share with the third-party application. Propagating impersonation context to third-party apps would effectively disclose user data without the user explicitly initiating that session with the application.

Additionally, the proposed use case is primarily operational/support related rather than a core authentication requirement. Because of the potential privacy implications and the lack of a strong platform-level need, we don’t consider this a valid use case to support through the SSO framework at this time.

For these reasons, we won’t be prioritizing or implementing this enhancement in the marketplace.