Coder Legion - Recent posts tagged oauth

AdMob Earnings Dashboard for iOS: OAuth with PKCE, AdMob Reporting API and Offline Caching

Mon, 26 Oct 2026 12:42:23 +0000

Originally published at https://bestlatestapps.com/blog/building-an-admob-earnings-dashboard-for-ios/

Signing in with ASWebAuthenticationSession and PKCE, storing tokens safely in the Keychain, calling networkReport:generate, decoding a streamed report, turning micros into money, why "today" is a Los Angeles day, live earning rates, and caching for offline use

If you have apps with ads, you know the habit: open the AdMob website on your phone, pinch, zoom, wait for the dashboard, then do it again an hour later. I wanted a native, fast, glanceable view of my AdMob earnings, so I built AdEarnings Pro. It's a dashboard for today's earnings, yesterday's comparison, earning rates per second, minute and hour, weekly averages for earnings and clicks, six months of history and currency conversion. It uses Google Sign-In, and the listing states plainly: "Your AdMob data is not saved, shared, or accessible to us."

That promise shapes the whole architecture. There's no server of mine in the middle. The app talks directly to Google's AdMob API using the user's own OAuth token, and everything is cached on the device.

This article walks through how to build that: OAuth for a native app done properly, the AdMob Reporting API's actual request and response format, and a few surprises from Google's documentation. The biggest is that the report time zone currently supports only America/Los_Angeles, which changes what "today" means for everyone outside California. Apple APIs are checked against Apple's documentation and Google APIs against Google's. Where I describe my approach rather than the shipped code, I say so.

1. The shape of the app: no middleman

The data flow is deliberately short:

The user signs in with Google and grants a read-only reporting scope.
The app stores the refresh token in the Keychain, on the device.
The app calls admob.googleapis.com directly with a short-lived access token.
Results are cached locally for offline viewing.

Google's AdMob API getting-started guide lists two scopes. admob.readonly lets an app "See all AdMob data", and Google notes that this "doesn't include sensitive data, such as payments or campaign details". admob.report lets it "See ad performance and earnings reports. See publisher ID, timezone, and default currency code." For an earnings dashboard, admob.report is the narrowest scope that works, and asking for the minimum is both good privacy and good for consent rates. Google's OAuth guide makes the same point: the fewer scopes you request, the more likely users are to grant them.

The listing also notes "This app requires access to your existing Google AdMob account". The API reads accounts; it can't create one.

2. OAuth for a native app: system browser, PKCE, no embedded web views

Google's OAuth documentation is blunt about embedded web views. Opening the authorization page in WKWebView produces a disallowed_useragent error, and Google recommends its Google Sign-In for iOS library or AppAuth instead. Both are built on the same standard flow: the system browser plus PKCE (Proof Key for Code Exchange). Here's that flow with Apple's own ASWebAuthenticationSession (iOS 12+), so you can see every step:

import AuthenticationServices
import UIKit
import CryptoKit
import Foundation

struct PKCE {
    let verifier: String
    let challenge: String

    /// Google: verifier is 43–128 chars of [A-Z a-z 0-9 - . _ ~]; S256 challenge = BASE64URL(SHA256(verifier)).
    static func make() -> PKCE {
        var bytes = [UInt8](repeating: 0, count: 32)
        _ = SecRandomCopyBytes(kSecRandomDefault, bytes.count, &bytes)
        let verifier = Data(bytes).base64URLEncoded()                     // 43 chars
        let challenge = Data(SHA256.hash(data: Data(verifier.utf8))).base64URLEncoded()
        return PKCE(verifier: verifier, challenge: challenge)
    }
}

extension Data {
    func base64URLEncoded() -> String {
        base64EncodedString().replacingOccurrences(of: "+", with: "-")
            .replacingOccurrences(of: "/", with: "_").replacingOccurrences(of: "=", with: "")
    }
}

@MainActor
final class GoogleAuth: NSObject, ASWebAuthenticationPresentationContextProviding {
    // An iOS OAuth client in Google Cloud; its redirect uses the reversed client ID as the scheme.
    let clientID = "1234-abc.apps.googleusercontent.com"
    var redirectScheme: String { "com.googleusercontent.apps.1234-abc" }
    var redirectURI: String { "\(redirectScheme):/oauth2redirect" }

    func signIn() async throws -> (code: String, pkce: PKCE) {
        let pkce = PKCE.make()
        let state = UUID().uuidString
        var url = URLComponents(string: "https://accounts.google.com/o/oauth2/v2/auth")!
        url.queryItems = [
            .init(name: "client_id", value: clientID),
            .init(name: "redirect_uri", value: redirectURI),
            .init(name: "response_type", value: "code"),
            .init(name: "scope", value: "https://www.googleapis.com/auth/admob.report"),
            .init(name: "code_challenge", value: pkce.challenge),
            .init(name: "code_challenge_method", value: "S256"),
            .init(name: "state", value: state)
        ]

        let callback: URL = try await withCheckedThrowingContinuation { cont in
            let session = ASWebAuthenticationSession(url: url.url!, callbackURLScheme: redirectScheme) { url, error in
                if let url { cont.resume(returning: url) } else { cont.resume(throwing: error ?? URLError(.cancelled)) }
            }
            session.presentationContextProvider = self
            session.prefersEphemeralWebBrowserSession = false   // reuse an existing Google session if there is one
            session.start()
        }

        let items = URLComponents(url: callback, resolvingAgainstBaseURL: false)?.queryItems ?? []
        guard items.first(where: { $0.name == "state" })?.value == state,       // CSRF check
              let code = items.first(where: { $0.name == "code" })?.value else { throw URLError(.userAuthenticationRequired) }
        return (code, pkce)
    }

    func presentationAnchor(for session: ASWebAuthenticationSession) -> ASPresentationAnchor {
        UIApplication.shared.connectedScenes.compactMap { ($0 as? UIWindowScene)?.keyWindow }.first ?? ASPresentationAnchor()
    }
}

Every parameter here comes from Google's OAuth documentation for installed apps:

The authorization endpoint is accounts.google.com/o/oauth2/v2/auth.
response_type=code is required.
The challenge is S256, which Google recommends.
The verifier is 43 to 128 characters. Thirty-two random bytes, base64url-encoded, gives exactly 43.
state protects against cross-site request forgery. Google calls it out as important, and the code checks it.

On iOS 17.4 and later, ASWebAuthenticationSession also accepts a Callback object (ASWebAuthenticationSession.Callback). SwiftUI has a webAuthenticationSession environment value from iOS 16.4. Either is a tidier wrapper around the same flow.

3. Exchanging the code and keeping tokens safe

Next, swap the code for tokens at oauth2.googleapis.com/token, sending the PKCE verifier (not the challenge). Google's docs note that client_secret doesn't apply to iOS clients:

struct TokenResponse: Decodable {
    let access_token: String
    let expires_in: Int
    let refresh_token: String?
    let scope: String
}

extension GoogleAuth {
    func exchange(code: String, pkce: PKCE) async throws -> TokenResponse {
        try await tokenRequest([
            "client_id": clientID, "code": code, "code_verifier": pkce.verifier,
            "grant_type": "authorization_code", "redirect_uri": redirectURI
        ])
    }

    func refresh(using refreshToken: String) async throws -> TokenResponse {
        try await tokenRequest(["client_id": clientID, "grant_type": "refresh_token", "refresh_token": refreshToken])
    }

    private func tokenRequest(_ form: [String: String]) async throws -> TokenResponse {
        var request = URLRequest(url: URL(string: "https://oauth2.googleapis.com/token")!)
        request.httpMethod = "POST"
        request.setValue("application/x-www-form-urlencoded", forHTTPHeaderField: "Content-Type")
        var body = URLComponents(); body.queryItems = form.map { URLQueryItem(name: $0.key, value: $0.value) }
        request.httpBody = body.percentEncodedQuery?.data(using: .utf8)
        let (data, _) = try await URLSession.shared.data(for: request)
        return try JSONDecoder().decode(TokenResponse.self, from: data)
    }
}

Then store the refresh token in the Keychain, never in UserDefaults, and mark it device-only:

import Security

enum TokenVault {
    static let account = "admob.refresh"

    static func save(_ token: String) {
        let base: [String: Any] = [kSecClass as String: kSecClassGenericPassword,
                                   kSecAttrAccount as String: account]
        SecItemDelete(base as CFDictionary)
        var item = base
        item[kSecValueData as String] = Data(token.utf8)
        item[kSecAttrAccessible as String] = kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
        SecItemAdd(item as CFDictionary, nil)
    }
}

AfterFirstUnlockThisDeviceOnly lets a widget or a background refresh read the token after the first unlock, while keeping it out of backups and off other devices. Two of Google's notes are worth building in. First, check the returned scope: users can grant less than you asked for, and the app should explain what's missing. Second, there are limits on how many refresh tokens are issued per client and user, so keep and reuse the refresh token rather than signing in again each time.

"Revoke consent anytime" maps to two things. The user can remove access from their Google Account settings, and the app can call https://oauth2.googleapis.com/revoke?token=… on sign-out and then delete the Keychain item.

4. Asking AdMob for a report

The AdMob API's core endpoint is accounts.networkReport.generate, a POST to https://admob.googleapis.com/v1/accounts/{publisherId}/networkReport:generate with a reportSpec. Here's a request for daily earnings and clicks over the last seven days:

struct ReportDate: Codable { let year: Int, month: Int, day: Int }

struct NetworkReportRequest: Encodable {
    struct Spec: Encodable {
        struct Range: Encodable { let startDate: ReportDate; let endDate: ReportDate }
        struct Localization: Encodable { let currencyCode: String; let languageCode: String }
        let dateRange: Range
        let dimensions: [String]
        let metrics: [String]
        let localizationSettings: Localization
        let timeZone: String
    }
    let reportSpec: Spec
}

func weeklyRequest(endingOn end: ReportDate, start: ReportDate, currency: String) -> NetworkReportRequest {
    .init(reportSpec: .init(
        dateRange: .init(startDate: start, endDate: end),
        dimensions: ["DATE"],
        metrics: ["ESTIMATED_EARNINGS", "CLICKS", "IMPRESSIONS"],
        localizationSettings: .init(currencyCode: currency, languageCode: "en-US"),
        timeZone: "America/Los_Angeles"
    ))
}

Three facts from Google's reference page shape this request:

ESTIMATED_EARNINGS is in micros. "$6.50 would be represented as 6500000." Never put that number in a Double and divide casually; use Decimal.
Currency comes from localizationSettings.currencyCode. Google says the currency unit of the earnings metrics is "determined by the localization setting for currency". The approach I'd use for "View earnings in your preferred currency" is to ask AdMob for that currency directly, so the figures are AdMob's own.
The time zone currently has only one supported value. Google: "Warning: The 'America/Los_Angeles' is the only supported value at the moment." Section 6 is about what that means.

5. Decoding a streamed report

The response isn't a simple object. It's "the result of a server-side streaming RPC": a JSON array whose first element has a header, then one row per result, then a footer. Each element has exactly one of those keys. So decode each element as an enum-like struct:

struct ReportChunk: Decodable {
    struct Row: Decodable {
        struct DimensionValue: Decodable { let value: String }
        struct MetricValue: Decodable { let microsValue: String?; let integerValue: String?; let doubleValue: Double? }
        let dimensionValues: [String: DimensionValue]
        let metricValues: [String: MetricValue]
    }
    let header: [String: AnyDecodable]?      // dateRange, localizationSettings
    let row: Row?
    let footer: [String: AnyDecodable]?      // matchingRowCount, warnings
}

struct AnyDecodable: Decodable { init(from decoder: Decoder) throws {} }   // we don't need header details here

struct DailyEarnings: Codable, Identifiable {
    var id: String { day }
    let day: String          // "20261022"
    let earnings: Decimal    // in report currency
    let clicks: Int
}

func parse(_ data: Data) throws -> [DailyEarnings] {
    try JSONDecoder().decode([ReportChunk].self, from: data).compactMap(\.row).map { row in
        let micros = Decimal(string: row.metricValues["ESTIMATED_EARNINGS"]?.microsValue ?? "0") ?? 0
        return DailyEarnings(day: row.dimensionValues["DATE"]?.value ?? "",
                             earnings: micros / 1_000_000,
                             clicks: Int(row.metricValues["CLICKS"]?.integerValue ?? "0") ?? 0)
    }
}

Google's example response shows "microsValue": 6500000 as a bare number. The API's JSON mapping for 64-bit integers often uses strings, so I'd decode both forms in production (a small custom init(from:)). The DATE dimension value is YYYYMMDD, as Google's reference describes.

Displaying money is then earnings.formatted(.currency(code: currency)). Don't hand-roll formats, because symbol placement and grouping vary by locale.

