Federated Identity: All your eggs in someone else's basket

You are only as secure as your identity provider. Hopefully.

Federated identity… or single sign-on… is everywhere in today's technology. The ability to prove your identity once and access any resource you want without needing to prove who you are again is incredibly convenient. Authentication is inconvenient given the technologies we have today, to say the least. This makes avoiding having to re-authenticate over, and over, and over, incredibly attractive. There is also no shortage of companies that want to be your sole source of authentication. Big names like Amazon, Facebook, Apple, Microsoft, are all doing everything they can to be your identity provider of choice. Locking you into an ecosystem is fantastic for them and easy for you, so why not?

This brings an interesting question though: Do you own your own identity?

"Of course, I do! It's me! Only I have my password! Only I have my amazing 2 factor codes! I have the keys so of course I own me!"

But do you really? Hopefully you're the only one that knows your password (and hopefully your trusted provider is protecting that password properly), and hopefully no one else has access to your 2FA resource(s), so you're right… only you have the keys.

But who owns the lock? Who owns the ability to actually set that password? Who owns the platforms that hold those keys? Who owns the system that, after you've authenticated, tells another system who you are? Who owns the systems that protect those systems? Who defines the policies that are supposed to be enforced to ensure those systems aren't manipulated or bypassed? Hint: It's not you.

Your identity is "owned" by whatever entity (aka, identity provider) is trusted to say you are who you say you are. We're used to providing credentials to these systems to prove we are who we say we are… but that's to prove ourselves to the identity provider. After that, it's not YOU who are being trusted… it's the identity provider. In fact, it is entirely possible for that identity provider to pretend to be you without your credentials even being required (known as "delegation"). In fact, this happens all the time when we allow systems to work together behind the scenes to provide services. If you've ever seen a request for permission for a system to "act on your behalf", this is exactly what's happening. You're saying that the identity provider is allowed to do whatever it wants, as you, whenever it wants, without your involvement. If someone can use your identity whenever it wants without your permission or involvement, do you really own that identity?

This also means you are completely trusting that identity provider to protect and respect the identity that you've entrusted it with. You're trusting that they have solid policies stating they won't abuse that identity. You're trusting they have tools implemented to enforce those policies. You're trusting that they won't bypass or reconfigure those enforcement tools to get around and violate their own policies. You're trusting them, completely, with being “you” to the rest of the world at any time… and trust is never certain.

You've put all of your eggs into someone else's basket, and you're really, really hoping they'll protect and respect your eggs.

The response to all of this from any identity provider will be fundamentally the same. "We have policies that prevent abuse" and "Our system architecture ensures our customers are protected" and "We have monitoring to ensure potential risks are caught and blocked immediately". It's in their best interests to be trusted, so of course these things are probably/hopefully true.

However, anything that can be configured to protect can also be configured (or misconfigured) to be bypassed.

There are many examples of how your identity can be compromised between providers:

• An API key that is shared between an identity provider and a service could be accidentally disclosed or maliciously acquired. Developers accidentally pushing API keys to their shared (and frequently public) source code systems happens all the time.

• A certificate could be mis-granted or mis-trusted to pretend to be your identity provider or the service the identity is being provided to. Certificates are all about chains of trust… compromise one link in the chain and everything that depends on it is broken.

• A state or government uses a legal means to demand that your identity be compromised. These can be written in such a way as to ensure you have no knowledge that it's even happening.

• An individual with elevated access to the systems protecting your identity can use this access to work around protections, using their access and knowledge of the systems to avoid detection or recourse.

• Systems anywhere along the way may not be fully patched with the latest security updates (and there are ALWAYS new security updates).

• You could grant permission for your identity to be delegated to another entity that can then abuse that access… like granting an app access to your contacts so that you can select your best friend only to find later that the app has uploaded, indexed, and is now reaching out to every contact you have.

To be fair, most of these can be said about any identity or authentication system, federated or not. Using a federated identity provider just makes the impact of such things much larger since compromising one system could potentially grant access to your entire life.

Federated identity can be a wonderful thing. Enterprises gain incredible power through identity federation by ensuring that their employees have appropriate access to approved resources with minimal risk of unintended access. When you work for an employer, your identity isn’t really “yours” …it’s theirs. They create it, they manage it, they can reset it, and when you leave the organization, they should have the full ability to disable it, all at their discretion. In business, this makes complete sense.

In some cases, you simply have no choice as to whether you use a federated identity or not. If you want to access a Google, Facebook, Microsoft, or Amazon property, you're in their federation's control and there's simply no way around it. This makes sense considering the number of properties and resources these companies own and provide access to within their own ecosystem.

But, what about your bank? Your medical information? Education records? Child information? There are resources that are worth protecting independently. There are values to not outsourcing your identity. Using discrete identities (aka, username/password/2FA) with discrete companies isolates your risk between various services… and this has proven valuable over and over again. Should a compromise of your streaming media provider imply a compromise of your bank accounts? Should the compromise of your magazine subscription imply a compromise of your medical provider? In a federated identity world, anything protected by that federated identity is 100% dependent on the security and integrity of that provider.

There are times when federated identity really does provide value and the convenience is simply worth it. Sites and services that are of low impact or contain information that is just “meh” if compromised or over-accessed… sure. Convenience is real. This is especially true with the way some browsers are integrating the sign-in process with the browser directly. For things I don’t care about? Yeah, sure, okay. Easy. Thanks.

For things I DO care about, however, every password is unique. Cross-service integration is kept to a minimum. There have even been occasional instances in which a cross-platform permission has been requested (and, hey, thanks for asking first by the way) and the level of access requested has been a solid NOPE. Everything is a balance between security and convenience. In general, and there are exceptions, more convenience implies a reduction in security.

I’m even an advocate of keeping my individual unique passwords separate from these providers as well. Products like 1Password, LastPass, and several others are very well studied, and their security implementations are well reviewed (by people smarter than me). Using a secondary password manager also keeps your passwords, yet again, out of the hands of the web browser providers… who also happen to be providers of those federated identity providers. The browser synchronization of passwords across your laptop and phone browser (assuming you’re using the same browser and have enabled sync) is convenient. However, A) those passwords are ONLY available in the browser, precluding access from non-browser use and B) while those passwords are hopefully encrypted in some way, they MUST be retrievable in the other browser as well… and you have no idea where this is happening, how it’s happening, or when.

Password managers from secondary, well respected, well reviewed companies or tools creates another boundary of things that have to be compromised in order to hijack your world. Most of them claim (and in many cases have been independently verified) to be physically incapable of accessing your passwords even if they wanted to.

Federated identity provides convenience and is sometimes required. It’s frankly inescapable. Just remember that you’re literally outsourcing your identity. You’re letting someone else “pretend” to be you. You’re trusting someone else with who you are to every service that integrates with that identity. It’s not your identity anymore… it’s theirs.

It’s their basket, and even though they’re your eggs, they can do whatever they want with their basket, even if it’s not to your benefit.