There is one case where you would need to authenticate to AM is when the customisation script needs to perform some task against AM that requires a session. Of course in this case, there is no interactivity (no user agent) therefore it has to be POST to the authenticate endpoint, and handling the callback(s) from the script. If this is an admin operation, I would carefully design the journey with security in mind, and for code simplicity ensure a single callback round - possibly using some kind of JWT authentication.
However it’s not because you can authenticate and perform some operation agains AM from within IDM that you should. It is actually not advisable, as first, it incurs a performance hit at the IDM REST managed endpoint, and secondly, it increases the solution ownership costs. Also to further hit the nail, you can’t implement caching in an IDM script, therefore, can’t cache the SSO token, it has to be acquired each time - which is a poor design.
It is best to place this code outside of IDM, logically at the intermediate layer. In fact you could use IG for this, this is an optimally performant solution, and easier to maintain. And there is some logic that can be implemented in IG to cache the SSO token obtained from a backchannel transaction - encapsulated with a specialised client handler [ see Promise Synchronisation in https://community.forgerock.com/t/identity-gateway-7-1-highway-to-async-programming ]
Note that my assumption here is that the onUpdate script invocation is originating from an update performed at the IDM REST endpoint, and therefore via using the admin or some delegated admin that has the privileges to do so, so this is not a direct user interaction, is that correct?
Regards
Patrick