Authentication is frequently confused with Access and Identity Management. These concepts are often used interchangeably because most existing authentication schemes were designed with the hierarchical, paternalistic mindset of traditional senior IT staff. Privileged accounts (dad) hold the keys to the kingdom and users (children) must prove their identity to the trusted directory (aunts and uncles) to show they are entitled access a service. In this narrow view, access is given following identity authentication by a trusted family member.
The source of trust in existing access control systems resides in a directory of user accounts. Trust is derived from the directory service when an entity with higher privileges asserts that the user has satisfied one or more authentication factors. The privileged entity signs an access token asserting that the user is who they say they are.
In existing AIM systems, you are who you say you are because a 3rd party authority says you are. In this perverted form of existentialism, Facebook says you are who you say you are and that assertion grants you existence online. Sometimes these 3rd parties make mistakes.
Convenience and usability are two core selling features and most corporate Access and Identity Management systems offer a Single Sign On service. With SSO, administrators can choose to trust identity tokens signed by multiple directories and take advantage of rule based systems to provide access across their enterprise. These systems are expensive and require significant administration but they significantly reduce friction and most enterprises are happy with that trade off.
On the consumer side, a few companies like Amazon offer their own SSO but most companies elect to use a “free” SSO solution created by a social media platform to harvest data. Facebook, Google, Snap and Twitter offer the most common consumer SSO directories. Companies using their SSO service elect to trust them to sign identity tokens.
If you don’t like sleeping at night (or ever again), you can read about a few of the authentication mistakes companies make everyday. One infamous example was announce in September of 2018. A single line of code on Facebook’s publicly facing “View As” template produced a signed access token for each user when their View As page was accessed. The tokens Facebook issued and signed could be used for persistent login as well as allowing access apps and access and/or registration on any 3rd party sites that support Facebook Single Sign On. 92 million users were exposed to a vast range of exploitations by a single mistake.
Facebook’s VP of Product, Guy Rosen, summarized the impact of this error on a conference call with reporters. “The vulnerability was on Facebook, but these access tokens enabled someone to use the account as if they were the account holder themselves.” Rosen continued. “This does mean they could have accessed other third-party apps that were using Facebook login.” Whoever grabbed the tokens from the publicly available “View All” page could use them on websites that use Facebook accounts as logins.
The biggest data breach in Facebook’s history didn’t just leave user accounts exposed; accounts could be created and authenticated on other websites and existing accounts compromised.
In UNS, identity is eponymous: You are who you say you are. And you are usually right.
UNS turns this model on its head. Rather than trust flowing from a directory to a user, trust in UNS derives from the private encryption keys which users generate on their devices. This form of existentialism is “I exist because I say I do.” UNS Authentication asserts that the entity requesting verification in possession of one of the group of devices pinned to the account. Services are pinned by the user TO their account. Trust is granted from the USER to the SERVICE.
UNS allows the user to operate their own key registry and be the final authority of their own identity. UNS nodes provide bookkeeping and communication services for the user, but they are not the source of trust; the user is the source of trust. Every action performed by a UNS node can be proven correct because the node must retain a signed token from the user authorizing the transaction.
