First off, there's a lot of resources out there on what is the OAuth2 protocol and how it came to be. What I'm going to try to do is collect it all in this post including where it originated from and what's the future of it. Please feel free to comment if something is incorrect. After all, the best way to learn is to teach right?
If you want a TL;DR, as always scroll to the bottom.
By definition, OAuth is a protocol that allows a resource owner to authorize clients to access a website or non-website server. This is important because it allows the resource owner to determine what areas the client can see which is convenient if you have proprietary or confidential IP. Typically, the authorization is granted via Access Tokens, an encrypted string that represents the granted permissions (or scopes). The API will then determine what scopes the client is authorized for and return back the data. For example, a Menu app would accept differing levels of authorization:
Within the OAuth 2.0 flow, there are the following roles that come into play.
This is taken from Auth0's page on OAuth 2.0 which I would highly recommend for further learning.
This is a high level overview of the flow and each step can be explained in further detail, enough to constitute it's own page so I will remain general and elaborate into further detail in another page. However, an important aspect of OAuth 2.0 is to know how the authentication works.
So first off, there is a difference between authentication and authorization. Authentication means that the entity has been validated to be who it claims to be. Authorization on the other hand refers to rules that determine who is allowed to do what. A good example of this is if you think of an application as a house. Authentication would be the owner of the house allowing Bob to enter the house. Once you have proven that you are Bob, you will be allowed to enter. Authorization in this case would be the owner telling Bob that he may enter the kitchen but not the master bedroom.
Now that we have defined the two, it will make more sense that OAuth 2.0 is an authentication protocol although due to scopes, it has some pseudo authorization aspects too. How the authentication works is that the protocol has two endpoints: Authorization and Token. What happens is that once a client has requested access to the resource server, the server will redirect the client to a consent screen where credentials can be entered. Assuming the credentials are valid, the client is given a response token and redirected back to the original page. I am sure you are familiar with this, this can be seen in many login screens where you can "Login via Facebook" or "Login via Github". Both of those options redirect you to the prospective login pages where you authorize the client's permission to access and then you are redirected back to the client.
Depending on the Authorization flow, the response token can return back a Refresh Token as well. This is generally used by web applications that are server side so the source code is not exposed to the public. Since the code is not exposed to the public, in this flow the response token will contain
refresh_token. So much information is exposed in this flow to allow a client and the resource server to interact with less, if any, user interaction. Given that information, the client can call the Authorization endpoint and use the
refresh_token to renew the
access_token since typically the
access_token has a shorter duration. For example, the access token can expire every 24 hours whereas the refresh token can expire every 100 days.
Honestly, there is a lot of complexities and intricacies of OAuth 2.0. But Auth0 did an incredibly good job of simplifying a generic flow so I will just post their diagram here. They explain a lot of concepts easily and I did my best to summarize the information in a single page here for ease of use.