6. Why "today" is a Los Angeles day

Here's the subtle part. If reports can only be in America/Los_Angeles, then AdMob's "today" starts at midnight Pacific time. For me in India, that's 12:30 or 1:30 in the afternoon, depending on US daylight saving. A dashboard that labels the latest row "Today" without explanation will confuse anyone outside the Pacific time zone.

The approach I'd use is to compute "today" in the report's calendar and say so in the UI:

struct ReportCalendar {
    static let zone = TimeZone(identifier: "America/Los_Angeles")!
    static var calendar: Calendar { var c = Calendar(identifier: .gregorian); c.timeZone = zone; return c }

    static func reportDate(for date: Date = .now) -> ReportDate {
        let c = calendar.dateComponents([.year, .month, .day], from: date)
        return ReportDate(year: c.year!, month: c.month!, day: c.day!)
    }

    /// Seconds elapsed in the current *report* day; the denominator for live rates.
    static func secondsIntoReportDay(now: Date = .now) -> TimeInterval {
        now.timeIntervalSince(calendar.startOfDay(for: now))
    }
}

The live earning rates in the listing ("per second, minute, and hour") follow naturally. Today's earnings divided by seconds into the report day gives an average rate so far:

func rates(todayEarnings: Decimal, now: Date = .now) -> (perSecond: Decimal, perMinute: Decimal, perHour: Decimal) {
    let seconds = Decimal(max(ReportCalendar.secondsIntoReportDay(now: now), 60))   // avoid tiny denominators just after midnight
    let perSecond = todayEarnings / seconds
    return (perSecond, perSecond * 60, perSecond * 3600)
}

Label it honestly, as "average so far today". Ad revenue isn't evenly spread over a day, and AdMob's figures are estimated earnings that can be revised.

7. Pull to refresh, offline cache and the weekly view

"Pull-to-refresh for fresh data" is one modifier, refreshable (iOS 15+). "Offline-ready with cached data" means saving the last good response, with a timestamp, and showing it whenever the network fails:

import SwiftUI

@MainActor
final class Dashboard: ObservableObject {
    @Published private(set) var days: [DailyEarnings] = []
    @Published private(set) var updatedAt: Date?
    private let cacheURL = URL.cachesDirectory.appending(path: "report-week.json")

    init() {
        if let data = try? Data(contentsOf: cacheURL),
           let cached = try? JSONDecoder().decode(Cached.self, from: data) {
            days = cached.days; updatedAt = cached.at                   // instant first paint, even offline
        }
    }

    func refresh(using api: AdMobAPI) async {
        do {
            let fresh = try await api.lastSevenDays()
            days = fresh; updatedAt = .now
            try? JSONEncoder().encode(Cached(days: fresh, at: .now)).write(to: cacheURL, options: .atomic)
        } catch {
            // Keep showing the cache; the "Updated 2 h ago" label tells the user it's stale.
        }
    }

    var weeklyAverage: Decimal {
        days.isEmpty ? 0 : days.map(\.earnings).reduce(0, +) / Decimal(days.count)
    }

    private struct Cached: Codable { let days: [DailyEarnings]; let at: Date }
}

struct DashboardView: View {
    @StateObject private var model = Dashboard()
    let api: AdMobAPI
    var body: some View {
        List {
            if let updatedAt = model.updatedAt {
                Text("Updated \(updatedAt, format: .relative(presentation: .named))").font(.caption)
            }
            ForEach(model.days.reversed()) { day in
                LabeledContent(day.day, value: day.earnings, format: .currency(code: "USD"))
            }
        }
        .refreshable { await model.refresh(using: api) }
        .task { await model.refresh(using: api) }
    }
}

Putting the cache in Caches is deliberate. It's disposable, it's re-fetchable, and it holds only aggregated numbers from the user's own account on the user's own device. That fits the listing's privacy statement. (AdMobAPI here is the small wrapper around section 4's request, with a valid access token.)

8. Real-world example: AdEarnings Pro

This walkthrough comes from building AdEarnings Pro. The code above is the approach I'd use, written for this article, not a copy of the app's source.

At the time of writing, its App Store listing shows:

Free, in Developer Tools
First released in November 2025
No ratings yet in the US store
Supports iOS 17.6 and later

How the listing maps to this article:

What the listing says	Where it's covered
"Secure Google Sign-In authentication" / "Google OAuth authentication is required to access AdMob API services"	System-browser OAuth with PKCE, tokens in the Keychain (sections 2–3)
"Your AdMob data is not saved, shared, or accessible to us"	Direct device-to-Google calls, no middleman (section 1)
"View today's earnings with live updates. Compare yesterday's performance."	`networkReport:generate` with the `DATE` dimension (sections 4–5)
"Live earning rates per second, minute, and hour"	Rates over the Pacific report day (section 6)
"Weekly average trends for earnings and clicks"	`ESTIMATED_EARNINGS` and `CLICKS` (sections 4 and 7)
"Convert earnings to any currency…"	`localizationSettings.currencyCode` (section 4)
"Pull-to-refresh for fresh data" / "Offline-ready with cached data"	`refreshable` and a timestamped cache (section 7)
"Revoke consent anytime"	Google Account settings and the revoke endpoint (section 3)

The listing also mentions unpaid earnings, last payment history and GDPR consent management. Those are outside this article's scope.

9. Before you ship an OAuth-powered dashboard: a checklist

Use the narrowest scope that works, and check the granted scope in the token response.
Use the system browser, PKCE (S256) and a state check. No WKWebView for sign-in.
Keep the refresh token in the Keychain, device-only, and reuse it.
Sign-out revokes the token and clears the Keychain and caches.
Handle money as Decimal from micros, formatted with the currency's own format.
Make the report time zone explicit. "Today" is a Pacific day, and the UI says so.
Label rates and estimates honestly: "average so far" and "estimated".
Show cached data instantly, with a visible "Updated…" time.
Complete Google's OAuth app verification if your scopes need it before public release. Google's docs describe an "unverified app" screen otherwise.
No third-party analytics touches the earnings data.

Wrapping up

An earnings dashboard looks like a chart, but it's mostly about trust. Sign in the way Google and Apple both recommend, ask for the least access, keep tokens on the device, talk to the API directly, and be honest about what the numbers mean, including the surprising fact that AdMob's "today" is a Los Angeles day. Get those right, and a glance at your phone replaces a dozen trips to a desktop website.

Try the app, or explore my other work:

AdEarnings Pro (iOS): https://apps.apple.com/us/app/adearnings-pro/id6754509445
All of my free iOS apps: https://apps.apple.com/us/developer/alok-singh/id1508795536
My portfolio: https://bestlatestapps.com/alok/

What's the one metric you check most in your ad dashboard? Tell me in the comments.

— Alok Kumar Singh

Originally published at https://bestlatestapps.com/blog/building-an-admob-earnings-dashboard-for-ios/

OAuth Is Not “Login.” I Found That Out the Hard Way in Production

Fri, 16 Oct 2026 17:09:26 +0000

Most people, including a lot of engineers, think OAuth means “the button that says Sign in with Google.” That’s not wrong exactly, but it’s like saying a car is “the thing with a steering wheel.” Technically true, misses basically everything that matters.

I want to actually walk through what OAuth is, why it exists, what it costs you, and the specific way it bit me in production, because the bug taught me more about OAuth than any tutorial did.

If I use a term that sounds like engineer-speak, I’ll flag it like this:

🚨 Jaggy jaggy alert: here’s the jargon, here’s what it actually means in plain English.

Let’s go.

What OAuth actually is
OAuth is not a login system. OAuth is a permission system. It answers one question: “can this app do this specific thing on my behalf, without me handing it my password?”

That’s it. That’s the whole idea.

Before OAuth, if you wanted some third party app to, say, post to your Twitter or read your Gmail contacts, you had exactly one option: give that app your actual Twitter or Gmail password. The app would log in as you, directly, using your real credentials. Which means that random app now has full access to your account forever, until you go change your password, and even then you’re trusting a third party company stored your password responsibly in the first place.

OAuth replaces that with a system where you never hand your password to the third party app at all. Instead, you briefly go to Google (or whoever), log in there, and Google hands the app a token, a kind of limited, revocable permission slip, instead of your actual credentials.

🚨 Jaggy jaggy alert: token. Think of it as a hotel key card instead of your house key. It opens specific doors, for a specific amount of time, and the hotel can deactivate it instantly without you having to change your actual house locks.

Could the internet work without OAuth
Technically, yes. Plenty of early 2000s apps worked exactly how I described above, you just gave them your password. It’s not that the internet collapses without OAuth.

What actually happens without it is worse in a slower, quieter way. Every app you connect to anything ends up holding a copy of your real password. A breach at any one of those apps means your actual account password leaks, not just some limited token. You can’t selectively revoke access (“let this app see my calendar but not send emails as me”) because the app either has your full password or it has nothing. And you can’t tell your bank, your email provider, or your social accounts “trust these five apps, not that one,” because from their point of view every connected app looks identical: someone logged in with your password.

So yes, the world could work without OAuth. It would just be a world where a breach anywhere is a breach everywhere, and “revoke access” isn’t really a button that exists.

A quick word on OAuth 1.0, the version before this one
Before the OAuth everyone actually uses today, there was OAuth 1.0, back around 2007. Same basic idea, token instead of password, but the mechanics were painful. Every single request had to be cryptographically signed by the app using a shared secret, a process involving HMAC-SHA1 and exact timestamps, before the server would trust it.

🚨 Jaggy jaggy alert: cryptographic. Just means “based on math that’s specifically designed to be really, really hard to fake or reverse without the right secret ingredient.” When something is described as cryptographically secure, breaking it isn’t impossible, it’s just so expensive and slow that nobody sane bothers trying.

🚨 Jaggy jaggy alert: signature (signing). Not a handwritten signature. A short code generated from the actual contents of a message plus a secret value, proving two things at once: this message wasn’t altered in transit, and it genuinely came from whoever holds that secret. Change one character of the message and the signature stops matching, which is exactly how tampering gets caught.

🚨 Jaggy jaggy alert: secret. A private value, basically a password, known only to the two parties who are supposed to trust each other. Whoever holds the secret can prove they are who they claim to be. Whoever doesn’t, can’t fake it convincingly. The whole system falls apart the moment that “secret” stops actually being secret.

🚨 Jaggy jaggy alert: HMAC-SHA1 signing. A way of mathematically stamping each request so the server can verify nothing was tampered with in transit, instead of just trusting an encrypted connection to do that job. You don’t need the math, just know it meant extra, fiddly cryptography homework on every single request.

In practice this meant developers spent real time fighting signature mismatches and clock sync issues instead of building their actual app. It worked, but it was miserable, and it still assumed every app had somewhere safe to keep a permanent secret. OAuth 2.0 showed up in 2012 and basically said, let’s just lean on HTTPS to protect the data in transit like everyone already does for everything else, and drop the per-request signing entirely.

🚨 Jaggy jaggy alert: HTTPS. The padlock in your browser’s address bar. It encrypts everything traveling between your browser and the server, so anyone snooping on the connection, a nosy coffee shop WiFi for instance, sees scrambled nonsense instead of your actual data. OAuth 2.0 leans on this instead of signing every request itself, which is most of why it’s so much simpler than OAuth 1.0.

Simpler for developers, which is exactly why OAuth 2.0 is the one that actually won and is what the rest of this article has been describing the whole time.

But that “every app has somewhere safe to keep a secret” assumption didn’t go away, it just got quietly inherited by OAuth 2.0. And a few years later, that assumption stopped being true for a huge chunk of apps. More on that in a minute.

How it actually works, the short version
Here’s the flow in plain English, using “Sign in with Google” as the example:

You click the button. The app sends you over to Google, not the other way around, you never type your Google password into the third party app’s own form. At Google, you log in (or you’re already logged in) and Google shows you a screen saying “This app wants to see your email and profile picture, allow it?” You say yes. Google then redirects you back to the app with a short-lived code. The app takes that code and, behind the scenes, trades it with Google for an actual token. From then on, the app uses that token to ask Google for the specific things you approved, nothing more.

🚨 Jaggy jaggy alert: scope. A scope is the specific permission being requested, like “read your email address” or “post on your behalf.” Apps are supposed to ask for the narrowest scope that does the job, though in practice a lot of apps ask for way more than they need, because broader scopes are easier to code against and nobody’s really checking.

Download the Medium app
🚨 Jaggy jaggy alert: redirect URI. This is the exact web address Google is allowed to send you back to after login. It’s locked in advance when the app registers with Google, specifically so an attacker can’t trick Google into sending your freshly issued code to some address they control instead.

That whole flow above quietly assumes one more thing: that the app trading the code for a token is a proper backend server, one that can hold onto a permanent, secret password of its own (a “client secret”) to prove to Google “yes, this request really is from the real app.” Which brings us to a problem nobody really had to think about back in 2012.

