Do we need to guard against federated identity servers lying about who signed in?


Having successfully integrated my old web forms app with an ADFS server I got to thinking about how the process works as a whole. The old app passes the user to the remote ADFS, then eventually the user arrives back in our server having a signed-in identity of joe.schmoe@somedomain.com but I’m not entirely clear on whether I’m supposed to trust that’s right, or whether I’m supposed to try and ensure it’s right.

Supposing that a rogue actor at somedomain.com replaces the sign on at the remote end or manipulates it in some way such that my local server ends up being told that bigboss@somedomain.com signed in (when it was actually tom.hacker@somedomain,com), or worse that bigboss@otherdomain.net signed in, what do we do with such situations?

Is this handled already by the auth process such that we can be sure there are some local rules that enforce the federated server may only return users with some characteristic such as "must really be a user of somedomain.com, for which you know this identity server is responsible" ?

When we hand off authentication to a third party, and get the "user X auth’d successfully", do we need to be wary about whether it’s truly user X and whether the server confirming the identity truly has authority to do so for the user given?

At the moment I’m thinking I should also implement my own local check that the announced user matches a pattern to ensure the federated server isn’t used to break into other domains’ accounts and also implement 2FA to give some extra check that the user announced truly is that person