DEV Community: G Ghuman

Understanding OAuth2 the Simple Way

G Ghuman — Fri, 14 Aug 2026 11:32:49 +0000

Understanding OAuth2 the Simple Way

You are building a side project and want users to log in with their Google accounts instead of making up yet another password they'll forget. So you open the OAuth2 spec. Ten minutes later, you are staring blankly at a wall of terminology about "Resource Owners," "Authorization Grants," and "Bearer Tokens," wondering if you should just use a plaintext database table and call it a day.

Every tutorial on the internet tries to explain OAuth2 with an analogy about valet keys at a restaurant. I don't want a valet key. I want to know why my redirect URI is returning a 400 Bad Request and how to get an access token without losing my sanity.

Let's skip the car analogies and look at how this actually works.

The Core Concept: Delegation, Not Authentication

Here is the first trap everyone falls into: treating OAuth2 as a login system.

It isn't one. OAuth2 is an authorization framework. It is designed to answer one question: Can application X access resource Y on behalf of user Z?

Authentication answers "Who are you?" (That's OpenID Connect, which is built on top of OAuth2, but we'll ignore that for a second). OAuth2 answers "What are you allowed to do?"

Imagine you built a little CLI tool that automatically backs up your GitHub repositories to a local drive. Your script needs access to your private repos, but you definitely don't want to hardcode your GitHub password into a Python file.

Instead, you want to go to GitHub, log in yourself, look at a scary warning screen that says "This app wants read access to your repositories," and click "Authorize." GitHub then hands your script a temporary backstage pass (an access token). Your script uses that pass to grab your code.

That handshake is OAuth2.

