Third Party Authentication — Why: Toward A Central Identity Management
Part I: Setting the Stage
Ever wondered how websites rely on third parties to authenticate users? SingPass/CorpPass is one such federated identity. Google Accounts is another one. Even Facebook, or LinkedIn, and Instagram. Each of these systems have user-differentiating information that they can pawn to other services.
At GoBusiness, and on many government sites, you’ll often be asked to log in with your SingPass or CorpPass credentials.
Today, we’ll be using these integrated systems to model third-party authentication.
Groundwork
First off, what do we mean by third-party authentication?
Authentication
Let’s begin by defining authentication. Authentication is simply a verification of identity — when a system authenticates someone, they are verifying that the someone is who they say they are. But perhaps we need to unpack identity even more.
What is identity? — Identity is a way of distinguishing users.
When I enter in my Google Accounts information on the Google Accounts Login Page, or my SingPass details on the SingPass Login page, I am giving a digital representation of myself that is known to these systems. That could be a username and password tuple, an email and password tuple or other couplets. It could even be a triplet, where the third vector is a time-sensitive code, quadruplet, or quintuplet — ad infinitum.
These systems then verify that this digital representation is valid — for e.g., that this username and password exists in their records, or a (username, hash(password)) exists and the 2FA provided is a valid one. If so, then to the system, the person who is logging me is the same person as the person who created these representations on registration.
When We Need Digital Representations of Users
Why do systems even want digital representations of users? Because that’s one way, perhaps the most natural way of associating digital resources to physical users.
Notice how you don’t need to log in to Wikipedia to read from it. That’s because the site is user-agnostic when it comes to content display. It doesn’t matter who is accessing the site, they will mostly see the same thing.
Correspondingly, in sites where there’s user activity such as posting and commenting, a log in is required. Unless posts and comments are anonymous, which is the model of some sites, we users assume site activity under a certain name indicate they were made by the same individual/entity. That’s what identity is, at least your online one.
Site activity associated with your digital identity could be photos you post, comments you make, a profile page, and/or a myriad of application activity.
In the case of government applications, things are a little more serious. Your identity could be associated with applications for licences on GoBusiness, tax filings on IRAS, or savings in your CPF account.
Needless to say, the veracity of one’s digital identity is of paramount importance.
A Central Identity Management, and Tokens
Now in the early, soupy days of the internet, you’ll see a lot of websites implementing their own user-login systems. That’s why we have to remember a thousand and one usernames. And passwords. Each website had their own store of digital users. And people kinda just did it because everyone else did. If you provided the correct set of credentials, you would be authenticated into a particular system as a particular user. The system would verify the credentials against a database, and perhaps a nonce generator in the case of 2FA passcodes.
But what if I could, wanted to, or had to make use of another system’s identity management? If that system could pass me a digital token representing said person — wouldn’t that be cool/neat and perhaps good enough? If I could just get another system to tell me who this person is, I wouldn’t have to store a digital representation of this person — or even verify that this person is valid and exists. Let’s call systems that use this token, consumers, and systems that generate the token, providers. As long as the providers return me a valid token — I know this person is a valid user.
In this manner, the digital token is a passport made for information transport between integrated systems.
Conclusion to the Introduction
And this is what is meant here by third party authentication. We leave it to a third party system, not managed by us to tell us if someone trying to log in is a valid user to the system, and who they are. You may also hear the term “federated identity” used synonymously. It makes sense; the federated identity is used in a federation of systems.
This implies a couple of things. Implicitly, it implies we trust the identity providers — because we don’t do any identity verification on our part. And we also agree to use the digital representation given by the identity providers. It also means that the multiple consumers using the same identity provider will have the same digital representation for a given person and may have some way of recognising the same user cross-platform in the event of future integration. Thus, they commit to being a “federation”.
In the case of government systems, it may even be considered a feature that identity management is centralised in one system — from a user’s stand-point, all government systems belong to one entity — the government. Significant angst comes when users are asked to create multiple digital identities across government systems, regardless if these systems are built independently of one another, or if they belong to different agencies. To have one central, federated identity that requires a one-time user set-up that is recognised across all agency services — is a hassle saver and definite plus.
For the technical follow-up, read this.