The problem nobody saw coming, apps that can’t keep a secret
Fast forward a few years and suddenly half the apps in the world are single-page apps running entirely in the browser, or mobile apps sitting on someone’s phone. A SPA’s entire codebase gets shipped straight to the user, anyone can pop open dev tools and read it line by line. A mobile app’s installer can be decompiled by anyone with a weekend and mild curiosity. There is nowhere to actually hide a secret in either case. Whatever you bake in, someone can pull back out, which is a uniquely bad punchline for something literally called a “client secret.”

🚨 Jaggy jaggy alert: client secret. A password-like value, known only to the real backend and Google, used to prove a token request is genuinely coming from the real app and not an imposter. Fine when there’s a server to keep it locked up. Useless the moment the “app” is just JavaScript running on a stranger’s laptop.

The fix is called PKCE, Proof Key for Code Exchange, and it’s pronounced “pixie,” which might be the single most delightful name in all of security engineering.

🚨 Jaggy jaggy alert: PKCE. Instead of a long-lived secret baked into the app, the app invents a random, one-time value right before login starts, the code verifier, and sends over a hashed version of it, the code challenge, when kicking off the flow. At the very end, when trading the code for a token, it has to produce that original, un-hashed value again. If someone intercepts the authorization code mid-flow, it’s useless to them, they don’t have the random value that generated it, and they can’t fake having it either.

🚨 Jaggy jaggy alert: hashing. A one-way math function that turns any input into a fixed-length scrambled output, and crucially, you can’t run it backwards to get the original input out again. Same input always produces the same output, which is exactly what makes it useful here, the app can prove “I know the original value” without ever saying the original value out loud until the very last step.

No permanent secret to leak, because there was never a permanent secret to begin with, just a fresh, disposable value that self-destructs after one use. Genuinely a cleaner idea than the thing it replaced, and these days it’s recommended for basically every app, server backed or not.

The trade-off nobody puts on the slide
Here’s what the “just add OAuth” tutorials gloss over: you’re trading simplicity for control, and that trade costs real engineering effort.

With a plain username and password system, you own the entire flow. One table, one hashing function, done. With OAuth, you now depend on a third party’s uptime, their API changing underneath you, tokens that expire and need refreshing, and an entire second system, your own backend, that has to track who’s logged in even though the actual login happened somewhere else entirely.

🚨 Jaggy jaggy alert: refresh token. Access tokens are deliberately short-lived, often an hour or less, so if one leaks, the damage window is small. A refresh token is a longer-lived, more sensitive token your backend holds onto quietly, so it can go get a fresh access token without making the user log in again every hour. Lose control of a refresh token and you’ve basically lost control of the session, so these need to be stored far more carefully than access tokens.

That’s the actual trade-off. You get: no passwords for you to store or leak, users can revoke access with one click from Google’s side, scoped and limited permissions, and single sign-on convenience. You pay for it with: more moving parts, a dependency on an external provider, token lifecycle management, and a genuinely larger surface area for things to quietly go wrong.

How I actually use this in production
On one platform I worked on, we had Google OAuth as a social login option sitting alongside our own email and password system, with our own JWT issued after either path succeeded.

🚨 Jaggy jaggy alert: JWT. Short for JSON Web Token. This is different from an OAuth access token, even though people use the words interchangeably all the time. A JWT is a signed, self-contained token your own backend creates, that your own backend can verify without a database lookup, basically a sealed, tamper-proof note saying “this is user 482, and I, the server, vouch for that.” OAuth tokens come from Google. JWTs, in this setup, come from us.

That distinction, two different kinds of token doing two different jobs, is exactly where things went wrong for me once.

What actually goes wrong: my real production bug
We had a production authentication bug where users were randomly getting logged out, or logged in as the wrong state, with no clear pattern. Intermittent, hard to reproduce locally, the worst kind of bug.

The root cause, once I actually traced it through production logs, was almost embarrassingly simple: the OAuth token coming back from the social login flow and our own JWT were both being stored under the same cookie key. Whichever one got written last silently overwrote the other. So depending on timing, a user’s session cookie might end up holding Google’s OAuth token instead of our own JWT, or vice versa, and the backend would try to verify it as the wrong type of token entirely, fail, and drop the session.

Nobody designed it that way on purpose. It happened because OAuth tokens and JWTs look similar enough, both are just strings you shove in a cookie, that it’s easy to treat them as interchangeable “auth stuff” instead of two distinct tokens with two distinct lifecycles and two distinct purposes. The fix was straightforward once I actually understood the distinction: give each token its own, clearly named cookie key, so they could never collide again.

The real lesson wasn’t the one line fix. It was that OAuth tokens and your own session tokens are not the same thing wearing a different hat, and treating them as the same thing is exactly the kind of assumption that only breaks in production, under real timing and real concurrent requests, never in your local dev environment where everything happens conveniently one at a time.

Other pitfalls worth knowing before you hit them
A few more ways this goes sideways, things I’ve seen or would actively watch for:

Storing tokens in localStorage instead of an httpOnly cookie, which means any cross-site scripting vulnerability on your site can just read the token straight out and walk away with the user's session.

🚨 Jaggy jaggy alert: httpOnly cookie. A cookie flagged so that JavaScript running in the browser can’t read it at all, only the browser itself can send it along with requests. It’s a deliberate wall against exactly the kind of theft I just described.

Mismatched redirect URIs between what’s registered and what the app actually sends, which just breaks login outright and is a surprisingly common first deploy bug when you move from a local dev URL to a real production domain and forget to register the new one.

Asking for way more scopes than you need, which makes users nervous at the consent screen and gives you a bigger blast radius if your token ever does leak.

Treating “the user has an OAuth token” as “the user is logged in” without actually verifying who they are. OAuth by itself is about authorization, what you’re allowed to do, not identity. Actual login on top of OAuth is a separate layer called OpenID Connect, and conflating the two is a genuinely common source of security bugs.

So, do you actually need it
If you’re building something small and internal, OAuth is probably overkill, a simple username and password system with properly hashed passwords is less to maintain and less to get wrong. OAuth earns its complexity the moment you want users to log in with an identity they already have elsewhere, or you want to act on a third party service on their behalf without ever touching their password. At that point, yes, deal with the token juggling, because the alternative, a world where “give the app your password” is normal, is worse in ways that only show up after something’s already gone wrong.

That’s the real shape of it. Not a login button. A permission system, with real trade-offs, that will absolutely find the one gap in your assumptions if you let two different tokens share a cookie key and call it a day.

Your NextAuth callbackUrl Might Be an Open Redirect Waiting to Happen

Mon, 12 Oct 2026 10:39:32 +0000

Redirecting a user back to the page they were trying to reach after they log in is good, expected UX. Nobody wants to log in and land back on the homepage when they were actually trying to read a specific article or check out a specific product. The common way this gets implemented is also a common way to accidentally build an open redirect vulnerability directly into your auth flow.

The Pattern That Looks Completely Reasonable

// app/login/page.tsx
export default function LoginPage({ searchParams }: { searchParams: { callbackUrl?: string } }) {
  return (
    <form action={async (formData: FormData) => {
      'use server';
      const result = await signIn('credentials', {
        email: formData.get('email'),
        password: formData.get('password'),
        redirect: false,
      });

      if (result?.ok) {
        redirect(searchParams.callbackUrl || '/dashboard');
      }
    }}>
      {/* form fields */}
    </form>
  );
}

This is a genuinely common pattern, a protected page redirects an unauthenticated visitor to /login?callbackUrl=/dashboard/reports, and after a successful login, the app sends them back to wherever that parameter points. It works correctly, and it feels like a small, harmless convenience feature, right up until someone realizes that callbackUrl value came straight from a query string the visitor controls entirely.

What an Attacker Actually Does With This

https://yourapp.com/login?callbackUrl=https://evi1-yourapp-login.com/phish

If your redirect logic trusts the callbackUrl value without validating that it actually points somewhere inside your own app, a victim who clicks a link like this, maybe from a phishing email that looks legitimate because the domain in the visible link is genuinely yourapp.com, logs in successfully on your real site, with their real credentials, and then gets silently redirected to an attacker-controlled page immediately afterward. That page can look like anything, a fake "session expired, please log in again" prompt designed to harvest the same credentials a second time, now with the victim's guard completely down because they just successfully authenticated on the real site seconds earlier.

This is specifically dangerous because every part of the actual login happened on your real, legitimate domain. Nothing about the login page itself looked suspicious, because it wasn't, the vulnerability is entirely in what happens after a genuine, successful login.

Why This Is Easy to Miss

Redirect-after-login code gets tested by developers clicking through their own app, which only ever produces callbackUrl values that point to real internal pages, because that's the only way anyone naturally encounters this flow during development. The idea of someone deliberately crafting a malicious external value for this parameter doesn't come up unless security testing specifically targets it, since from a pure functionality standpoint, the feature works perfectly for every normal case anyone would think to try.

The Fix: Validate the Redirect Target Is Actually Internal

// lib/safe-redirect.ts
export function getSafeRedirectUrl(callbackUrl: string | undefined, fallback = '/dashboard'): string {
  if (!callbackUrl) return fallback;

  // Reject anything that isn't a relative path starting with exactly one slash.
  // "//evil.com" and "https://evil.com" both get rejected here,
  // protocol-relative URLs are a classic bypass for a naive check.
  if (!callbackUrl.startsWith('/') || callbackUrl.startsWith('//')) {
    return fallback;
  }

  return callbackUrl;
}

if (result?.ok) {
  redirect(getSafeRedirectUrl(searchParams.callbackUrl));
}

The specific check for a leading // matters more than it looks like it should. A browser interprets //evil.com as a protocol-relative URL, meaning it resolves to https://evil.com using whatever protocol the current page is on, and a naive check that only verifies "does this start with a single slash" can be bypassed entirely by that exact pattern. Rejecting anything that doesn't match a genuine single-slash-prefixed relative path closes this specific gap.

If you're using NextAuth's built-in redirect callback, the same principle applies there directly, NextAuth exposes a redirect callback specifically so you can validate target URLs centrally:

// auth.ts
export const authOptions: NextAuthOptions = {
  callbacks: {
    async redirect({ url, baseUrl }) {
      // Only allow redirects to the same origin as the app itself
      if (url.startsWith(baseUrl)) return url;
      if (url.startsWith('/')) return `${baseUrl}${url}`;
      return baseUrl;
    },
  },
};

The Rule

Any redirect target sourced from user-controllable input, a query parameter, a form field, a referrer header, needs to be validated as pointing somewhere inside your own app before you redirect to it. "It's just a convenience redirect" is exactly the framing that makes this vulnerability easy to introduce without noticing, since the feature's happy path looks completely benign and only the deliberately crafted input reveals the gap.

I validate every redirect target this way in the auth flows across my Next.js dashboard templates, since login and post-auth redirects show up in basically every project and this is a genuinely easy detail to skip under normal development pressure. More on the broader auth patterns I build around at pixelanas.com.

Get the templates: https://pixelanas.gumroad.com

Go check your own login flow for a callbackUrl, returnTo, or next parameter that gets redirected to without validation. If you find one, try crafting a //evil.com style value against it. Drop what you find in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

You Changed a User's Role in the Database, But Their JWT Doesn't Know That Yet

Sat, 10 Oct 2026 13:33:53 +0000

You find out a user's permissions need to change right now, maybe they're being demoted from admin, maybe their account access is being revoked entirely after an incident. You update the database. The change looks instant in your admin panel. Meanwhile, that user keeps acting with their old permissions for as long as their existing session token stays valid, sometimes for hours, sometimes for days, and nothing about your database update touched that.

Why This Happens: JWTs Don't Check Back In

A JWT-based session, the kind most Next.js apps use with something like NextAuth, is a self-contained token. Once it's issued, your server verifies it by checking its signature and expiration, not by looking anything up in your database. That's the entire point of a stateless token, it avoids a database round trip on every single request.

// middleware.ts
export async function middleware(request: NextRequest) {
  const token = await getToken({ req: request });

  // This only checks: is the signature valid, has it expired?
  // It does NOT check: does this role still match what's in the database right now?
  if (token?.role !== 'admin') {
    return NextResponse.redirect(new URL('/unauthorized', request.url));
  }

  return NextResponse.next();
}

The role embedded in that token was correct the moment it was issued. It is not re-verified against the database on every request, because doing so would defeat the entire performance benefit of using a stateless token in the first place. If you update the user's role in the database five minutes after their token was issued, the token itself still says the old role, and will keep saying that until it expires and they're forced to log in again.

Where This Actually Causes Real Problems

