OAuth (Open Authorization) enables third-party websites or apps to access users’ data without requiring them to share their credentials.
It is a set of rules that makes access delegation possible.
The user gets to authorize which resources an app can access and limits access accordingly.

🧱 Terminologies

Term	Description
Client 📦	The application that seeks access to resources. Usually, the third party.
Resource Owner 👤	The user who owns the resources. It can also be a machine 🤖 (E.g., Enterprise scenarios).
Resource 🖼	Could be images, data exposed via APIs, and so on.
Resource Server 📚	Server that hosts protected resources. Usually, an API server that serves resources if a proper token is furnished.
Authorization Server 🛡	Server responsible for authorizing the client and issuing access tokens.
User-Agent 🌐	The browser or mobile application through which the resource owner communicates with our authorization server.
Access Token 🔑	A token which is issued as a result of successful authorization. An access token can be obtained for a set of permissions (scopes) and has a pre-determined lifetime after which it expires.
Refresh Token 🔄	A special type of token that can be used to replenish the access token.

An end-user (resource owner 👤) grants a printing service (app 📦) access to their photo (resource 🖼) hosted in a photo-sharing service (resource server 📚), without sharing their username and password. Instead, they authenticate directly with a server trusted by the photo-sharing service (authorization server 🛡), which issues the printing service delegation-specific credentials (access token 🔑).

Note that our app (client) has to be registered in the authorization server in the first place.
A Client ID is returned as a result.
A client secret is also optionally generated depending on the scenario.
This secret is known only to the authorization server and the application.

Flows in OAuth 2.0

Authorization Code Grant flow

It is a popular browser-based authorization flow for Web and mobile apps.
In the diagram below, the flow starts from the Client redirecting the user to the authorization endpoint.

This flow is optimized for confidential clients.
- Confidential clients are apps that can guarantee the secrecy of client_secret.
A part of this flow happens in the front channel (until the authorization code is obtained).
The access_token 🔑 exchange step happens confidentially via back-channel (server-to-server communication).

Authorization Code Grant with PKCE

Public clients using authorization code grant flow have security concerns.