When you recorded the test, it is likely you went through a federated sign-in process with your organization's on-premises AD FS. (This federated sign-in may have been transparent, as a series of redirects.) As part of this federated sign-in, your organization's AD FS will have issued a SAML token identifying the user to Azure AD. Azure AD will have then verified that SAML token, and since everything checked out, it issued it's own token to the application (the response with #id_token=...).
However, when you attempt to replay those steps later, the original SAML token issued by AD FS (during the original recording) has expired and is no longer valid. So instead of Azure AD redirecting back to your app with the expected ID Token, it redirects back to you app with the error about a bad SAML token.
You should be able to verify this by recording a fresh sequence of the sign-in, and replaying for the test immediately. You'll likely find that the test will pass at first, and then will eventually start failing again once the token expires.
The solution to this depends a lot on your test environment, your Azure AD and AD FS environment, and what specifically you're trying to load test. One option is to use a cloud-only dedicated test user, from a dedicated test tenant in Azure AD (you should not include any credentials for real users from your production environment in your tests). If part of what you're trying to validate includes the federated sign-in, then you should use a test instance of AD FS, and federate your test Azure AD tenant with this test AD FS.
