Explain OAuth like I'm Five

Did you find this post useful? Show some love!

There's a new kid in your class. You’re not sure if you can trust him, so you wouldn’t necessarily believe him if he tells you that his name is Billy. So you send him to the teacher and ask her to confirm that it’s him. Because she has Billy’s school record, she recignizes him and tells you so. You know you can trust the teacher, so you accept that the new boy is called Billy.

Here, Billy is the end-user/browser, you are the application making use of OAuth as a way to let users log in, and the teacher is the OAuth provider.

This (and the DigitalOcean tutorial linked in the comment) is a great explanation:

At a very high level, think of it as of a software variant of a (paper) passport: This is being granted to you by a central authority who "knows" who you are, so the passport is a pretty strong proof of your identity. With this passport, you can walk around and identify yourself in places where this is required (maybe your bank in order to have access to your accounting information, your rental car company to, well, rent a car, or your travel agency to buy plane tickets). All these want to know for sure you are "who you are", and the passport is a strong way to prove this. And it pretty much eases "real-world authentication" because you have one agreed-upon document with a well-defined meaning and a well-defined source of trust, so you don't need to care much about how to check if this person in front of you is actually who (s)he pretends to be.

OAuth is similar to this: A central instance (authentication service) validates your identity based upon certain information you provide (login name, password, maybe two-factor-authentication like a pin entered to a smartphone, ...) and provides you with a "token" (which is the digital representation of the passport in the example above). With this "token", you then may access certain services - your e-mail account, your Instagram account, your dev.to account, ... - with each of these services "trusting" the token because they "trust" the central instance in this case. For certain services, this eases the task to validate whether a user is "who (s)he claims to be".

I guess this is what it boils down to. It's of course a bit more complex in real implementation. Have a look at digitalocean.com/community/tutoria... for a more technical yet still straightforward introduction.

Classic DEV Post from Feb 26

Self-Deprecation Needs to 🛑

My thoughts on self-deprecation in tech.

Follow @mauricehayward to see more of their posts in your feed.
Pratik Ambani
Life is POC 😇
More from @pratikaambani
Explain idempotency (in REST) like I'm Five
#explainlikeimfive #rest #webservices #discuss
Explain Cross Site Scripting(XSS) attacks like I'm Five
#discuss #javascript #xss #explainlikeimfive
Trending on dev.to
Journey to fullstack engineering.
#beginners #programming #career
Resources for Getting into DevOps?
#help #discuss #devops
What was your worst experience with a programming language?
#discuss #programming #python #experience
Rails Sprockets Vulnerability
#rails #sprockets #security #heroku
What are some good questions for a "State of the Web" survey?
#webdev #discuss
Fast way to build CRUD app?
#discuss #programming
Its 2018, why are you still going to the office?
Who uses Telegram at work?