For a routine role change, like a title update that doesn't affect sensitive access, a short delay before it takes effect is a minor inconvenience, at worst, mildly confusing. For a security-sensitive revocation, suspending an account after detecting suspicious activity, revoking admin access after an employee departure, removing a compromised API key's associated session, that same delay is a real exposure window. The access you believed you'd just shut off is still fully functional from the attacker's or departed employee's side, for however long their existing token remains valid.

Why This Is Easy to Miss Building the App

Session and role logic almost always gets tested by logging in fresh after making a change, which issues a brand new token with the updated role baked in, making the fix look like it worked perfectly. The actual bug only shows up for a user who's already logged in with an existing token at the moment the change happens, a scenario that's genuinely easy to never think to test, since it requires two separate sessions and specific timing to notice.

The Fix: Force Re-Verification for Anything Sensitive

The cleanest general fix is shortening token lifetime for sensitive roles and pairing it with refresh logic that re-checks the database:

// auth.ts (NextAuth config)
export const authOptions: NextAuthOptions = {
  session: {
    strategy: 'jwt',
    maxAge: 15 * 60, // 15 minutes instead of days, forces more frequent re-issuance
  },
  callbacks: {
    async jwt({ token, user, trigger }) {
      if (trigger === 'update' || !token.lastChecked || Date.now() - (token.lastChecked as number) > 60_000) {
        // Re-fetch the current role from the database periodically,
        // not just at initial login
        const dbUser = await User.findById(token.sub).select('role status');
        if (!dbUser || dbUser.status === 'suspended') {
          return { ...token, role: null, revoked: true };
        }
        token.role = dbUser.role;
        token.lastChecked = Date.now();
      }
      return token;
    },
  },
};

For genuinely urgent revocations, like an active security incident, token expiration alone isn't fast enough, and this is where some form of server-side revocation check becomes necessary, a denylist of revoked token IDs checked against a fast store like Redis, even if you're otherwise fully stateless everywhere else. It adds back a small lookup cost, but only for the specific case where "wait until the token expires naturally" genuinely isn't an acceptable answer.

// A minimal revocation check added to middleware
const isRevoked = await redis.sismember('revoked_sessions', token.jti);
if (isRevoked) {
  return NextResponse.redirect(new URL('/login', request.url));
}

The Rule

A JWT's claims are a snapshot from the moment it was issued, not a live view of your database. Any role or permission check based purely on token contents can be stale for as long as that token remains valid. For routine data, that staleness is usually an acceptable tradeoff for performance. For anything where immediate revocation actually matters, you need either short-lived tokens with periodic re-verification, or an explicit revocation check, because the token itself has no way of knowing anything changed.

I treat this distinction explicitly in the auth setup behind my Next.js dashboard templates, where role-based access control needs to actually mean something the moment it changes, not sometime later.

Get the templates: https://pixelanas.gumroad.com

Check your own app, specifically how fast a role change or account suspension actually takes effect for a user with an existing session. If the honest answer is "whenever their token expires," that's worth deciding on purpose rather than by default. Drop what you find in the comments.

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Fixing Threads API Authorization Code Failures

Sun, 04 Oct 2026 09:03:46 +0000

Integrating the Threads API requires navigating a three-legged OAuth process that can stall at several distinct points. When an application fails to exchange an authorization code for a valid access token, debugging often becomes a frustrating exercise in trial and error. The API returns cryptic numeric codes and generic error messages that rarely point to the root cause of the failure.

The core problem stems from strict validation rules across the authorization code, the application credentials, the redirect URIs, and token families. Understanding why these failures occur helps engineering teams establish a reliable diagnostic process and complete successful token exchanges without burning single-use codes.

The Three-Legged Token Flow

The Threads API uses a standard OAuth three-legged flow to establish user-level access. First, the user visits an authorization URL hosted by the platform, which redirects back to the application with a short-lived authorization code. Second, the backend exchanges this authorization code for a short-lived user access token via a POST request. Third, this short-lived token is exchanged for a sixty-day long-lived token.

Each leg of this journey relies on precise inputs. The authorization code expires within minutes and can only be used once. If any parameter in the subsequent requests deviates from the expected format, the platform rejects the exchange.

The Four Failure Modes

When token exchanges fail, the error typically maps to one of four specific conditions:

Wrong token family (452 Session key invalid): Tokens minted in generic testing surfaces or alternative Meta dashboards belong to a different token family. The Threads endpoint rejects these tokens outright.
Wrong secret of two: Meta frequently issues multiple app ID and secret pairs for a single project. The Threads API requires the specific Threads credential pair, and because both secrets share the same length, visual inspection is unreliable.
Non-identical redirect URI (36008): The redirect URI supplied during the code exchange must match the initial authorization request byte-for-byte, including trailing slashes and parameter encodings.
Stale or consumed codes (36006): Authorization codes are strictly single-use. Retrying a failed request with an old code or keeping multiple browser tabs open will trigger this failure.

The Diagnostic Ladder

To isolate these issues without wasting tokens, follow a strict diagnostic order. Testing items sequentially prevents compounding errors.

First, verify the token family. If a 452 error occurs, check whether the credentials originated from the correct Meta app dashboard configured specifically for Threads rather than general Facebook Login products.

Second, test the secret pairing programmatically. Because visual checks fail on same-length secrets, send a lightweight client credentials grant or inspection call using the suspected secret to confirm authentication success before attempting the user code exchange.

Third, compare redirect URIs at the byte level. Print out the exact string sent in both the authorization redirect and the token exchange POST body. A missing trailing slash or an unencoded character will immediately cause a 36008 error.

Finally, treat authorization codes as perishable singletons. Open a fresh authorization URL, capture the code immediately, and execute the exchange request within seconds.

Code Example for Token Exchange

Executing the token exchange correctly requires sending the proper POST parameters with the right application credentials. Here is an example request using curl:

curl -X POST "https://graph.threads.net/oauth/access_token" \
  -F "client_id=YOUR_THREADS_CLIENT_ID" \
  -F "client_secret=YOUR_THREADS_CLIENT_SECRET" \
  -F "grant_type=authorization_code" \
  -F "redirect_uri=https://example.com/callback" \
  -F "code=AQD_SAMPLE_AUTHORIZATION_CODE"

If successful, the endpoint returns a JSON payload containing the short-lived access token and the user ID. Immediately pass this token to the long-lived token endpoint to secure a sixty-day session.

After the Token Lands

Once the sixty-day token is successfully retrieved, verify its permissions by calling a read-scoped endpoint before storing it. Store the final token securely in platform secret storage or a key-value store with strict rotation policies. Never commit secrets to version control or leave them exposed in local configuration files. For a related implementation, see Secrets Local Config Ci.

Conclusion

Navigating the Threads API authentication flow depends on precise adherence to credential pairings, token families, and byte-level URI matching. By following a structured diagnostic approach and treating authorization codes as perishable singletons, developers can eliminate invalid-code failures and build resilient social integrations. For a related implementation, see Site Wide Structured Data Social Graph.

From Broken Google OAuth to a Stable Sepolia E2E Environment: Engineering MyZubster on a VPS

Sun, 27 Sep 2026 00:54:50 +0000

From Broken Google OAuth to a Stable Sepolia E2E Environment: Engineering MyZubster on a VPS

Over the last development cycle, we worked on stabilizing the MyZubster Sepolia environment and turning what was initially a collection of partially working services into a much more predictable end-to-end infrastructure.

The work involved several layers of the stack:

Node.js / Express backend
Google OAuth 2.0
React frontend
Ethereum Sepolia testing
MongoDB
PM2 process management
Cloudflare tunneling
VPS deployment
Environment configuration
Urban Lab / I-ECO-01 services
Git branch and deployment management

This article documents what we fixed, how we diagnosed the problems, what is working now, and what still needs to be completed.

1. The Starting Point

The Sepolia environment was running on a VPS with several services managed by PM2.

The main components included:

MyZubster Sepolia backend
MyZubster Sepolia frontend
MyZubster Social
MyZubster Web
Urban Lab / I-ECO-01
Cloudflared

The environment was operational, but two important areas were unstable.

The first was Google authentication.

Users could start the OAuth flow and Google returned the authorization callback, but the backend failed during the authorization-code exchange.

The second problem was the Urban Lab service.

It was trapped in a PM2 restart loop, generating millions of restarts because runtime dependencies required by server.js were missing.

We debugged these independently instead of treating the VPS as a single black box.

2. Debugging Google OAuth

The original application error was generic:

Login Google non riuscito

That message was not enough to identify whether the problem was caused by:

the authorization code,
OAuth state,
callback URI,
client ID,
client secret,
Google configuration,
proxy forwarding,
or application logic.

We therefore instrumented the token exchange temporarily.

The relevant backend flow exchanges the authorization code against Google's token endpoint and then retrieves the verified Google user profile.

The diagnostic logging revealed the actual failure:

status: 401
error: invalid_client
description: The provided client secret is invalid.

This immediately changed the investigation.

The callback itself was reaching the backend correctly.

The OAuth state existed.

The authorization code existed.

The problem was the credentials used during the token exchange.

3. Validating the Runtime Environment

One of the important lessons from this debugging session was that validating .env alone is not sufficient.

We checked both the configuration file and the running PM2 process.

The Google client configuration was inspected without printing the complete secret.

We verified properties such as:

CLIENT ID
SECRET PRESENT
SECRET LENGTH
SECRET FORMAT
CALLBACK URL

The configured callback was:

https://sepolia.myzubster.com/api/auth/social/google/callback

We then discovered that the previously configured secret was not a valid secret for the OAuth client being used.

After replacing it with the correct Google OAuth client secret, the token exchange started succeeding.

4. Google OAuth Successfully Completed

After correcting the OAuth credentials, the backend began reporting successful callbacks.

The flow became:

Browser
   |
   v
Google Authorization
   |
   v
/api/auth/social/google/callback
   |
   v
Authorization Code Exchange
   |
   v
Google Access Token
   |
   v
Google UserInfo
   |
   v
MyZubster account verification
   |
   v
Social login ticket
   |
   v
Frontend

The backend successfully received callbacks containing both the authorization code and OAuth state.

Most importantly, the previous invalid_client token error disappeared.

The public provider endpoint also confirmed:

{
  "success": true,
  "data": {
    "providers": {
      "google": true,
      "github": false,
      "facebook": false
    }
  }
}

Google authentication is therefore enabled in the Sepolia environment.

5. Fixing the OAuth Redirect

Authentication succeeding at Google was only part of the problem.

The backend was still redirecting successful logins to an old Vercel deployment.

The runtime destination was effectively:

old Vercel deployment

instead of:

https://sepolia.myzubster.com

We corrected the runtime environment so the relevant public URLs resolve to the Sepolia deployment.

The running PM2 process was verified with:

FRONTEND_URL=https://sepolia.myzubster.com
GATEWAY_PUBLIC_URL=https://sepolia.myzubster.com
PUBLIC_APP_URL=https://sepolia.myzubster.com

This was an important distinction.

Updating .env is not necessarily equivalent to updating the environment of an already running process.

For production-style deployments, the effective runtime configuration must always be verified.

6. Testing the Complete OAuth Path

We then tested the complete flow again.

The callback reached the backend with:

hasCode: true
hasState: true
hasError: false

The Google token exchange completed successfully.

No new Google token error appeared.

The backend remained online.

The provider endpoint remained available.

The PM2 process PID remained stable.

This gave us evidence that the fix was not simply masking an application crash.

7. Removing Temporary Debug Instrumentation

Temporary instrumentation is useful during incident analysis, but it should not become permanent application noise.

After confirming the OAuth path, we removed the temporary HTTP callback logger.

We retained useful error-level logging around OAuth failures:

console.error('[OAUTH-CALLBACK-ERROR]', {
  provider,
  message: String(error?.message || error)
});

This provides enough information for future troubleshooting without logging authorization codes, OAuth state values, access tokens, or secrets.

That distinction matters.

Authentication debugging must provide observability without accidentally creating a credential-leak mechanism.

8. Stabilizing Urban Lab / I-ECO-01

At the same time, another service on the VPS had a completely different problem.

The urbanlab PM2 process had accumulated an extremely large restart count.

Inspection of the error log showed:

Error: Cannot find module 'helmet'

The server required:

require('dotenv').config();
const express = require('express');
const cors = require('cors');
const helmet = require('helmet');
const mongoose = require('mongoose');
const { createServer } = require('http');
const { Server } = require('socket.io');
const winston = require('winston');

But package.json originally contained only:

cors
dotenv
express
mongoose

The runtime therefore expected modules that the project did not declare/install.

We added the missing dependencies:

helmet
socket.io
winston

After installation, each required module could be resolved successfully.

9. Stopping a Multi-Million-Restart PM2 Loop

Once the missing dependencies were installed, Urban Lab started normally.

The server reported:

Server started on port 5002
MongoDB connected

Its health endpoint returned:

