In the first edition of our technical blog series, we look at trust in federated identity.
What is federated identity?
Federated identity means I can use identity information given to me in one place to sign in somewhere else. We see federated identity when we use a Facebook, LinkedIn or Twitter identity to sign in to a third-party service (using one of those identities to sign in to a third-party media site, for example). To talk about federated identity, it’s important to establish common terminology:
- User: the person accessing an online service (relying party)
- Relying party: an online service that needs to know something about a user
- Identity provider: an entity that can hold and state information about a user
If we think of an example:
- I (the user) access The New York Times (the relying party) and am prompted to sign-in with one of three social identity providers: Google, Facebook or Apple:
Figure 1 – NYT sign in with SIdPs - I pick, Continue with Facebook (identity provider), consent to share limited personal information from Facebook with The New York Times (relying party), and am returned as a logged in user to The New York Times:
Figure 2 – NYT return following sign in
Federated identity is a common and well-understood pattern, but it’s important to know what’s going on under the hood.
Trust in federated identity
In federated identity, there is two-way trust between the user and the identity provider (IdP). The user can trust that Facebook is indeed the genuine Facebook because they have connected to it via HTTPS and they can see the green padlock in their browser. Building on this trust, the user has already given personal information (e.g., set-up a Facebook account) to get credentials they can use elsewhere (e.g., sign-in to The New York Times with Facebook). The user is trusting the IdP to keep their credentials safe and, in fact, the credentials are owned by the IdP (Facebook owns my Facebook account, not me). In addition, the IdP (Facebook) can trust that the user is the real owner of their information, because they are in possession of the credentials (username/password) given to them at time of registration. We can show this:
In the diagram above, the following information exchange takes place:
- The IdP gives the user a set of credentials (Facebook gives me a username and password)
- The IdP proves themselves to the user using the PKI/TLS/HTTPS system which results to a green padlock on their browser
- By clicking “Continue with Facebook” and following the consent process,
There’s also two-way trust between the identity provider and relying party. The relying party needs to trust that the identity provider can assert information on a user’s behalf; the identity provider needs to trust the relying party is genuine (the real New York Times) and not a bad actor (a fake site set-up to steal my credentials:
Above, the following information exchange takes place:
- The relying party shares its client Id and client secret with the identity provider so it can identify itself to the IdP
- The identity provider shares its signing certificate with the relying party so the IdP knowns information has come from the IdP and has not been tampered with
Because we’ve established trust between the user and the identity provider, and the identity provider and the relying party, we can now have a resulting trust between the user and the relying party:
Big privacy problems
The largest problem with federated identity in the context described, is we’re sharing a lot of personal information with organisations we don’t entirely trust. I’m giving a lot of information to social identity providers (whether Facebook, LinkedIn, Twitter or someone else) about where I spend my time on the internet. These identity providers know what I’m reading online and if I’m signing into digital services advising on medical conditions.
What we need to do is move away from trusting single identity providers and towards decentralized identity patterns – and that’s the subject of our next blog article.