For further actions, you may consider blocking this person and/or reporting abuse
For further actions, you may consider blocking this person and/or reporting abuse
DevOps Descent -
Blessing Ndubuisi -
iAmSherif 💎 -
Habdul Hazeez -
Top comments (3)
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.
OAuth is all about delegating Authorization (choosing someone who can do Authorization for you). Note that Authentication and Authorization are different things. OAuth is Authorization (Access control), and if you want to implement Authentication (ID verification) also, OpenID protocol can be used on top of OAuth.
All big companies like Facebook, Google, Github,... use this kind of authorization nowadays. For example, I just signed in on this website using my Github account, this means dev.to doesn't know my password, dev.to receives the allowance from github.com where my password (hashed obviously) is saved.
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.