{
  "status": "ok",
  "service": "I-ECO-01",
  "mongodb": "connected"
}

We then compared the PM2 process before and after a waiting period.

The PID remained unchanged.

The restart counter remained unchanged.

That confirmed that the restart loop had actually stopped.

This is much more meaningful than simply seeing:

status: online

for a few seconds.

A process can repeatedly appear online while constantly crashing and restarting.

Process stability needs to be measured over time.

10. Current VPS Architecture

The resulting environment now looks approximately like this:

                    Internet
                       |
                       v
                Cloudflare Tunnel
                       |
                       v
            sepolia.myzubster.com
                       |
          +------------+------------+
          |                         |
          v                         v
     React Frontend            Express Backend
                                   |
                    +--------------+--------------+
                    |              |              |
                    v              v              v
                 MongoDB       Google OAuth   Sepolia EVM
                    |
                    v
              Application Data

Additional VPS services:

PM2
 |
 +-- MyZubster Sepolia Backend
 +-- MyZubster Sepolia Frontend
 +-- MyZubster Social
 +-- MyZubster Web
 +-- Urban Lab / I-ECO-01
 +-- Cloudflared

PM2 is configured under systemd, and the active process list has been saved using:

pm2 save

This means the current process configuration can be restored after a reboot through the existing PM2 startup integration.

11. Git Hygiene

Another important part of the work was separating debugging artifacts from actual source changes.

During debugging we created several temporary backups.

Before committing, those files were removed from the working tree.

We also explicitly verified that .env remained ignored.

The final source change was isolated and committed as:

fix(auth): improve OAuth callback error logging

The resulting commit was:

02f06f22

The working tree was clean after the commit.

The branch:

vps/sepolia-e2e-test

was then pushed to the remote repository.

This gives us a reproducible Git checkpoint corresponding to the working VPS state without committing the environment secrets.

12. Security Considerations

One of the most important lessons from this work concerns secrets.

OAuth client secrets, API keys, database credentials, private keys, GitHub tokens, JWT signing secrets, and similar credentials should never be committed to Git.

The repository correctly ignores .env.

But .gitignore is only one layer of protection.

The longer-term architecture should move production credentials toward dedicated secret management and controlled deployment-time injection.

We also deliberately avoided logging:

Google client secret
OAuth authorization code
OAuth state
access tokens
JWTs
database passwords
private keys

Observability and secret exposure must remain separate concerns.

13. What Is Working Now

At this stage we have achieved several concrete milestones.

Google OAuth can complete the server-side authorization-code flow.

The Sepolia backend exposes Google as an enabled authentication provider.

The callback is routed through the public Sepolia infrastructure.

The application runtime is using the intended Sepolia frontend/public URLs.

PM2 is running the MyZubster services.

PM2 configuration has been persisted.

Urban Lab / I-ECO-01 is no longer trapped in its missing-module restart loop.

Its MongoDB connection is operational.

The I-ECO-01 health endpoint responds successfully.

The OAuth debugging changes have been cleaned up.

The relevant source change has been committed and pushed to a dedicated branch.

14. What Still Needs to Be Done

A working OAuth callback does not mean the entire platform is production-ready.

Several areas still need engineering work.

Authentication hardening

The OAuth implementation should receive additional automated tests covering:

invalid state
expired state
missing code
provider errors
invalid client configuration
token endpoint failures
userinfo failures
unverified email
expired social-login tickets
replay attempts

GitHub and Facebook providers are currently disabled according to the provider endpoint and can be implemented or enabled separately when their configuration is ready.

Deployment reproducibility

The VPS currently represents an important working environment.

The next goal should be making that environment reproducible from source and configuration rather than depending on manual server history.

That means documenting and eventually automating:

dependency installation
environment injection
PM2 configuration
Cloudflare configuration
frontend startup
backend startup
health checks
rollback

Monitoring

A process being online is not sufficient operational monitoring.

We want visibility into:

restart rate
HTTP error rate
OAuth failure rate
MongoDB availability
response latency
memory consumption
CPU consumption
Sepolia RPC failures
WebSocket availability

Secret management

Production credentials should eventually be rotated and managed through a dedicated secret-management workflow.

CI/CD

The current branch and commit structure gives us a good foundation for moving toward automated deployment.

The desired flow is:

Developer
   |
   v
Git branch
   |
   v
Pull Request
   |
   v
Automated Tests
   |
   v
Security Checks
   |
   v
Merge
   |
   v
Sepolia Deployment
   |
   v
Health Checks
   |
   v
Production Promotion

15. Where We Want to Go

The objective is larger than simply making Google login work.

The Sepolia environment is becoming the integration layer where we can validate the interaction between identity, application state, Web3 payments, AI services, Urban Lab infrastructure, and MyZubster's broader ecosystem.

The architecture we are moving toward is approximately:

                         MyZubster
                             |
        +--------------------+--------------------+
        |                    |                    |
        v                    v                    v
     Identity             Web3 Layer          AI Layer
        |                    |                    |
   Google OAuth          Ethereum           AI Services
   GitHub OAuth          Sepolia            Zorgax / Pytho
   Social Identity       Wallets            Automation
        |                    |                    |
        +--------------------+--------------------+
                             |
                             v
                        Core Backend
                             |
             +---------------+---------------+
             |                               |
             v                               v
          MongoDB                       Urban Lab
                                            |
                                  +---------+---------+
                                  |                   |
                                  v                   v
                              IoT / GPS        Environmental Data

The Sepolia environment gives us a place to integrate these components without treating production as the testing environment.

16. Engineering Lessons

Several lessons from this debugging cycle are worth keeping.

Inspect the real provider response

Login failed tells you almost nothing.

401 invalid_client
The provided client secret is invalid

tells you exactly where to investigate.

`.env` is not necessarily the runtime environment

Always inspect what the actual process sees.

This becomes especially important with PM2, containers, systemd, CI/CD, and cloud deployment systems.

`online` does not necessarily mean healthy

Urban Lab demonstrated this clearly.

A service may be repeatedly restarted while PM2 continues reporting it as online between crashes.

PID stability, restart counters, health checks, and logs provide a much better picture.

Debug instrumentation should be temporary

Add enough instrumentation to understand the failure.

Verify the fix.

Then remove unnecessary diagnostic logging while retaining safe operational error reporting.

Infrastructure fixes should end in Git

A VPS fix that exists only in shell history is technical debt.

Once the behavior is verified, the corresponding source changes should be cleaned, reviewed, committed, and pushed.

Conclusion

What began as a Google login failure exposed several deeper infrastructure issues.

We traced the OAuth flow to the actual Google token exchange, identified an invalid client secret, corrected the runtime configuration, fixed the frontend redirect destination, validated the public callback path, cleaned the debugging instrumentation, stabilized a separate Urban Lab service that had entered a massive PM2 restart loop, verified MongoDB connectivity, persisted the PM2 process state, cleaned the Git working tree, committed the relevant OAuth changes, and pushed the working branch.

The important outcome is not simply:

“Google login works.”

The more important outcome is that the Sepolia environment is becoming observable, reproducible, testable, and suitable for real end-to-end integration work.

The next phase is to convert these manually validated infrastructure improvements into automated tests, deployment pipelines, monitoring, stronger secret management, and repeatable environment provisioning.

That is the path from a working development VPS to a maintainable engineering platform.

🔐 Understanding SAML, OAuth 2.0 and OpenID Connect

Fri, 25 Sep 2026 16:02:35 +0000

🔎 What Are These Protocols?

SAML 2.0 (Security Assertion Markup Language)

SAML is an authentication and authorization protocol primarily used for Single Sign-On (SSO) in enterprises. It enables users to log in once and access multiple applications without entering credentials again.

✔ Used For: Enterprise authentication (e.g., logging into Google Workspace, Salesforce, etc.)
✔ How It Works: Uses XML-based security assertions to exchange authentication and authorization data.
✔ Downside: Verbose XML format, and not actively developed anymore.

OAuth 2.0 (Open Authorization)

OAuth 2.0 is an authorization protocol designed to grant limited access to resources without exposing user credentials. It’s commonly used for API access and delegated permissions.

✔ Used For: Third-party API authorization (e.g., "Allow this app to access your Google Drive")
✔ How It Works: Uses access tokens to grant specific permissions.
✔ Downside: It doesn’t authenticate users—it just authorizes actions.

OpenID Connect (OIDC)

OIDC is an authentication protocol built on top of OAuth 2.0. It adds ID Tokens to OAuth, allowing applications to verify a user's identity in a secure, standardized way.

✔ Used For: Modern authentication (e.g., "Sign in with Google")
✔ How It Works: Extends OAuth 2.0 by providing identity tokens (JWTs) to verify users.
✔ Why It’s Popular: Lightweight, JSON-based, and designed for modern web and mobile apps.

At this point, you might be thinking:

"Okay, I just read these definitions, but things still seem a bit confusing."

"Don’t worry—I felt the same when I first tried to understand them! So, let me break it down in the simplest way possible."

Before we jump into the story-based explanation, let’s first understand two key terms that will make everything clearer:

✔ Identity Provider (IdP):

The system that authenticates users and confirms their identity.

Example: Google, Okta, Microsoft Entra ID (Azure AD).

✔ Service Provider (SP):

The application or website that users want to access after authentication.

Example: Gmail, Slack, Salesforce.

💡 Think of it this way:

The IdP is like a security guard checking your ID before letting you in.

The SP is the building or service you’re trying to enter.

🔍 Let’s Understand This with a Story

Imagine a big amusement park 🎡 where visitors need special passes to access different rides.

In this park:
🎟 A Ticket (Token) = Proof of Access
🏛 The Ticket Counter (Identity Provider) = Authenticates visitors
🎢 The Ride (Service Provider) = Grants access based on the ticket

This analogy will help you understand how authentication and authorization work in each protocol.

1️⃣ SAML 2.0 – The VIP Pass for Employees

📖 Story: The Corporate Park & Employee Pass

Imagine one company that owns a huge amusement park. Employees don’t buy separate tickets for every ride—they get a VIP Employee Badge 🎫 from the HR office.

How It Works (SAML Flow):

1️⃣ 🏛 HR Office = Identity Provider (IdP)

Employees check in at the HR office (login page).

The HR office verifies who they are and issues a VIP badge (SAML token).

2️⃣ 🎢 Amusement Park Rides = Service Providers (SP)

The employee shows the badge at any ride’s entrance.

The ride operator trusts the badge (without asking for a password).

The employee gets access to the ride (authorization).

Key Takeaways:
✅ SSO (Single Sign-On): Employees log in once and access multiple rides.
✅ Authentication + Authorization: The badge confirms who you are and grants access to specific rides.
✅ Enterprise Use: Best for corporate authentication, but not ideal for modern mobile/web apps.
✅ Legacy & Declining Use: SAML is no longer actively developed, and many modern applications are shifting towards OpenID Connect (OIDC).

📌 Example Use Case:

A company uses SAML-based SSO so employees can log in once and access tools like Google Workspace, Salesforce, and Slack without re-entering credentials.

2️⃣ OAuth 2.0 – Borrowing a Friend’s Car (Authorization, Not Authentication)

📖 Story: The Car Rental & Borrowing Keys

Imagine you need a rental car 🚗 (access to an app), but instead of getting a car yourself, you ask your friend to get it for you.

How It Works (OAuth Flow):

1️⃣ 🧍♂️ User (You) asks your Friend (Client App) to get a Car (Protected Resource).

You don’t have direct access to the rental car system.

Instead, you give your friend (third-party app) permission to get a car for you.

2️⃣ 🏛 Rental Agency (Authorization Server) issues a Car Key (Access Token).

The agency checks if your friend is authorized.

They issue a temporary key (OAuth token) that allows your friend to drive the car.

3️⃣ 🚗 Using the Car (Accessing Resources).

Your friend shows the car key and gets the car without needing your ID.

They can’t modify the rental agreement—just drive the car based on the given permission.

Key Takeaways:
✅ Authorization, Not Authentication: The car key doesn’t prove who you are, it just lets someone use a resource.
✅ Token-Based: If someone steals the key, they can use the car, even if they aren’t you (Bearer Token Risk).
✅ Used for API Access: Perfect for granting limited access to apps (e.g., "Allow this app to access your Google Drive").

🚨 Key Misconception:

OAuth ≠ Authentication. It’s about authorization (permissions), not logging in.

3️⃣ OpenID Connect (OIDC) – VIP Pass with Your Photo (Authentication + Authorization)

📖 Story: The All-Access Digital ID

Now, imagine a more modern amusement park where you can:
✔ Use a digital ID 📱 instead of a paper ticket.
✔ Your ID has your photo to prove who you are (Authentication).
✔ Your ID also includes ride permissions (Authorization).

How It Works (OIDC Flow):

