Also why is it sometimes called a federated ID? Does it have to be an email address or could any value work?
SSO - Single Sign-On
The idea is that you use one identity from any provider to log in everywhere. It’s also used in the enterprise world to centrally manage every app you can log into. So they assign you an email address, and you can use their SSO service to get into Slack/Teams/Salesforce/Figma/admin panels and whatever else you might need. When you quit, they turn off your email, and by doing that you also lose access to all those other apps and accounts as well automatically.
It’s also widely used by regular people often in the form of login with Facebook/Google/AppleID/Github and others.
The idea behind it is, you can focus on having one account that you keep very safe with a strong password and 2FA. And you don’t have to remember any other password or username or whatever.
Not all SSO systems are compatible with eachother: some use SAML2, some use OpenID, some use a fairly standard OAuth flow, and some are specific to that platform like Facebook and Google. OpenID in particular is federated, because in theory you can use any OpenID provider to log into anything that accepts OpenID. Email is also federated, because it is also an open and interoperable standard: you can send a Gmail to a Yahoo account, or in my case, my own personal server. Or how Lemmy does it: I have my own Lemmy server, but it talks to all the other lemmys so I can subscribe, vote and comment.
The way it works is, you tell the site you would like to log in with a third party provider, the website redirects you to your SSO provider (that you trust and can validate that, for example, you’re indeed on google.com if you select to log in with Google). Then, you log in there (if not already). Then it confirms to you that you’re about to log in to whatever app, and what information about you will be shared such as your name, email address, picture, sometimes more. You validate, and your SSO provider sends you back to the website with a secret key that contains all that information, and voilà, you’re logged in to the website without ever making an account or entering your details. No password or security questions to remember for that site!
It doesn’t have to be an email, but since a lot of SSO providers are also email providers or use emails as your login there, it’s nearly always an email.
Great explanation. Two question, what’s the likelihood of an SSO page being spoofed? This seems like an all-eggs-in-one-basket sitch, so what are the potential threats to this?
Here’s a good article that explains it well.