The Authorization Code Flow (The One You'll Actually Use)

There are several "grant types" in the OAuth2 spec. Ignore all of them except the Authorization Code Flow.

If you are building a traditional web app with a backend server, this is the flow you need. It keeps your app's secret key safe on the server where users can't see it in their browser dev tools.

Here is how the dance goes step by step:

The Redirect: Your app sends the user to the identity provider (like Google or GitHub) with a URL that says, "Hey, send this user back to /callback when they log in, and tell them I need read:user permissions."
The Consent: The user logs into Google, sees the consent screen, and clicks "Allow."
The Code: Google redirects the user back to your app's /callback route with a temporary code stuck in the query string. This code is not the access token. It's a single-use receipt.
The Exchange: Your backend takes that receipt, walks up to Google's token endpoint behind the scenes (along with your client secret), and trades it for the actual Access Token.

Let's look at what that token exchange looks like in practice. Here is a quick Node.js snippet using axios hitting a mock provider:

const axios = require('axios');

async function exchangeCodeForToken(authCode) {
  try {
    const response = await axios.post('https://oauth.example.com/oauth/token', {
      client_id: process.env.CLIENT_ID,
      client_secret: process.env.CLIENT_SECRET,
      code: authCode,
      grant_type: 'authorization_code',
      redirect_uri: 'http://localhost:3000/callback'
    }, {
      headers: { 'Content-Type': 'application/json' }
    });

    // This is what you actually care about
    const { access_token, refresh_token, expires_in } = response.data;

    return access_token;
  } catch (error) {
    // Spoiler: You will hit this catch block a lot at first
    console.error('Token exchange failed:', error.response.data);
    throw new Error('OAuth dance failed');
  }
}

Making the Authenticated Request

Once you have that access_token safely stored in a secure, HTTP-only cookie or a session, using it is anti-climactic. You just slap it into the HTTP headers of your API requests.

import requests

def get_user_profile(access_token):
    url = "https://api.example.com/v1/user/profile"

    headers = {
        "Authorization": f"Bearer {access_token}",
        "Accept": "application/json"
    }

    response = requests.get(url, headers=headers)

    if response.status_code == 401:
        print("Token expired or invalid. Time to use that refresh token.")
        return None

    return response.json()

That Bearer prefix trips people up. It literally means "Hand this token to whoever is bearing it." If someone steals your access token, they can impersonate the user until it expires. That is why keeping tokens out of localStorage in single-page apps matters so much—any rogue XSS script can read localStorage and steal your bearer tokens.

The Gotchas That Will Waste Your Afternoon

When I first wired this up, I spent three hours debugging a redirect_uri_mismatch error from Google. Everything looked identical. The string in my code matched the string in the Google Cloud Console down to the last slash.

Except it didn't. I had http://localhost:3000/callback in my code, but http://localhost:3000/callback/ (with a trailing slash) registered in the dashboard. OAuth implementations are aggressively literal. If a single character is off, they lock the door and give you zero helpful context.

Another common pitfall is ignoring token expiration. Access tokens are designed to be short-lived—sometimes expiring in 15 minutes. If your app crashes because a user's token expired while they were filling out a form, your UX is broken. You have to implement the refresh token cycle, which means storing that second token securely and asking the auth server for a fresh access token behind the scenes when the first one dies.

Finally, don't write your own OAuth2 server unless you are doing it purely for fun on a weekend. Use Auth0, Keycloak, Supabase, or Firebase Auth. Implementing the spec securely—handling state parameters to prevent CSRF, managing PKCE for mobile apps, handling token rotation—is tedious security plumbing that has already been solved a thousand times.

Next Steps

Open up your terminal, pick an API you use daily (GitHub or Spotify have great, developer-friendly docs), and register a new developer application in their dashboard. Don't write any code yet—just use Postman or curl to manually trigger the authorization URL in your browser, grab the code from the redirect, and paste it into a manual POST request to get your first token.

Once you trace the round-trip manually with your own eyes, the magic trick loses its mystery.

Step-by-Step: Setting Up a Mobile App Development Environment

G Ghuman — Fri, 14 Aug 2026 08:31:05 +0000

Step-by-Step: Setting Up a Mobile App Development Environment

Getting a mobile development environment running on your machine is a rite of passage, mostly because it usually takes three hours and involves downloading about fifteen gigabytes of software you didn't know existed.

If you're coming from web development, the shift is jarring. In web dev, you save a file and your browser refreshes. In mobile dev, you're compiling native binaries, managing virtual devices that eat your RAM for breakfast, and dealing with two completely different ecosystems that actively try not to get along.

I recently had to set up a fresh MacBook for React Native and Flutter work. Here is the exact path through the setup swamp, minus the dead ends I hit along the way.

1. The Command Line Foundation (Homebrew and Node)

Don't download installers from random websites if you can avoid it. You want a package manager so you can actually update your tools next year without crying.

On macOS, Homebrew is non-negotiable. If you're on Linux, your native package manager handles most of this, and if you're on Windows, you should probably be using WSL2, though that's a whole separate therapy session.

Open your terminal and install Homebrew if you haven't already:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Once that finishes, the installer usually prints a couple of "Next steps" lines to add Brew to your PATH. Do not ignore them, or your terminal will pretend it has no idea what brew is the second you close the window.

Next, grab Node.js. Even if you aren't building a React Native app, almost every mobile toolchain relies on Node somewhere under the hood for build scripts or CLI runners.

brew install node

Verify it worked. If node -v spits out a version number, you're ready for the heavy machinery.

2. Android Studio and the SDK Monster

You need Android Studio even if you plan to build iOS apps later. Why? Because you need the Android SDK, the build tools, and the emulator manager. You don't actually have to write code in Android Studio—you can use VS Code or whatever editor you prefer—but you cannot escape installing it.

Download Android Studio from the official site and run the installer. When you get to the setup wizard, choose Custom setup. Do not just click Next on everything. You want to make sure the following components are checked:

Android SDK
Android SDK Platform
Performance (Intel HAXM or AMD equivalent, depending on your chip)
Android Virtual Device

Once it installs, open the SDK Manager (it's hidden in the settings menus). Go to the SDK Platforms tab and make sure you have at least one recent version installed—Android 14 (API 34) is a safe bet right now.

Then switch to the SDK Tools tab and check these boxes:

Android SDK Build-Tools
Android Emulator
Android SDK Platform-Tools

Here is the gotcha that wasted an hour of my life: your terminal doesn't know where any of this lives by default. You have to wire up your environment variables.

Open your shell configuration file (~/.zshrc or ~/.bash_profile) in your text editor and paste these lines at the bottom:

export ANDROID_HOME=$HOME/Library/Android/sdk
export PATH=$PATH:$ANDROID_HOME/emulator
export PATH=$PATH:$ANDROID_HOME/platform-tools
export PATH=$PATH:$ANDROID_HOME/cmdline-tools/latest/bin

Save the file, then run source ~/.zshrc to apply the changes. If you type adb into your terminal now, it should print a list of commands instead of saying "command not found."

3. Xcode (Mac Only) and iOS Simulator Quirks

If you're on a Mac and want to build for iOS, you have to deal with Xcode. Head over to the Mac App Store and download it.

Fair warning: Xcode is massive—well over 30GB depending on what components it decides to pull down. Start the download, go make a sandwich, watch an episode of something, and come back. It takes a while.

Once Xcode is installed, open it at least once. It needs to prompt you to install additional required components and agree to the license agreement. If you skip this and try to run a build from the command line, Xcode will fail silently or throw an obscure exit code that means nothing.

Next, install the command-line tools:

sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer
sudo xcodebuild -runFirstLaunch

You'll also want to install CocoaPods, which is the dependency manager for iOS. Don't use sudo gem install cocoapods if you can avoid it—it messes with system ruby permissions. Use homebrew instead:

brew install cocoapods

To test if your iOS simulator is working without spinning up a whole project yet, you can boot one directly from the terminal:

xcrun simctl boot "iPhone 15"
open -a Simulator

If a shiny virtual iPhone pops up on your screen, you're in business.

4. Creating and Running Your First Test Project

Let's verify everything actually talks to each other. We'll use React Native's CLI for this test because it touches both Android and iOS toolchains.

Create a blank sandbox project:

npx @react-native-community/cli init TestEnvironmentApp
cd TestEnvironmentApp

Now, open two separate terminal tabs.

In tab one, start the Metro bundler:

npm start

In tab two, try launching the Android build:

npm run android

If your Android emulator spins up, builds the app, and displays the default React Native welcome screen without throwing a Gradle build error, your environment is solid.

If it fails with a Gradle error about Java versions, don't panic. Mobile tools are notoriously picky about Java Development Kit (JDK) versions. Android Studio installs its own JDK, but sometimes your system points to an older global version. You can check your Java version with java -version. Most modern mobile frameworks expect JDK 17.

To test iOS (assuming you're on a Mac), run:

cd ios && pod install && cd ..
npm run ios

The simulator should automatically compile the native iOS binary and load the app.

Next Step

Open your terminal right now, type adb devices or spin up an iOS simulator to verify your paths are still working after closing your terminal window. Once you confirm a virtual device boots up cleanly, pick a framework—React Native, Flutter, or native Swift/Kotlin—and run their official "Hello World" tutorial while your environment is still fresh.