1️⃣ 🏛 Ticket Booth (Identity Provider) issues an ID with your photo.

The booth verifies your identity and gives you a digital ID (ID Token) with your photo and details.

2️⃣ 🎢 Amusement Park Scanners (Apps & APIs) accept the ID.

When you go to a ride, you scan your digital ID.

The system verifies your photo (Authentication) and checks ride access (Authorization).

Key Takeaways:
✅ Authentication + Authorization: OIDC proves who you are (ID Token) + controls what you can do (Access Token).
✅ Modern & Lightweight: Uses JSON instead of XML (simpler than SAML).
✅ Best for Web & Mobile Apps: Google, Facebook, and Microsoft use OIDC for "Sign in with Google/Facebook" logins.
✅ Replacing SAML: Many modern applications are shifting from SAML to OIDC for better support in web & mobile apps.

🤔 When to Use Which Protocol?

Use Case	Best Choice	Why?
Enterprise SSO (Internal Apps)	SAML	Secure, well-established in enterprises
Third-party API Access	OAuth 2.0	Grants limited access without credentials
Social Login & Modern Web Apps	OIDC	Lightweight, authentication + authorization

🎯 Final Thoughts

Understanding SAML, OAuth and OIDC is crucial for securing applications. These protocols ensure users and apps interact securely without sharing sensitive credentials.

You might have noticed that SAML and OIDC seem similar—both handle authentication and enable Single Sign-On (SSO). However, the key difference is how they work:

✔ SAML: Uses XML, is enterprise-focused, and is mainly for web-based applications.
✔ OIDC: Uses JSON, is lightweight, and works well for modern web and mobile apps.

While SAML is older and widely used in enterprises, OIDC is the future—it’s more flexible and designed for modern applications.

🚀 If your system already uses SAML, you might stick with it. But if you're building something new, OIDC is likely the better choice!

💬 Which protocol have you worked with the most? Let’s discuss in the comments! 🚀

Building a Human-in-the-Loop GitHub Profile Automation with MyZubster and Zorgax

Thu, 24 Sep 2026 14:25:14 +0000

thorization with the user.

Result

The full GitHub profile automation loop is now working:

MyZubster
→ Zorgax
→ GitHub analysis
→ generated README
→ final preview
→ explicit human approval
→ authenticated GitHub write
→ public commit

It took more than generating Markdown.

The difficult parts were identity, OAuth, state handoff, parsing, permission boundaries and making the final action auditable.

And those are exactly the parts that make AI automation interesting to build.

Project: MyZubster
AI assistant: Zorgax
Main repository: MyZubster-Ecosystem/myzubster
Test profile: @myzubster

Looking for 3 Beta Testers – HubSpot OAuth Installation Flow (Marketplace Submission)

Sat, 25 Jul 2026 16:46:05 +0000

We're preparing our HubSpot app for Marketplace submission and are looking for 3 developers or HubSpot users to help validate our OAuth installation flow.

The goal is to ensure a smooth, secure, and reliable installation experience before the app goes through Marketplace review.

What we're testing

✅ HubSpot OAuth 2.0 authorization
✅ Secure account connection
✅ Token synchronization
✅ Installation experience
✅ Overall usability

Who can help?

HubSpot users
SaaS founders
CRM developers
API developers
Automation builders

Installation takes about a minute. If you encounter any issues or have suggestions for improving the user experience, I'd genuinely appreciate your feedback.

The installation link is available in the first comment.

Thank you for helping improve the integration before Marketplace submission.

SAML vs OIDC vs OAuth 2.0: 12 Differences Every B2B Engineering Team Should Know

Tue, 21 Jul 2026 08:03:43 +0000

Quick answer is OAuth 2.0 is an authorization framework (delegated access to resources). OIDC is an authentication layer built on top of OAuth 2.0 (modern identity for web, mobile, and SPAs). SAML 2.0 is a separate, XML-based enterprise SSO standard from 2005. They are not competitors — a production B2B SaaS will end up supporting all three. This article breaks down the 12 technical differences that actually matter when you are shipping enterprise-ready auth, plus a decision matrix and migration path. If you want to skip the 18-month build, SSOJet is a protocol-agnostic broker that handles all three behind a single API.

Most "SAML vs OIDC vs OAuth" explainers treat the three as interchangeable login protocols. They are not. They were designed in different decades, by different standards bodies, to solve different problems — and the differences show up in very real ways once you have paying enterprise customers.

This is the engineer's guide- 12 dimensions, one decision matrix, one migration playbook, and an honest take on when to build versus buy.

The 30-Second Mental Model

Before the deep dive, lock in the mnemonic that makes these protocols stop blurring together:

OAuth 2.0 = AuthZ. A valet key that lets one app access resources in another app, on behalf of a user, without sharing the password.
OIDC = AuthN on top of OAuth. Adds a signed ID Token (JWT) so the app knows who the user is.
SAML 2.0 = AuthN for enterprises. XML-based, browser-driven, older, and the lingua franca of corporate IT.

AuthN = who you are. SAML and OIDC do this. AuthZ = what you can do. OAuth 2.0 does this.

Every other difference in this article is a consequence of those three design goals.

Protocol Snapshot Table

Dimension	SAML 2.0	OIDC	OAuth 2.0
Primary purpose	Enterprise SSO & federation	User authentication	Delegated authorization
Standards body	OASIS	OpenID Foundation	IETF (RFC 6749)
Year standardized	2005	2014	2012
Token format	XML assertion	JWT (ID Token)	Opaque or JWT
Cryptography	XML-DSig / XML-Enc	JOSE (JWS / JWE)	JOSE when JWTs used
Transport	Browser redirects	REST + JSON	REST + JSON
Mobile / native fit	Poor	Excellent	Excellent
Discovery	Static XML metadata	`/.well-known/openid-configuration` + JWKS	Via OIDC discovery
Logout	Single Logout (SLO) spec	Front/back-channel logout	Token revocation only
Provisioning	Usually paired with SCIM	Usually paired with SCIM	N/A
Recommended flow (2026)	Web Browser SSO Profile	Auth Code + PKCE	Auth Code + PKCE / Client Credentials
Best for	Regulated enterprise SSO	Modern web / mobile auth	API authorization

Now let's unpack the 12 differences that actually drive architecture decisions.

Difference #1: Protocol Origins and Design Goals

Each protocol was built to solve a different problem in a different era. Forgetting that is the single biggest source of confusion.

SAML 2.0 was ratified by OASIS in March 2005, consolidating earlier work from Shibboleth and the Liberty Alliance. The design goal is a metadata-driven, browser-based federation protocol for enterprises that needed to bridge on-prem Active Directory with external web apps. SAML assumes a pre-established trust relationship between two organizations — IT admins exchange signed XML metadata files, not API keys.

OAuth 2.0 was published as RFC 6749 by the IETF in October 2012. Its goal was never authentication. It answers is "How does App A let User U grant App B permission to access their data in App A, without App B ever seeing User U's password?" Think "Sign in with Google to let Calendly read your calendar." That delegation pattern is OAuth's entire reason for existing.

OpenID Connect (OIDC) launched on February 26, 2014, published by the OpenID Foundation. Developers had been misusing OAuth 2.0 for login (because it was easier than SAML) — and doing it badly, insecurely. OIDC standardized the pattern by adding a signed ID Token on top of OAuth 2.0, plus a userinfo endpoint and standardized scopes like openid, profile, email.

Why this matters: you cannot "pick between" SAML and OAuth. They do different things. The actual choice is SAML vs OIDC for authentication, and OAuth vs nothing for API authorization.

Difference #2: Token Format — XML Assertions vs JWTs

This is the most visible, day-to-day difference for engineers.

A SAML assertion is a signed XML document, typically 2–8 KB (sometimes much larger with attribute statements and embedded certificates). Signing uses XML-DSig, encryption uses XML-Enc. If you have ever debugged XML canonicalization mismatches at 2 AM, you know why SAML has a reputation for brittleness.

An OIDC ID Token is a JWT — Base64URL-encoded JSON, typically a few hundred bytes to 1 KB, signed via JWS using the JOSE framework. Paste one into jwt decoder and it's human-readable.

OAuth 2.0 access tokens can be either opaque strings (validated by introspection) or JWTs (validated locally). Modern deployments favor JWTs for performance.

	SAML assertion	JWT (OIDC / OAuth)
Size	2–8 KB typical	~300 bytes – 1 KB
Format	XML	JSON
Parsing	XML parser + canonicalization	Base64 decode + JSON parse
Inspectable	Painful	One click at jwt decoder
Passable in header	No (too large)	Yes (`Authorization: Bearer`)
Mobile / SPA friendly	No	Yes

Why this matters: at scale, the CPU cost of parsing and canonicalizing XML adds real infrastructure bills. More importantly, the SAML attack surface (XML Signature Wrapping, XSLT injection, entity expansion) is deeper and scarier than the JWT attack surface — though both require care.

Difference #3: Transport Assumptions — Browser vs REST

SAML was designed for the browser. The three bindings you will see in practice are:

HTTP-Redirect — small requests passed via URL query string (typically the AuthnRequest).
HTTP-POST — large responses (the actual assertion) passed via an auto-submitting HTML form.
HTTP-Artifact — an opaque reference the SP redeems via back-channel SOAP.

Every SAML SSO flow routes through the user's browser as the message courier.

OIDC and OAuth 2.0 assume REST + JSON over HTTPS. The recommended flow in 2026 for every client type — web apps, SPAs, mobile, desktop, CLIs — is Authorization Code with PKCE (RFC 7636). For machine-to-machine, OAuth 2.0 offers the Client Credentials grant, which has no SAML equivalent.

The practical consequence: if your product has a mobile app, a CLI, or any non-browser client, SAML alone is insufficient. This is why OIDC is "mobile-native" and SAML is not.

Difference #4: Discovery and Metadata Management

This is where SAML deployments quietly age badly.

SAML discovery is static. Each entity publishes an EntityDescriptor XML file listing its endpoints (SingleSignOnService, AssertionConsumerService, etc.), supported bindings, and — critically — X.509 certificates embedded inside <KeyDescriptor> elements. This metadata is exchanged manually (often via email) or hosted at a stable URL the partner polls.

Certificate rotation is where SAML breaks. When a signing cert is about to expire, you must publish the new cert inside the metadata alongside the old one during an overlap window, and every downstream SP must refresh their cached copy. Miss that, and half your enterprise tenants lose SSO on the same Monday morning.

OIDC discovery is dynamic. Providers publish a /.well-known/openid-configuration JSON document, and inside is a jwks_uri that points to a live JWKS (JSON Web Key Set) endpoint. Keys rotate by publishing a new key with a new kid. Clients pick it up on the next token validation automatically. No emails. No coordination.

For the full operational playbook on this topic, see our deep dive on enterprise federation and SAML metadata management.

Difference #5: Enterprise vs Consumer Fit

There is a reason regulated enterprises still demand SAML in 2026. It is not nostalgia — it is procurement and compliance.

SAML's strengths in enterprise:

20+ years of deployment inside ADFS, Ping, Shibboleth, Entra ID, Okta.
Embedded in federation networks like InCommon and eduGAIN.
Audited into FedRAMP, HIPAA, PCI-DSS, and banking sector compliance frameworks.
Rich attribute exchange — roles, groups, department, employee ID — all in a single assertion.

OIDC's strengths in modern environments:

Dominates CIAM (Customer Identity and Access Management).
Native to every modern IdP -Entra ID, Google Workspace, Okta, Auth0.
First-class SPA, mobile, and API support.
Developer-friendly SDKs in every major language.

The B2B SaaS reality: if you are selling up-market, you will ship both. Mid-market customers will happily take OIDC. Enterprise customers will hand you a SAML metadata XML file on day one of procurement. This is the pattern our SSO protocol primer: SAML, OIDC and OAuth explained walks through in detail.

Difference #6: Session Management and Logout

If there's one feature that "works on the slide deck but breaks in production," it's Single Logout.

SAML has a formal Single Logout (SLO) spec. Each assertion carries a SessionIndex, and logout flows through either:

Front-channel SLO — IdP redirects the user's browser through every SP's logout URL sequentially. Breaks the moment the user closes a tab, hits a popup blocker, or loses connectivity.
Back-channel SLO — IdP makes SOAP calls directly to each SP. More reliable, but requires network reachability that enterprise firewalls rarely grant.

The SAML spec itself acknowledges "partial logout" as a valid outcome. That is the protocol telling you this is hard.

OIDC defines three logout modes:

RP-Initiated Logout — relying party redirects to the IdP's end_session_endpoint.
Front-Channel Logout — IdP loads iframes for each connected client.
Back-Channel Logout — IdP sends signed logout tokens (JWTs) directly to each client.

None of these are bulletproof either, but they use modern transports and produce debuggable failures.

