An unlikely, but more plausible option to me would be that after removal of the Parler account, someone else was able to register the same account and gain access that way. But that doesn't fit the description all that well, and I'd also expect that this would not work at all if the authentication service is not very careless.
For example here is how something like that might break:
/auth
-> returns {"success": true} and 200 on success
-> normally returns {"success": false, "error": "BLAHLBAH"} and 200 on failure
after your account is disabled /auth starts returning empty json: {} with a 500 error code
oops. now all the requests are incorrectly marked as success. i know this happens because i've seen similar things happen in real life.
the error could also be more obvious and the code just fails open. someone has a try/catch and returns true either because of an accidental mistake or because they don't want users to be locked out when the provider is down.
Failing open would be a catastrophic mistake either way. "The auth provider is down, just let everyone in!"
Unless the software skipped authentication entirely when this service was unavailable, which I find hard to imagine. But that seems to be what is claimed right now.