Used to do DevOps before they even called it that way: Linux. Python. Perl. Java. Docker. For fun and profit. CTO level generalist working for a mid-sized tech-centric company.
Dresden, Germany
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.