Be careful who you trust
Offering single sign-on for consumer scenarios (B2C) depends on major companies. Google, Apple, LinkedIn, Facebook, and the like. This is a US centric list; for other countries there are other major consumer identity providers. For instance, I know Xing is in the mix in Germany.
As a developer, you need to understand how these identity providers verify user identity, because, transitively, you are relying on their “say-so”.
If you are are in a B2B2E situation, where you are selling to customers who then set up their own identity providers, you’re in a whole different world. You need to be careful to ensure that you know who is running the identity provider that you are federating with.
Here’s an example of a potential privilege escalation in Azure AD, which is especially risky for multi-tenant scenarios.
An AAD user can be created or modified by a privileged user with an email which impersonates another AAD user. When an application uses an unverified email claim for authorization, a bad actor has the potential to gain unauthorized access by issuing a token to impersonate a valid AAD user.
You should read the whole thing, but users can, in certain scenarios, set up their account to impersonate another user’s email address. The the post recommends avoiding reliance on an email address for authorization or identification purposes.
But the larger point is, if you delegate to Azure AD, you trust them to get identity right. You must understand the implementation details (that some users “can have any email address set for their Mail (Primary SMTP) attribute”) and the ramifications. Otherwise, takeover of your customer’s account could be possible.
Imagine if you had a malicious Azure AD tenant that you configured to be a valid federation source. You’d be delegating user identity to an attacker.
Federation seems like such a good deal! You get easier user registration/sign-up and you can rely on the remote identity provider to “own the user”. But with great trust comes risk.
Ways to mitigate federation risk:
be careful who you trust
logically segment your users and the identity sources which can be used to authenticate them
avoid automatically matching accounts on mutable attributes such as email address
Dan