OAuth 2.0 Authorization Flow

0

OAuth 2.0 (Open Authorization 2.0) is a protocol(delegation/authorization protocol) that allows third-party applications to obtain limited access to a user’s resources without exposing the user’s credentials. It’s a framework that provides authorization workflows for web applications, desktop applications, mobile phones, and other devices. Here’s a more detailed look at OAuth 2.0:

Key Concepts:

  1. Resource Owner:
    • The user who authorizes an application to access their account.
  2. Client:
    • The application requesting access to the user’s resources.
  3. Authorization Server:
    • The server that issues the access tokens to the client after successfully authenticating the resource owner and obtaining their authorization.
  4. Resource Server:
    • The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
  5. Access Token:
    • A token that represents the authorization granted to the client by the resource owner.
  6. Refresh Token:
    • A token used to obtain a new access token when the current one expires.

OAuth 2.0 Authorization Flow:

  1. Authorization Request:
    • The client requests authorization from the resource owner. This is typically done through a user-agent (browser).
  2. Authorization Grant:
    • The resource owner grants authorization to the client. This authorization is represented by an authorization grant (e.g., an authorization code).
  3. Authorization Code Exchange:
    • The client exchanges the authorization grant for an access token at the authorization server.
  4. Access Token Request:
    • The client requests an access token from the authorization server by presenting the authorization grant.
  5. Access Token Response:
    • The authorization server authenticates the client and validates the authorization grant, then issues an access token.
  6. Access Resource:
    • The client uses the access token to access the protected resources on the resource server.

Example:

Consider a user having google account and want to register/sing up to WX.com using the existing google account.

OAuth 2.0 Flow Explanation:

Step-by-Step Explanation:

User Log In (WX.com)

  • Description: A user attempts to log in to the application (Wix.com) by clicking on a “Login with Google” button on Wix.com.
  • Additional Info: This button initiates the OAuth 2.0 authorization process.
  1. Redirect to Google Authorization Server
    • Description: The user is redirected to the Google Authorization Server.
    • Redirect URL containing parameters such as
      • client_id
        • A unique identifier(Ex client_id=abc123) assigned to the client (application Ex wx.com) by the authorization server during the registration process of Wx.com with authorization provider.
      • Redirect_uri
        • The URL to which the authorization server will send the user after the authorization process is completed.
        • It ensures that the authorization code or access token is sent to the correct application.(ex redirect_uri=https://example.com/callback)
      • Response_type-
        • Specifies the type of response the client expects from the authorization server.
        • Common Values-
          • code: The client expects an authorization code. Used in Authorization Code Grant
          • token: The client expects an access token directly. Used in Implicit Grant
      • Scope
        • A space-separated list of permissions that the client is requesting from the resource owner
        • It defines the level of access the client is requesting (e.g., read access to user emails, write access to user calendars
        • Example: scope=profile email
    • Additional Info: These parameters specify the app’s identity, the callback URL, the type of response expected, and the access permissions requested.
    • User Authentication at Google
      • Description: The user logs in to their Google account or selects an existing logged-in account.
      • Additional Info: After authentication, Google asks for consent to share specific user data with Wix.com.
    • Sample Redirect URI with all the above information is available at the end of page-https://codallt.com/wp-content/uploads/2024/07/image-1-1024×210.png
  2. User Consent (Permission Grant)
    • Description: The user grants permission to Wix.com to access their profile information.
    • Additional Info: Google displays the permissions requested by Wix.com, such as email, profile picture, etc.
    • Temporary Authorization Code Issued
      • Description: Google provides a temporary authorization code and this code is sent to the callback URL specified earlier (redirect_uri).
      • Additional Info: This code is short-lived and is used to obtain an access token.
  3. Authorization Code Sent to Wix.com application server
    • Description: The authorization code is received by Wix.com.
    • Additional Info: Wix.com then uses this code to request an access token from Google.
  4. Access Token Request
    • Description: Wix.com requests an access token from Google Authorization Server using the authorization code.
    • Correction: Clearly show the exchange process with parameters such as code, client_id, client_secret, redirect_uri, and grant_type.
    • Additional Info: This step verifies Wix.com’s identity and authorization code validity.
  5. Access Token Issued
    • Description: Google Authorization Server issues an access token.
    • Additional Info: The access token allows Wix.com to access the user’s Google profile information.
  6. Resource Request Using Access Token
    • Description: Wix.com uses the access token to request user information from Google Resource Server.
    • Additional Info: The access token must be included in the authorization header of the request.
  7. Resource Server Responds
    • Description: Google Resource Server responds with the requested user information (e.g., email, profile picture).
    • Additional Info: Wix.com can now use this information to complete the user login process or registration.

Benefits of OAuth 2.0:

Use Cases:

  • Security: The user doesn’t share their credentials with the third-party application.
  • User Experience: Users can authorize applications to access their data without sharing their passwords.
  • Flexibility: OAuth 2.0 supports various types of applications and use cases.
  • Scalability: OAuth 2.0 can be used across multiple devices and platforms.

Use Cases:

  • Single Sign-On (SSO): Users can sign in to multiple applications using a single set of credentials.
  • Third-Party Access: Applications can access user data from another service (like accessing Google contacts from a CRM).
  • API Authorization: Secure access to APIs without the need for direct user credential handling.

Leave a Reply

Your email address will not be published. Required fields are marked *