A Beginner-Friendly Guide to API Authentication & Authorization: Lessons from Real-World APIs

Have you noticed that every secure API starts with two simple questions?

1. Who are you? 2. What are you allowed to do?

If you can’t answer those questions, well-built APIs will lock the door in your face, politely, but firmly.

Here, I tried to understand how APIs decide who can enter and what they can do. So I picked GitHub’s API and tested two authentication methods myself:

✔ Personal Access Token (PAT) ✔ OAuth App

I used Postman for PAT testing and a regular web browser for OAuth and below is my full breakdown.

Step 1 — AuthN vs AuthZ (The Real Heart of API Security)

Before touching GitHub, I needed to understand two words that everyone throws around:

Authentication (AuthN) → Who are you?

Think of it like inserting your ATM card and entering your PIN. You are proving “Yes, this is me.”

In APIs, the “PIN” might be a token, password, or API key.

Authorization (AuthZ) → What are you allowed to do?

Now that the bank knows it’s you, can you withdraw $10,000 today? Authentication alone doesn’t guarantee that. Authorization checks your limits.

In GitHub, authorization comes from token scopes; read, write, admin, etc.

Why this matters

Because you can confirm identity and still be blocked if you lack permissions. AuthN proves you are real. AuthZ decides what doors open for you.

A secure API must check both.

Step 2 — Looking Into GitHub’s Authentication Options

GitHub has several ways to prove identity when using its API:

GitHub Authentication Options:

→ Personal Access Tokens (PAT)

→ OAuth Apps

→ GitHub Apps

→ Username + Password (deprecated)

→ GitHub Actions

I focused on PAT and OAuth because they are the simplest to explore manually, and perfect for showing AuthN vs AuthZ in action.

Step 3 — My Hands-On Test With a Personal Access Token (PAT)

Test A — Calling the API without authentication

I opened Postman and made a GET request to:

https://api.github.com/user

And of course, it was rejected instantly.

Postman returned:

401 Unauthorized

401 Unauthorized

No identity, no entry.

Create a Personal Access Token

To test AuthN properly, I generated a PAT:

GitHub → Settings → Developer settings → Personal access tokens → Generate new token

What I did differently:

I only selected one scope → read:user (no write permissions, no repo access, nothing dangerous)

Copied the token and saved it somewhere safe.

Test B — Call GitHub API again, but with the PAT

In Postman:

1. Authorization → Bearer Token
2. Paste the PAT
3. Send request again

GET https://api.github.com/user

This time I got:

200 OK ✔

User authenticated

The API recognized me, Authentication success.

I was allowed to view my user profile because my token had read permission.

Read my repos

Test C — Now I intentionally tried to break authorization

Still using the same exact PAT…

I requested something out of scope:

I tried to create a repository secret, which requires the write:actions scope.

PUT https://api.github.com/repos/YOUR_REPO/actions/secrets/TEST_SECRET

With this JSON body:

{
  "encrypted_value": "dummy_value",
  "key_id": "dummy_key"
}

And GitHub replied:

403 Forbidden ❌

Going out of scope

Not because it didn’t know who I was… but because my token was not allowed to do that operation.

PAT Test Result

AuthN passed → I proved identity

AuthZ failed → I lacked permission

Authentication and Authorization are not the same. And this demonstrates the difference.

Step 4 — Testing OAuth (The Human-Consent Side of Security)

PATs are like giving someone your house key. OAuth is like opening the door only when they knock, and only to specific rooms.

Here’s how I tested GitHub OAuth without writing code.

Create an OAuth App

GitHub → Settings → Developer settings → OAuth Apps → New OAuth App

I used:

Application Name → OAuth Demo Test

Homepage URL → https://example.com

Callback URL → https://example.com/callback

After saving, GitHub gave me a Client ID and Client Secret.

Request Authorization Through Browser

I pasted this in my browser, replacing the client ID:

https://github.com/login/oauth/authorize?client_id=YOUR_CLIENT_ID&scope=read:user

And I saw a page asking me to authorize access. Yes, it asked for my permission.

OAuth authentication

I clicked Authorize, and GitHub redirected me with a code. That code could be exchanged for a token.

OAuth redirect

Authorized application

OAuth showed me:

✔ Identity must be verified (AuthN) ✔ User must approve access (AuthZ) ✔ App permissions are limited by scope

It is good for third-party integrations but a much safer option is GitHub Apps because it gives fine-grained permissions.

Strengths & Weaknesses

PAT:

Great for → Personal scripts, quick testing

User Control → Medium (scopes only)

Risk if exposed → High (like a password)

Setup → Very simple

My experience → Easy to test with Postman

OAuth:

Great for → Third-party apps, shared access

User Control → High (explicit approval + revocable)

Risk if exposed → Lower (scoped + revocable)

Setup → More steps

My experience → Great for understanding consent flow

Final Thoughts

🔹 A PAT let me authenticate quickly, the API recognized me. 🔹 OAuth slowed me down intentionally, because it prioritizes consent and permission.

One proves identity (AuthN). The other controls power (AuthZ).

And any secure API needs both.

If you read this far, thank you! I hope this guide makes authentication feel less abstract and more real.