OAuth Basic Concepts for Beginners

By Posted on

What is OAuth and why is it widely used in applications?

OAuth stands for Open Authorization, a standard used to grant access permissions between two applications without requiring the user to share their password.

With OAuth, users can grant limited permissions to other applications to access some of their data, such as their profile, email, or photos, without providing their password.

Real-life example:

Imagine you want to print photos from your Google Drive account using an online printing application.
For the application to retrieve your photos, you don’t need to provide your Google account password, right?

Instead, you grant permission to the application through Google.
Google then provides the application with an “access token,” which is only valid for specific features and for a specific time.

That’s the essence of OAuth, sharing access without sharing passwords.

Why is OAuth Necessary?

Without OAuth, many security issues can arise:

  • Third-party applications must store user passwords → very risky.
  • There’s no way to restrict access (all or nothing).
  • It’s difficult to revoke permissions without changing passwords.

With OAuth, all of this becomes more secure:

  • Passwords remain secure (never shared).
  • Access can be restricted (for example, to only “read emails,” not “delete emails”).
  • Permissions can be revoked at any time.

Basic OAuth Flow (Step by Step)

Let’s use an example: you log in to the “MyTask” app using your Google account.

1. The user clicks “Sign in with Google.”

The MyTask app doesn’t ask for your Google password.
Instead, the app redirects the browser to Google’s login page.

2. Google asks the user for permission.

    Google displays a permission page that looks like this:

    “Will you allow MyTask to access your name and email address?”

    You can select “Allow” or “Deny.”

    3. Google sends an “Authorization Code.”

      If you click “Allow,” Google will return a temporary code to the MyTask app (via a redirect URL).
      This code, called an Authorization Code, is only valid for a short time.

      4. The app exchanges the code for an “Access Token.”

        The MyTask app sends this code to Google’s servers (not through the browser), along with the client secret (the app’s secret key).
        Google then sends an Access Token, and sometimes also a Refresh Token.

        5. The app uses the token to access data

          Now MyTask can send requests to the Google API using that token: 

          GET https://www.googleapis.com/userinfo?access_token=XYZ

          Google replies with user data (name, email, etc.).
          The app never knows your password!

          6. Tokens can expire

            Access tokens are usually only valid for a few minutes or hours.
            Once they expire, the app can use a Refresh Token to request a new token — without needing to log in again.

            Visual Overview of OAuth Flow

            [1] User clicks "Sign in with Google"
    ↓
[2] Redirect to Google (Authorization Server)
    ↓
[3] User logs in and allows access
    ↓
[4] Google sends an Authorization Code to the application
    ↓
[5] Application exchanges code → Access Token
    ↓
[6] Application uses Access Token to retrieve user data

            Difference Between OAuth and OAuth 2.0

            Release date

              OAuth 1.0 is the first version of this standard (released in 2007). OAuth 2.0 is the second version and a major improvement (released in 2012).

              They are not backward compatible — meaning, applications using OAuth 2.0 cannot directly talk to servers that only support OAuth 1.0.

              The Concept

              Both OAuth 1.0 and OAuth 2.0 have the same goals:

              “Granting third-party applications permission to access user data without sharing passwords.”

              But the way to achieve this is very different, especially in terms of security and ease of implementation.

              Differences Table

              AspectOAuth 1.0OAuth 2.0
              Main goalFocused on security using signature-based verificationFocused on simplicity and flexibility
              Request security methodEvery request must be digitally signed (HMAC-SHA1)Uses HTTPS (SSL/TLS) to ensure security
              Implementation complexityComplex – each request needs cryptographic signature generationSimpler – just use access tokens with HTTPS
              Token typesRequest Token + Access TokenAccess Token, Refresh Token, and optionally ID Token (for OpenID Connect)
              Primary use caseInitially used for small web APIs (e.g., old Twitter API)Widely used by modern platforms (Google, Facebook, GitHub, etc.)
              Standard directionOutdated, rarely used todayModern and widely adopted global standard

              In short:

              OAuth 1.0 was very secure but hard to implement.
              OAuth 2.0 is easier, faster, and now the industry standard.

              Happy Coding!!!