is a security standard that alows an app to access resources and actions of a 3rd party platform like Google or Facebook.

is a framework where a user of a service can allow a third-party application to access his/her data hosted in the service without revealing his/her credentials (ID & password) to the application.

this protocol is not for authentication and not really for authorization. It is for delegated authority. It grants authority to an application.

Authentication deals information about "who one is". Authorization deals information about "who grants what permissions to whom". Authorization flow contains authentication as its first step. It is the reason people are often confused.

There are many libraries and services that use OAuth 2.0 for authentication. It is often called "social login" and It makes people more confused. If you see "OAuth authentication" (not "OAuth authorization"), it is a solution using OAuth for authentication.

access token authorizes an application to access resources or make actions on behalf of the user. For example: a microsoft access token gives the app permission to the users OneDrive or Microsoft Graph(API).

most of the time in OAuth flow, the user has to give consent to share the specific resources your app requests. It never (or shouldn't) gain full control of all resources, only the ones needed.

user doesn't share Google credentials with your app.
your app doesn't gain control of the user or see the user's password on the 3rd party provider.

flow

the usual flow to grant authorization with OAuth is the following:
resource owner wants to grant client access to resources of a 3rd party service.

1. authenticate: client redirect user's browser to authorization server. redirected to a login page of the provider.
   with the req is included client id, redirect uri, response type and scope.
2. server verifies who user is and if necessary prompts for a login.
3. after verified, server presents user with consent form to permissions.
4. user gets redirected to callback url alongside a temp authorization code.
5. client sends back authorization code along client id and client secret. it does not use the user's browser.
6. server responds with access token.

access token is a value the client doesn't understand, it could interpret it as a random string. It uses this token to send reqs to the resource server.

vocabulary

• resource owner: the user
• client: your app
• authorization server: server that knows the user (Google for ex)
• resource server: API or service the client wants to use on behalf of the owner.
  sometimes authorization server and resource server are the same server.
• redirect URI or callback URL: url the auth server will redirect the resource owner back to after granting permission to the client.
• response type: the type of info the client expects to receive. client typically expects an authorization code or token.
• scope: the granular permissions the client wants (read, write, delete...)
• client Id: is used to verify the client with the authorization server.
• client secret: password that only the client and authorization server know.
• authorization code: shortlived temp code the authorization server sends to the client -> the client sends the authorization code back to server along with client secret -> server sends back access token
• access token: the key the client will use to comunicate with resource server.

Benefits:

• ease of use for user:
  • user already has a google or facebook account.
  • registering is 1 click
  • no need to remember password for your site

disadvantages:

• app depends on 3rd party

sources

• https://oauth.net/2/
• https://stackoverflow.com/questions/33702826/oauth-authorization-vs-authentication
• https://www.youtube.com/watch?v=t18YB3xDfXI