One authentication event, many relying parties
Federated identity lets a user authenticate once with a trusted identity provider and have that proof accepted by many separate applications, none of which need to manage passwords themselves. This is a real improvement over per-application credentials, which multiply the number of secrets a user has to manage and the number of places those secrets can leak from.
But federation is a division of labor, not a removal of responsibility. Each relying application still decides what the authenticated identity is allowed to do inside that application. Accepting a token from an identity provider answers who the user is; it says nothing on its own about what they're permitted to do here.
The provider becomes a single point of both trust and failure
Because every relying application accepts the same identity provider's word, compromising that provider — or the account it manages — grants an attacker a foothold everywhere the federation reaches at once, rather than in one application at a time. That concentration is the tradeoff for the convenience, and it's why the identity provider itself typically warrants stronger protection than any individual downstream application does on its own.
It also means an outage or misconfiguration at the identity provider affects every relying application simultaneously, which is worth planning for explicitly rather than discovering during an incident.