OAuth 2.0 has no logout concept at all — only token revocation (RFC 7009). This is by design; OAuth is about access tokens, not sessions.

Honest advice: do not promise customers "one-click log out of everything everywhere." Implement

Access vs Refresh Tokens: I Was Missing Two Ideas

Wed, 15 Jul 2026 12:11:13 +0000

Years ago I was building a login API, and a colleague looked at what I was returning and asked why I only had one token. He said the newer APIs hand back two, an access token and a refresh token. Mine returned one. So I asked him the obvious thing: why two? What does the second one buy you?

He didn't really know either. He was a front-end dev, and he'd only ever seen the two tokens come back from the backend on a project he'd worked on. When he asked the person who built that side why there were two, all he got was "it's industry standard." That was the whole explanation. So he was passing that straight down to me: two tokens, that's just how it's done. He said he'd dig into the real reason and get back to me. Two developers standing there, and the actual why had already gone missing one hop up the chain, buried under "it's industry standard."

So I did what a confused junior does when the fancy version doesn't make sense. I called it overhead and shipped the simple one. One token, a JWT, and because I didn't want to think about expiry I gave it a life of something like seven years. No revocation. Once it was signed and handed out, it was valid until roughly the next World Cup, and there was nothing I could do to kill it. The only reason that never blew up in my face is that the project never went to production. I didn't get smart, I got lucky.

Why two tokens made no sense to me

The thing worth being honest about is exactly why I thought it was dumb, because the wrong mental model is the interesting part, not the right one.

First, I thought the refresh token was just a longer-lived copy of the access token. Same thing, one lives longer. If they're the same thing, why carry two? Just use the long one.

Then my colleague came back with the first real clue: the refresh token lives longer, and it's used rarely, only the access token gets sent on every request, so there's less chance of the refresh one getting stolen. And I remember pushing back on that, because "less chance of being stolen" sounded like a hand-wave. There's still a chance. If it can be stolen at all, and it's the long-lived one, then leaking it is worse, not better. That didn't sound like security, it sounded like hoping.

And underneath both of those was a bigger assumption I didn't even know I was making: tokens are stateless. That's the whole selling point, right, the server doesn't store them, it just checks the signature. So the idea of revoking one made no sense to me. You can't reach out and kill a stateless token, there's nothing to kill. And if you did want that, we already have sessions for exactly that job, so why reinvent it worse.

I also had never heard of scopes. It genuinely never occurred to me that a token could be restricted to one specific job. In my head a token meant "this is me, let me do things," full stop. So when I stacked all of that up, two tokens looked like ceremony. Two things that do the same job, one just lives longer, neither one killable, for a benefit I couldn't measure.

The two ideas I was actually missing

None of this resolved quickly. For months after that conversation we just kept shipping the single-token approach, because it worked and we didn't know any better. We were a handful of junior devs with nobody above us to ask. We knew JWT was the standard tool for auth, so we used it the way we understood it, one token, and moved on. The question just sat there, unanswered, for months.

It didn't click on the job. It clicked on YouTube, which is where I go when a thing refuses to make sense and I want to hear someone who actually gets it explain it.

Two concepts landed in the same video and the whole thing fell over at once.

The first was revocation. A token doesn't have to be a fire-and-forget thing you can never call back. If you store it, you can keep a list of the ones you've killed and refuse them. I'd been treating "stateless" as a law instead of a choice, and the moment it's a choice, killing a leaked token is just something you get to decide.

The second was scopes. A token can be restricted to certain actions and nothing else. So the two tokens weren't two copies of the same authority after all. They could have different powers on purpose.

Once I had those two pieces I ran every scenario in my head and it all just resolved, and honestly I started laughing at myself, because it was so easy. This was the same access-and-refresh split I'd bounced off when I first went reading about auth, back when none of the articles made sense. Nothing had changed. I'd just been missing two words. I went to my computer and built a small login, signup, and refresh flow as a demo, and I understood the entire thing end to end in under an hour.

So what are the two tokens actually for

Here's the version I wish someone had handed me at the start.

The access token is the one you send on every single request. Because it's everywhere, all the time, in headers, in logs if you're careless, on every hop, it's the one most likely to leak. So you make it cheap to lose. You give it a short life, minutes to an hour, and you scope it to just what it needs. It's a stateless JWT, so the server never looks it up, it just checks the signature and trusts it until it expires. That's what keeps it fast, and it's also why you don't try to kill an access token individually: you can't, so you lean on the short life instead. If a copy leaks, the damage is small and it ages out on its own fast.

The refresh token has exactly one job: get a new access token. That's it. It can't read your data, it can't hit your endpoints, it does one thing. And here's the part I'd had backwards: the refresh token usually isn't a JWT at all. It's an opaque random string, a row in your database, and that's on purpose, because a row is a thing you can delete. That's what makes it revocable. It also only ever travels to one place, the single refresh endpoint, never your other routes, so its exposure is a sliver of what the access token's is. You send it rarely, only when the access token is about to run out, so there are fewer chances to leak it in the first place, and the moment you suspect it, you delete the row and it's dead on the next use.

That finally answers the thing past-me couldn't get over: yes, the long-lived one can still be stolen, but it only works against that one refresh route, it's useless anywhere else, and it dies the instant you kill the row. The long life stops being scary once the thing is killable and can barely go anywhere.

Where you keep it matters as much as any of this. The refresh token lives in a cryptographically signed, httpOnly cookie, which the browser will hand back only to your server and which JavaScript on the page can't read. What you never do is drop it in localStorage. Anything running on your page can read localStorage, and on a modern app that's a pile of npm packages you didn't write. One compromised dependency reads your token straight out of storage and walks off with it, and you won't get so much as a log line. A signed cookie closes that door.

That's the piece I'd been missing. The refresh token is not a longer copy of the access token. It has a job the access token can't safely do. It keeps you logged in without making you re-type your password every hour, and it does that while staying killable. Short-lived thing you use constantly, long-lived thing you use almost never and can revoke on demand. Two different jobs, so two different tokens.

And that split is the best-of-both trick I never saw coming. A session checks the database on every single request: safe, always current, but a lookup every time. A pure JWT checks nothing, ever: fast, but you can't call it back. Two tokens sit right between them. The access token is the no-lookup JWT on the hot path, so the requests that happen constantly stay fast, and the refresh token is the database-backed, revocable thing on the cold path that fires rarely. You get the speed of stateless where it's hot and the killability of sessions where it counts.

The honest part: you probably don't need it

Now that I get it, I'm not going to pretend everyone should reach for two tokens. Most apps don't need this.

For a normal app with sessions, one token is fine. Give it a sane life, seven or thirty days, and when it expires, ask the user to log in again. That's not a security hole, that's just a login. The two-token dance has a real cost: you're now refreshing tokens on a timer, maintaining a blacklist, handling the refresh failing, handling the race where two requests refresh at once. That's more moving parts, and every moving part is a new place for it to break.

Notice that my seven-year JWT wasn't dumb because it was one token. It was dumb because it was unbounded and I couldn't kill it. A single token with a bounded life and a re-login is a perfectly reasonable design for most things I'd build today. Two tokens is what you reach for when the blast radius is big enough to earn the extra machinery: a big multi-tenant system, anything moving real money, anything where a leaked credential is expensive to clean up.

If I could hand one sentence back to the guy shipping that seven-year token, it'd be this. Short access, long refresh, only the refresh can mint new ones. If the small one leaks, the damage window is tiny. If the long one leaks, you blacklist it. That's the whole thing, and it took me two words, revocation and scopes, to see it.

SAML vs OIDC vs OAuth: The 60-Second B2B Playbook

Thu, 23 Apr 2026 05:29:52 +0000

SAML vs OIDC vs OAuth: The 60-Second B2B Playbook

TL;DR (read this first): OAuth 2.0 is authorization (a valet key for APIs). OIDC is authentication built on top of OAuth 2.0 (modern login for web, mobile, and SPAs). SAML 2.0 is a separate, XML-based protocol designed for enterprise Single Sign-On. If you are building a B2B SaaS in 2026, you will end up shipping all three — not picking one. The only real question is whether you build that plumbing yourself or front-end it with an identity broker like SSOJet.

Most "SAML vs OIDC vs OAuth" articles treat the three protocols as competitors. They are not. They solve different problems, were designed in different decades, and, in a real B2B product, they coexist.

This playbook gives you the 60-second decision tree, the 12 differences that actually matter in production, and the migration path enterprise customers will eventually force you down.

The 60-Second Decision Tree

Before we go deep, here is the decision your engineering team actually has to make. Read it out loud once and you will never confuse these protocols again.

Do you need to let a third-party app call an API on behalf of a user? → OAuth 2.0 (authorization).
Do you need to know who the user is so you can log them into your app? → OIDC (authentication, built on OAuth 2.0).
Is the customer a Fortune 500 buying your SaaS, and their IT team just emailed you an XML metadata file? → SAML 2.0 (enterprise SSO, non-negotiable).
All three of the above in the same product? → Welcome to B2B SaaS. You need a protocol-agnostic identity layer.

If you want a short mnemonic engineers actually remember: AuthN is SAML and OIDC. AuthZ is OAuth. OIDC is the one that speaks JSON.

Quick-Answer Comparison Table

Dimension	SAML 2.0	OIDC	OAuth 2.0
Purpose	Enterprise SSO / federation	User authentication	Delegated authorization
Year standardized	2005 (OASIS)	2014 (OpenID Foundation)	2012 (IETF, RFC 6749)
Token format	XML assertions	JSON Web Tokens (JWT)	Opaque strings or JWTs
Message signing	XML-DSig / XML-Enc	JOSE (JWS / JWE)	JOSE when JWTs are used
Transport	Browser redirects (HTTP-POST / Redirect / Artifact)	REST + JSON over HTTPS	REST + JSON over HTTPS
Discovery	Static XML metadata file	`/.well-known/openid-configuration` + JWKS URI	Manual or via OIDC discovery
Mobile / native app fit	Poor (designed for browsers)	Excellent	Excellent
Typical buyer	Enterprise IT / CISO	Developers / product teams	API / platform teams
Session & logout	Formal SLO spec (brittle in practice)	Front-channel / back-channel logout	Not defined (token revocation only)
Provisioning pair	Usually paired with SCIM	Usually paired with SCIM	N/A
Recommended flow (2026)	Web Browser SSO Profile	Authorization Code + PKCE	Authorization Code + PKCE / Client Credentials
Ease of debugging	Painful (XML signature errors)	Moderate (JWT is inspectable)	Moderate

Keep that table bookmarked. The rest of this playbook is just the "why" behind each row.

1. Protocol Origins: Why Each One Exists

Understanding the design goals of each protocol is the fastest way to stop confusing them.

SAML 2.0 was ratified by OASIS in March 2005, consolidating several earlier federation specs (Shibboleth, Liberty Alliance). It was built for a world where enterprises needed to bridge on-prem Active Directory with external web apps over a browser. Its design is optimized for heavy, attribute-rich assertions between two organizations that have a formal, pre-established trust relationship.

OAuth 2.0 was published as RFC 6749 in October 2012 by the IETF OAuth Working Group. Its explicit goal was not authentication. It answered the question: "How can a user let App A read their data in App B without handing App A their App B password?" Think of the first "Sign in with Twitter to post to Facebook" flows — that is the problem OAuth was invented for.

OpenID Connect (OIDC) launched on February 26, 2014, published by the OpenID Foundation. Developers were misusing OAuth 2.0 as a login protocol (because it was easier than SAML), and doing it badly and insecurely. OIDC standardized the pattern: it adds a signed ID Token (a JWT) on top of OAuth 2.0 so an app can reliably know who the user is.

So the lineage is simple: OAuth gave us delegation, OIDC added identity, SAML was already doing both for enterprises a decade earlier — just in XML.

2. Token Formats: XML Verbosity vs JWT Portability

This is where the protocols feel most different in day-to-day engineering.

A SAML assertion is a signed XML document — typically 2–8 KB, sometimes much larger once attribute statements and certificates are included. Signing uses XML-DSig, and if you have ever debugged an "XML Signature Wrapping" attack or a canonicalization mismatch, you know why SAML has a reputation for being brittle.

An OIDC ID Token is a compact JWT — usually a few hundred bytes to 1 KB, Base64URL-encoded, signed via JWS (JSON Web Signatures) using the JOSE framework. You can paste it into jwt.io and read it. Your backend can verify it in one line of code in almost any language.

Why this matters in production:

JWTs are mobile- and SPA-friendly. SAML assertions are not.
JWTs can be passed in an Authorization: Bearer header. SAML assertions typically cannot.
XML parsing is CPU-intensive. At scale, the difference between parsing 50,000 SAML assertions/sec and 50,000 JWTs/sec is measurable in servers and dollars.
JWTs have well-known attack classes (alg: none, key confusion) but they are documented attack classes. SAML's attack surface includes XSLT injection, entity expansion, and signature wrapping — a deeper, scarier well.

