Explaining Modern Authentication Like I'm Five
I know, you’ve been putting it off.
You understand the full stack of an app – frontends, APIs, business layers, saving data to the database, the whole lot.
…Except authentication.
Somehow you keep skipping that part for later.
And later never comes.
ELI5
The explain it like I’m five strategy helps you fit a complex concept into a box that your brain has already mapped out, so that’s what we are going to do today by breaking it down using as many analogies as I can.
How has authentication changed?
The traditional multi-tier application has generally used the process of taking the credentials from the user directly, doing a password check, and then authorizing.
ELI5: You know “open sesame”? This is like going up to your local brewpub and having to speak a password like “open sesame” to get in. The pub has to keep track of every customers password. People nearby could hear you say it and then use it to get in under your bar tab. Not only that, but you need your own password for every bar you go to. Both you and the bar staff have to keep track of all the passwords. Some bars are staffed by goons that forget shit half the time, ya know?
Modern authentication is a transfer of ownership of the identity and password managing process. Storing passwords is risky. Software teams each rolling their own security methods, requiring users to remember multiple passwords, this is how you get pwned.
The modern strategy
The solution is letting someone who has leagues more experience than you handle it. Passwords, multi-factors, personal information, all safe and secure in one place _outside of your app’s database. You can’t be pwned if you’ve got nothing worth pwning!
The modern strategy, known as claims-based authentication and authorization is configuring your application to use tokens that provide the identity and access rules of your users.
Have you ever used the Login with Google/Twitter/LinkedIn buttons on your favorite apps? What is happening behind the scenes is claims-based authentication.
Instead of storing passwords and authentication/authorizing your users, your app outsources that task to a company like Google.
One common analogy is that of the driver’s license. Instead of remembering passwords for each brewpub, you just establish your identity once with your local governments licensing department and the bar staff can just verify your driver’s license.
The licensing department (like Google) manages the security of your identity and stores your identity claims on your driver’s license (an identity token) like your name and true date of birth.
The driver’s license also uses cryptography to prevent tampering, as well as proving that it came from your local government. Now you can use your driver’s license in most places to prove your identity.
So, what is the actual implementation of that analogy?
The actual protocols
As the you’ll find out, there is a ton of jargon and mixed terminology in the space. Terms that mean the same thing but used in weird ways. Terms that replace old terms but then sometimes use the old term instead… yikes.
The main set of protocols that implement claims-based authentication are SAML, Shibboleth, OAuth, OAuth2, and OpenID Connect.
All of these are simply standards for what an identity token should look like, what it should contain, and how it should be passed around.
They actually evolved in that order too, and at the time of writing this article, OpenID Connect is the one of the latest evolutions, so it’s most likely what you should use.
ELI5: Eventually we will probably be able to use our phone or our eyeball to prove our identity at the bar. You could use your driver’s license, but that’s old and slow!
The protocols implementing modern authentication are like that.
You have options, some are better than others, but they all just prove your identity in some shape or form. The driver’s license card is like the token format, compared to the JWT (JSON Web Token) format of the OpenID Connect protocol or the SAML XML format of the SAML protocol.
Let’s stop there
Let’s go a little deeper into the actual protocols next. I’m going to do the next essays a little differently by bundling them into a 4-part email series (sign up below).
We’ll dive into the inner workings of the protocols in another explain like I’m five rendition. You’ll actually be able to fit terms like OAuth2 in a nice little box in your mind.