How OAuth Works: A Developer’s Perspective

When I first read about OAuth, I thought it was just another login system: like “Sign in with Google.” But when I had to integrate Zapier with our platform, I realized OAuth isn’t login, it’s delegated access.

That realization made everything click.

Here is the developer-focused understanding of OAuth and how it works.

The Core Idea

OAuth exists to let one system access another on behalf of a user — securely, without sharing passwords. Basically, OAuth gives limited access, secured without sharing actual password with the other application. It gives a token only to limited access to data. Examples like:

Zapier wants to access our platform’s API to fetch new leads.
“Sign in with Google” button on lots of websites

That’s OAuth in one line: “Give access without giving credentials”

OAuth 2.0 Flow

This is the most common and secure OAuth flow for server based applications. Let’s go step by step to understand more using Zapier example

Step 1: Authorization Request For Client (Zapier)

Zapier redirects the user to the platform’s OAuth’s endpoint, by calling the OAuth’s endpoint / API with it’s details like client id, redirect url, scope, response type, etc

GET /oauth2/authorize? 
  client_id=zapier-client& 
  redirect_uri=https://zapier.com/oauth/callback& 
  response_type=code& 
  scope=read:leads

API – /oauth2/authorize	Your OAuth Authorize endpoint/API to initialize authentication for user
client_id	OAuth client id to connect with.
redirect_uri	Once success, on which URL OAuth should share the tokens or authorization code
response_type	It tells the server which authorization grant flow to use and what type of credential to return, in our case : code
scope	Define scope of the access

After processing, platform shows consent screen asking something like “Zapier wants to access leads?”. If the user approves, OAuth sends a authorization code on the redirect URL.

Step 2: The Client Exchanges the Code for a Token

Once the Zapier receives the authorization code, it calls the token exchange API to get tokens.

POST /oauth2/token 
Content-Type: application/x-www-form-urlencoded 
grant_type=authorization_code 
code=abc123 
client_id=zapier-client 
client_secret=supersecret 
redirect_uri=https://zapier.com/oauth/callback

API – /oauth2/token	Your OAuth token endpoint/API to generate tokens
client_secret	A secret key required to generate token for that specific client

If the client secret and client id matches then OAuth server gives as access token & refresh token

Step 3: The Client Uses the Access Token

To use the token, tokens need to be stored somewhere. Like Zapier stores the token and use that token at the time of calling get lead API

GET /api/leads 
Authorization: [access token]

Here, /api/leads is our API will be called by Zapier, our server validates token -> confirms the permission and then gives the lead data to Zapier.

Step 4: Token Expiry and Refresh

Access token usually have a one hour time limit, after that it expires. There is a lifespan limit for access token and refresh token that can be configured in the client details.

Instead of reauthenticating (going with login & consent & token generation), we can use refresh token to generate new access token.

POST /oauth2/token 
grant_type=refresh_token 
refresh_token=[your refresh token] 
client_id=zapier-client 
client_secret=supersecret

Here, grant_type is refresh_token that’s how OAuth understands that I need to use the refresh token to generate new access token. Here! At the time of refreshing access token, new refresh token is also generated and given back to the server(Zapier) as response.

This ensures long-term secure access without re-prompting the user every time.

Developer’s Mental Model: Think in Tokens

If you’re new to OAuth, here’s the way to think about it:

Access Token = “temporary permission slip (Temporary access)”
Refresh Token = “ID card that lets you get new permission slips (Refreshes the access token)”
Authorization Code = “proof that the user said yes (Consent accepted)”

Why Developer needs to know about OAuth?

If you’re integrating with any external platforms like Slack, Google, Zapier, or GitHub then OAuth is unavoidable. You have to go through OAuth and its ecosystem and then only then you can go with your integrations.

Once you understand OAuth:

You can build integration faster.
You can design secure APIs.
You can debug token issues confidently

And if your product doesn’t yet support OAuth, adding it (like we did with ORY Hydra: see blog Blog4_ Why OryHydra_ Comparing with Keycloak OAuth.docx) opens up your ecosystem to a world of automation and integrations.

Final Thoughts

When OAuth finally clicked for me, it wasn’t about tokens or grant types. It was realizing that OAuth is trust delegation between systems, and as developers, we’re just wiring that trust correctly.

Every time you see a “Connect with Google” button prompt, that’s OAuth quietly doing its job behind the scenes. Once you understand that, the rest things like tokens, scopes, grants are just implementation details.