When enterprise customers ask "why are you pushing OIDC?", the honest answer is: because JWTs are easier to get right.

3. Transport and Flows

SAML rides on the browser. The three SAML bindings you will actually see are HTTP-Redirect (for requests, because they are small), HTTP-POST (for responses, because assertions are large), and occasionally HTTP-Artifact (for back-channel retrieval when you cannot trust the browser). Every SAML SSO flow goes: user → SP → browser redirect → IdP → browser POST → SP's Assertion Consumer Service (ACS) endpoint.

OIDC and OAuth ride on REST. The recommended flow in 2026 for every client type — web, SPA, mobile, desktop — is Authorization Code with PKCE (Proof Key for Code Exchange, RFC 7636). For machine-to-machine calls, OAuth 2.0 provides the Client Credentials grant, which SAML has no real equivalent to.

The practical consequence: if your product has a mobile app, a CLI, or any non-browser client, SAML alone is insufficient. You will need OIDC or OAuth to cover those surfaces.

For a deeper look at how modern OAuth flows are evolving, our OAuth 2.1 security defaults and migration checklist explains what has been deprecated and why.

4. Discovery and Key Rotation: Where SAML Ages Badly

This is the section that quietly destroys SAML deployments at 3 AM.

SAML discovery is static. Each party publishes an EntityDescriptor XML metadata file that lists endpoints, supported bindings, and — critically — embeds X.509 certificates inside <KeyDescriptor> elements. You either exchange this file manually (over email, seriously) or host it at a stable URL your partner polls.

Certificate rotation is where SAML deployments fail. When your SAML signing cert expires, every downstream SP breaks at once unless you have published the new cert inside the metadata during an overlap window and every partner has actually refreshed their copy. If you run B2B SAML at any scale, you will eventually have a war story about a Monday morning where 40 enterprise tenants lost SSO because a cert rolled over and half of them had cached the old metadata.

OIDC discovery is dynamic. An OIDC provider publishes /.well-known/openid-configuration, and inside that document is a jwks_uri pointing to a live JSON Web Key Set. Keys rotate by simply publishing a new key at the JWKS endpoint with a new kid (key ID). Clients automatically pick up the rotation on their next token validation. No emails, no coordination, no outages.

For the full operational playbook on this topic, see our guide on enterprise federation and SAML metadata management.

5. Enterprise vs Consumer Fit

There is a reason large, regulated enterprises still demand SAML in 2026. It is not nostalgia — it is procurement.

SAML 2.0 has 20 years of deployment inside ADFS, Ping Identity, Shibboleth, and established federation networks like InCommon and eduGAIN. It has been audited into FedRAMP, HIPAA, and banking-sector compliance documents. Your customer's CISO does not care that JWTs are more modern; they care that their auditor already has a checklist for SAML.

OIDC, on the other hand, dominates modern CIAM (Customer Identity and Access Management), SPAs, mobile apps, and workforce SSO at companies founded after 2015. Entra ID, Okta, Auth0, Google Workspace, and every modern IdP support it natively, and it plays well with everything downstream.

The B2B SaaS reality: ship both. Your mid-market customers will ask for OIDC (or be happy with either). Your enterprise customers will hand you a SAML metadata XML file on day one of procurement and expect you to make it work. This is exactly the pattern our SSO protocol primer: SAML, OIDC and OAuth explained walks through in more detail.

6. Session Management and the Single Logout Nightmare

SAML has a formal Single Logout (SLO) specification. In practice, it is one of the most reliably broken features in enterprise identity.

SLO requires the IdP to notify every SP that the user's session ended. The front-channel version does this by redirecting the user's browser through every SP's logout URL sequentially — which fails the instant the user closes the tab, hits an ad blocker, or a popup blocker intervenes. The back-channel version uses server-to-server SOAP calls, which are more reliable but require every SP to be reachable from the IdP over a network that firewalls rarely permit. The SAML spec itself acknowledges "partial logout" as a valid outcome.

OIDC defines front-channel, back-channel, and session management logout modes. None of them are perfect either, but they use modern transports (iframes, direct HTTP calls) and standardized JWTs for logout tokens. Failures are easier to debug.

Honest take: if you promise customers "one-click log out of everything," read the fine print of whichever spec you pick. SLO is hard in every protocol. Plan for session TTLs and step-up auth rather than relying on SLO to save you.

7. Provisioning: SCIM Is the Missing Piece

Neither SAML nor OIDC handles user lifecycle well on its own. Both can do Just-In-Time (JIT) provisioning — creating a user account in your app the first time they authenticate — but JIT has a fatal flaw: it does not handle deprovisioning.

When an enterprise fires an employee, the identity provider revokes access instantly. But if your app was relying on JIT, that user's account in your system still exists, with the last set of attributes it saw. Orphaned accounts are a compliance finding waiting to happen.

The fix is SCIM (System for Cross-domain Identity Management) — an out-of-band REST API the IdP calls to create, update, and deactivate users in your app in near real time. Modern B2B SSO is really a three-legged stool: SAML or OIDC for login + SCIM for lifecycle + MFA enforcement for compliance.

Most enterprise procurement checklists in 2026 require all three. If you implement only SSO, you will still fail security reviews.

8. Tooling and Developer Ecosystem

Okta, Auth0, Microsoft Entra ID, Google, and Ping all support SAML and OIDC. The libraries exist in every major language. But the quality of experience differs sharply.

OIDC libraries are generally first-class, actively maintained, and have sensible defaults. openid-client for Node, authlib for Python, Spring Security OAuth for Java.
SAML libraries tend to be older, less m

Autopilot - the API Nightmare: How I Defeated LinkedIn Bureaucracy to Automate My Company

Fri, 13 Feb 2026 07:04:33 +0000

Until now, everything was fun. We had AI agents with cynical personalities (Post 3) and a brain capable of analyzing text (Post 2). But everything lived in the safety of my terminal, on localhost.

For Datalaria Autopilot to become real, it had to get out into the world.

Here is where the project stopped being an engineering problem and became a battle against API Bureaucracy.

The Goal: Publishing as a Brand, Not a Person

My requirement was clear: I don't want the bot posting on my personal LinkedIn profile. I want it to post on the Datalaria Company Page, with the official logo and a corporate tone.

Technically, this requires a change in the API endpoint:

Personal Profile: urn:li:person:12345
Company Page: urn:li:organization:110125695

It looks like a one-line code change. It ended up being a couple of days of waiting and red tape.

Battle 1: Twitter (X) and the Anti-Bot Wall

First up, Twitter. Getting API access these days requires passing an audition. I had to apply for the Free Tier and write a "motivational letter" explaining that I am not a Russian spam bot, but an AI technical enthusiast.

After getting past the 403 Forbidden error (I forgot to enable "Read & Write" permissions) and the Duplicate Content error (I tried sending the same "Hello World" twice), I achieved connection. Twitter/X was ready, and in principle, everything worked simply.

Battle 2: The Final Boss (LinkedIn Company Pages)

The biggest problem occurred with LinkedIn.

I designed my social_manager.py script to use a company ID if it existed in the environment variables:

# Hybrid logic in Python
if company_id:
    print(f" Company ID Detected. Posting as page...")
    author_urn = f"urn:li:organization:{company_id}"
else:
    print(" Posting as personal profile...")

When I ran it, the console spat out a blood-red error:

❌ Error posting to LinkedIn: Status 403: ACCESS_DENIED

The Ghost Permission: `w_organization_social`

I discovered that the standard LinkedIn token only gives you the w_member_social permission (posting as a person). The permission for companies (w_organization_social) did not exist in my developer dashboard.

To unlock it, I had to complete an administrative scavenger hunt:

Page Verification: I had to generate a special URL in the Developer Portal and approve it with my admin account. Result: Company Verified. ✅
Even so, it didn't work: The permission still didn't appear.
The Hidden Request: I had to request access to the "Marketing Developer Platform" product.
The Form: LinkedIn made me fill out a questionnaire detailing that I am a "Direct Customer," that I am not an advertising agency, and that my usage is strictly internal for organic automation.

The Victory

After a few hours of waiting, the approval email arrived. I re-generated the token and... there it was!

With the new "Super Token" loaded into my .env, I ran the script one last time.

--- TESTING SOCIAL MEDIA MANAGER ---
DTO - Posting to Twitter... ✅ Success!
DTO - Posting to LinkedIn...
 Company ID Detected: 110125695.
✅ LinkedIn Success! Post ID: urn:li:share:741...

And the definitive proof on the social network:

Conclusion and Next Steps

I have achieved what seemed impossible: a Python script that has legal authorization to act as my company.

But there is one final problem: This token expires in 60 days.

If I do nothing, in two months this whole system will break. Furthermore, I am still running the script manually from my laptop.

In the final post of this series, we are going to automate it all. We will use GitHub Actions so the system runs itself every time I upload an article, and (if the API lets us) we will implement automatic token renewal.

Coming Up - Post 5: Total Automation (CI/CD).

Source Code: The final social_manager.py module is available in the GitHub repo.

Coder Legion - Recent posts tagged oauth

AdMob Earnings Dashboard for iOS: OAuth with PKCE, AdMob Reporting API and Offline Caching

1. The shape of the app: no middleman

2. OAuth for a native app: system browser, PKCE, no embedded web views

3. Exchanging the code and keeping tokens safe

4. Asking AdMob for a report

5. Decoding a streamed report

6. Why "today" is a Los Angeles day

7. Pull to refresh, offline cache and the weekly view

8. Real-world example: AdEarnings Pro

9. Before you ship an OAuth-powered dashboard: a checklist

Wrapping up

OAuth Is Not “Login.” I Found That Out the Hard Way in Production

Your NextAuth callbackUrl Might Be an Open Redirect Waiting to Happen

The Pattern That Looks Completely Reasonable

What an Attacker Actually Does With This

Why This Is Easy to Miss

The Fix: Validate the Redirect Target Is Actually Internal

The Rule

You Changed a User's Role in the Database, But Their JWT Doesn't Know That Yet

Why This Happens: JWTs Don't Check Back In

Where This Actually Causes Real Problems

Why This Is Easy to Miss Building the App

The Fix: Force Re-Verification for Anything Sensitive

The Rule

Fixing Threads API Authorization Code Failures

The Three-Legged Token Flow

The Four Failure Modes

The Diagnostic Ladder

Code Example for Token Exchange

After the Token Lands

Conclusion

From Broken Google OAuth to a Stable Sepolia E2E Environment: Engineering MyZubster on a VPS

From Broken Google OAuth to a Stable Sepolia E2E Environment: Engineering MyZubster on a VPS

1. The Starting Point

2. Debugging Google OAuth

3. Validating the Runtime Environment

4. Google OAuth Successfully Completed

5. Fixing the OAuth Redirect

6. Testing the Complete OAuth Path

7. Removing Temporary Debug Instrumentation

8. Stabilizing Urban Lab / I-ECO-01

9. Stopping a Multi-Million-Restart PM2 Loop

10. Current VPS Architecture

11. Git Hygiene

12. Security Considerations

13. What Is Working Now

14. What Still Needs to Be Done

Authentication hardening

Deployment reproducibility

Monitoring

Secret management

CI/CD

15. Where We Want to Go

16. Engineering Lessons

Inspect the real provider response

.env is not necessarily the runtime environment

online does not necessarily mean healthy

Debug instrumentation should be temporary

Infrastructure fixes should end in Git

Conclusion

🔐 Understanding SAML, OAuth 2.0 and OpenID Connect

🔎 What Are These Protocols?

SAML 2.0 (Security Assertion Markup Language)

OAuth 2.0 (Open Authorization)

OpenID Connect (OIDC)

🔍 Let’s Understand This with a Story

1️⃣ SAML 2.0 – The VIP Pass for Employees

How It Works (SAML Flow):

2️⃣ OAuth 2.0 – Borrowing a Friend’s Car (Authorization, Not Authentication)

How It Works (OAuth Flow):

3️⃣ OpenID Connect (OIDC) – VIP Pass with Your Photo (Authentication + Authorization)

How It Works (OIDC Flow):

🤔 When to Use Which Protocol?

🎯 Final Thoughts

Building a Human-in-the-Loop GitHub Profile Automation with MyZubster and Zorgax

Looking for 3 Beta Testers – HubSpot OAuth Installation Flow (Marketplace Submission)

SAML vs OIDC vs OAuth 2.0: 12 Differences Every B2B Engineering Team Should Know

The 30-Second Mental Model

Protocol Snapshot Table

`.env` is not necessarily the runtime environment

`online` does not necessarily mean healthy

The Ghost Permission: `w_organization_social`