You cannot meaningfully restrict the allowed frame ancestors if the app is to support custom domains, at least not if the value of the directive is static.
It should be possible to evaluate the tenant context given by the JWT and set the header dynamically, but that’s more costly to configure/implement. Is that approach advisable/encouraged?
As I understand it, the main motivation of an attacker to embed a UI module on another domain is to make an unsuspecting user do something in the context of their session through click-jacking or something similar. The UI module won’t work without a valid JWT in the URL, so the attacker would have to have that. In most of our apps, the user’s credentials for calls to our back end are derived from that JWT. If an attacker has a valid JWT, they would most likely already have all they need. So it’s not clear to me that restricting the frame ancestors would provide any additional security benefits. However, I’d be happy to hear about scenarios where it would.