OAuth, OIDC, MFA - how you actually get in somewhere.
OAuth solves one specific problem: how to let a third-party app work with your data, without handing it the key to everything. Instead of a password, the system issues a token - a temporary pass with tightly written limits: "this third party can read your calendar, nothing else, for 30 days." You click "sign in with Google" under some site - and that's exactly what happens behind the scenes. The pass can be revoked at any moment, without touching your password.
The problem is, the pass doesn't say who's carrying it, only what it's allowed to do. This is where OIDC comes in, built on top of OAuth. It adds an identity seal - confirmation that behind the request stands a specific, verified person. So when you sign in somewhere "with Google" or "with Apple," two different things happen at once: you get access (OAuth) and you confirm who you are (OIDC). Most people never tell the two apart - for them it's just one click.
MFA sits on a completely different level - not what you have access to, but whether you're really you. The password is something you know. The second factor is something you have or something you are - a phone with a code, an app generating numbers every 30 seconds, a push-notification, a fingerprint. The idea is simple: if someone steals your password, they shouldn't get anywhere without the second check. On paper it sounds bulletproof.
In practice it isn't. Attackers stopped fighting the password long ago - they bypass the check. They steal the token itself after you've logged in, instead of guessing your password. That's session theft, and the token works as a real identity, without asking anything again. Or they bombard your phone with MFA push requests in the middle of the night, until half-asleep you tap "approve" just to make the noise stop - an attack known as MFA fatigue. Or they trick you into "granting access" to a fake app, which then holds a legitimate OAuth pass to your account, without having stolen anything.