What is OAuth?

OAuth is the industry standard protocol for secure authorization, enabling applications to access resources on behalf of a user without sharing their credentials. It provides user-consented access and allows restricted actions on resources. It is a system that helps apps, websites, and devices work together safely. It lets an app use your data from another service (like letting a game use your Google account) without sharing your password. It's used on many platforms like websites, phone apps, and smart devices to keep your information secure while allowing apps to do what you’ve allowed them to.

Key Concepts in OAuth

1. Resource Owner (User): The user who owns the data and grants permission to the application to access their data.

2. Client (Application): The application requesting access to the resource owner's data.

3. Resource Server: The server that holds the user's data (e.g., Google, Facebook).

4. Authorization Server: The server that issues tokens to the client after authenticating the resource owner and obtaining authorization.

5. Access Token: A short-lived token the client uses to access the resource server.

OAuth Scopes

OAuth scope defines what specific actions or data an application is allowed to access on behalf of a user. It's like setting boundaries for what an app can do with your account or data. They are used to specify exactly the reason for which access to resources may be granted. It places the payload data in the JWT tokens.

OAuth 2.0 Authorization Code Flow

1. User → Application Client:

   • The user opens the Application Client (like a mobile app or web app) and starts an action that needs access to a protected resource, such as user data from Google or Facebook. It’s a kind of opening the login page of the

2. Application Client → Authorization Page:

   • The Application Client redirects the user to the Authorization Page (hosted by the Authorization Server). The URL typically includes the following:

     • client_id (the identifier of the application)

     • redirect_uri (where the user will be sent after granting permission)

     • scope (the permissions the app is requesting)

     • response_type=code (indicating the Authorization Code flow)

3. User → Give Access by Clicking Allow → Authorization Page:

   • The Authorization Page presents the user with a login screen (if the user isn't logged in already). The user then enters the userId either username/email and passsword to complete the authentication process. But typically, for granting the access from the third party such as google, github, etc, the system asks them to grant access by clicking "Allow" or "Authorize" to give the Application Client permission to access their data.

4. Authorization Page → Authorization Server:

   • Once the user grants permission, the Authorization Page sends them back to the Authorization Server with an authorization code, verifying their consent. How can we understand this one; the system generates the code to exchange the token.

5. Authorization Server → Authorization Page:

   • The Authorization Server checks the request, and if the user has allowed access, it creates an authorization code. This code is then added to the URL (e.g., https://client.com/callback?code=AUTHORIZATION_CODE) and sent back to the Authorization Page.

6. Authorization Page → Application Client:

   • The Authorization Page sends the user back to the Application Client with an authorization code attached to the redirect link (e.g., https://client.com/callback?code=AUTHORIZATION_CODE). It is the same code that will exchange the JWT token.

7. Application Client → Application Server:

   • The Application Client takes the authorization code it got from the Authorization Page and sends it to its Application Server to ask for an access token.

8. Application Server → Authorization Server:

   • The Application Server sends a request to the Authorization Server's token endpoint, including:

     • The authorization code (received from the Authorization Page)

     • The client secret (to authenticate the app)

     • The redirect URI (for validation purposes)

9. Authorization Server → Application Server:

   • The Authorization Server checks the request to make sure the authorization code, client ID, and client secret are correct. If everything is valid, it sends back an access token (and sometimes a refresh token). The Application Server can use this access token to make secure API requests.

10. Application Server → Resource (Source) Server:

• The Application Server now uses the access token to safely request information from the Resource Server (like Google API or Facebook API). This lets it access the user's protected data, such as profile details or files. The same token can further used in the backend system to authorize the endpoints.