DEV Community: DGIT

JWT auth across web and mobile in ASP.NET Core — what I actually built and why

DGIT — Mon, 29 Jun 2026 20:38:38 +0000

Every app needs auth. It's the part of a project that's genuinely hard to get right, surprisingly easy to get wrong in subtle ways, and also the part where you look at Auth0 or Clerk and think: maybe I just pay someone else to deal with this.

I didn't. Here's what I built instead, why, and the parts that tripped me up.

This is part of a series on MiniStack — a full-stack mobile boilerplate built on Expo + ASP.NET Core. The # covers the full stack and how the whole project came together.

Why not Auth0 or Clerk

Honest answer: familiarity. I've been writing .NET for ten years and I understand how JWT auth works in ASP.NET Core. I didn't want to introduce an external service that manages my users, sits between my app and its database, and adds a pricing conversation when things scale.

That's a personal call, not a universal one. Auth0 and Clerk are good products. If your team doesn't have strong backend auth experience, reaching for one of them is probably the right move. I just wasn't in that situation, and owning the full implementation felt cleaner to me.

What I built ended up being fairly standard — a split-token pattern with some decisions around per-device sessions that are worth explaining.

The token model

Two tokens. Short-lived access tokens, long-lived refresh tokens.

Access tokens live in memory only. Never written to disk, never stored in localStorage, never put in a cookie. They're valid for 60 minutes. When your app starts or the token expires, it gets a new one using the refresh token. If the app is closed, the access token is gone — that's intentional.

Refresh tokens are different. They're persisted — one row per device in a UserRefreshTokens table — and they're valid for 30 days. Every time a refresh token is used, the old row is deleted and a new one is inserted. This is called token rotation. If a refresh token is stolen and used, the original owner's next request will fail because their token no longer exists.

The per-device model was a deliberate decision. I see a lot of implementations that store a single refresh token on the user record. The problem: if you log out on your phone, you've ended your session on your laptop too. That's not how any modern app works. One row per device means logout only affects the device that requested it. Password reset, on the other hand, deletes all rows — every device gets logged out, which is the right behaviour after a credential change.

Where the tokens live on each platform

On mobile (Expo): the refresh token goes into expo-secure-store, which maps to iOS Keychain on iPhone and Android Keystore on Android. The access token is a module-level variable in the API service — in memory, gone when the app closes. On startup, the app reads the stored refresh token, calls /api/auth/refresh, and gets a new access token back.

On web (Next.js): the browser never sees the refresh token directly. There's a small backend-for-frontend layer — three Next.js API routes:

POST /api/set-refresh-token — stores the refresh token in an httpOnly cookie after login
POST /api/refresh — reads the cookie, calls the ASP.NET Core refresh endpoint, updates the cookie
POST /api/clear-refresh-token — deletes the cookie on logout

An httpOnly cookie can't be read by JavaScript. If the page has an XSS vulnerability, the refresh token is still safe. The access token — which JavaScript does need — is kept in React state, which means it's gone on page refresh, triggering a silent refresh via the cookie.

Google and Apple Sign-In

The mental model that unlocked this for me: the backend doesn't do an OAuth redirect flow. It just validates a JWT.

Expo's auth libraries handle the actual OAuth dance on-device — opening a browser, redirecting, getting the response back. What comes out the other end is a signed token: an id_token from Google, an identityToken from Apple. The mobile app sends that token to the backend. The backend validates the signature against the provider's public keys and extracts the claims. That's it.

For Google: GoogleJsonWebSignature.ValidateAsync from the Google.Apis.Auth package does the heavy lifting. It verifies the signature, checks expiry, and confirms the audience matches your configured client IDs. For Apple: you fetch the JWKS from https://appleid.apple.com/auth/keys and validate the JWT manually, checking the bundle ID as the audience.

Both flows end the same way as email/password login: upsert the user, issue an access token and refresh token, return the auth response. OAuth users are marked as email-verified immediately — the provider already verified it.

One Apple-specific thing worth knowing: Apple only gives you the user's name on the very first sign-in. After that, you get a stable user ID (sub) but no name. Save the name on that first call or you'll never get it.

Getting Google Sign-In to work correctly across all Expo platforms took four separate fixes. I'll cover those in detail in the next article — they're specific enough to warrant their own post.

Email verification and password reset

Registration issues a refresh token immediately so the user can start using the app, but sets EmailVerified = false. A 24-hour verification link goes out by email. OAuth registrations skip this — the provider already verified the address.

Password reset follows a pattern you've probably seen: POST /api/auth/forgot-password with an email address always returns 200, regardless of whether the account exists. This prevents user enumeration — an attacker can't use your reset endpoint to discover which emails are registered. The reset token is valid for one hour, and using it deletes every refresh token row for that user. All devices get logged out. If someone reset your password, you want them out everywhere.

Rate limiting

Auth endpoints — login, register, forgot-password — are limited to 5 requests per 15 minutes per IP. OAuth endpoints get a slightly higher limit (30 per 15 minutes) since OAuth flows can involve multiple round trips legitimately.

One implementation detail worth noting: the rate limiter runs as middleware, so it also runs in tests. Integration tests will start failing in confusing ways if you don't disable it in your test environment. The fix is a single environment check in Program.cs — skip AddRateLimiter and UseRateLimiter when the environment is Testing. Obvious once you've hit it, not obvious before.

A few smaller decisions

ClockSkew = TimeSpan.Zero — The default in .NET is a 5-minute tolerance, meaning a token that expired 4 minutes ago is still accepted. That's there to handle clock drift between servers, which is a real concern in some architectures. In this setup there's one backend and tokens should expire precisely when they say they do.

CORS via config, not code — Origins are configured via appsettings (Cors:AllowedOrigins) rather than hardcoded. An empty array falls back to AllowAnyOrigin for local development, so you're not fighting CORS during development but you're forced to be explicit in production.

Security headers — X-Content-Type-Options, HSTS, and a few others go out with every response. Nothing exotic, just the basics that scanners and security reviews will flag if they're missing.

Configuration

Everything auth-related lives in appsettings and gets injected at startup. JWT secret, issuer, audience, token lifetimes, CORS origins, Google client IDs, Apple bundle ID, email SMTP config. Nothing hardcoded, nothing in the repo — all of it goes into environment variables or a secrets manager in production.

In development, leaving the SMTP config empty makes the backend log email links to the console instead of sending them. That's useful for testing verification and reset flows without needing a real email service wired up.

Is it worth building yourself?

For me, yes. I own the implementation, I understand every part of it, and there's no external dependency on my authentication path.

The tradeoff is real though. This took time to get right. If I'd reached for Auth0 the auth would have been done in an afternoon. What I built took significantly longer and required knowing enough about JWT, OAuth, and token security to make reasonable decisions along the way.

The code for all of this is in MiniStack. The auth architecture is documented in full in AUTH.md in the repo, including flow diagrams for every auth path and a full configuration reference.

Questions? Open a discussion.

How I built a production mobile app boilerplate in two weeks without writing a line of frontend code

DGIT — Mon, 29 Jun 2026 14:28:24 +0000

How I built a production mobile app boilerplate in two weeks without writing a line of frontend code

Eight months ago my wife and I had twins.

The baby tracker apps on the App Store weren't designed for multiples. Most were paid. The free ones were missing things. None of them thought about two babies at the same time — one timer, one log, one feeding. So I built my own. TwinLog is a free tracker for twins and multiples ([https://play.google.com/store/apps/details?id=com.dgit.babytracker]) . My wife uses it every day. It just launched on the Play Store with almost no users and I'm genuinely fine with that — it was built because we needed it, not because I wanted users.

After shipping it I noticed something obvious in hindsight: every app starts with the same work. Authentication, payments, cloud infrastructure, CI/CD pipelines. Two weeks of scaffolding before you write a single line of what your app actually does. TwinLog has none of that — no auth because I didn't have time, no payments because it's free, no web frontend. I skipped everything non-essential to ship fast.

But a commercial app can't skip those things. And I wasn't going to rebuild them from scratch every time.

So I built MiniStack — a full-stack mobile boilerplate — instead.

The stack

Expo for mobile (React Native), Next.js 15 for the web frontend, ASP.NET Core with EF Core for the backend, PostgreSQL for the database. Terraform modules for both GCP and Azure. GitHub Actions for CI/CD. Google and Apple Sign-In, email/password auth, Stripe subscriptions with a free tier, email verification, push notification wiring.

I'm a .NET developer. Ten years. I don't particularly enjoy frontend — I can do it but it takes me longer and I enjoy it less. Picking ASP.NET Core as the backend wasn't a considered tradeoff, it was just the obvious choice. I know it, it's fast, and I had no reason to relearn deployment tooling and testing patterns in Node just because the frontend uses TypeScript.

Most React Native starters assume a JavaScript backend. This one doesn't. If you're a Node developer this probably isn't for you. If you're a .NET developer who wants to ship a mobile app without switching ecosystems, keep reading.

How it was actually built

The whole codebase was written by Claude AI. I directed, it implemented.

I should be specific about what that means, because "written by AI" covers a lot of ground. I didn't paste prompts into a chat and copy code into files. I used Claude Desktop's Cowork tab for the earlier project (TwinLog) — that gives Claude direct access to your repo and it edits files itself, but you still copy-paste and run terminal commands manually. I switched to Claude Code in VS Code quickly. The difference is that Claude Code runs the commands too. You see file diffs appear in your editor in real time. When something breaks you can see exactly what changed and why, which makes course-correcting much faster on a project with dozens of interconnected files.

What I actually did: described what I wanted, reviewed what came back, made the architectural calls, and corrected direction when something was wrong. I didn't write the implementation. It's the first time I've worked this way on a real project — not a tutorial, not a toy — and it held up.

It took about two weeks. A couple of hours a day, not every day.

Auth: custom JWT without Auth0

TwinLog has no authentication. MiniStack has full authentication. The decision to build it ourselves rather than use Auth0, Clerk, or Supabase Auth was mostly about familiarity. I understand .NET JWT auth. I didn't want another external service managing my users or another pricing tier to reason about when my next app scales.

This is personal preference, not a universal recommendation. Auth0 and Clerk are good products. For teams without strong backend auth experience they're probably the right call.

The implementation uses a split-token pattern. Access tokens live in memory only, 60-minute lifetime. Refresh tokens are in the database, one row per device, rotated every time they're used. On the web the refresh token sits in an httpOnly cookie managed by a Next.js API route — JavaScript in the browser never touches it. On mobile it goes into expo-secure-store, which maps to iOS Keychain or Android Keystore.

Each device has its own session. Logging out on your phone doesn't end your session on your laptop.

Google and Apple Sign-In took a while to get right. The mental model that helped: the backend doesn't do a redirect flow. Expo's libraries handle the OAuth dance on-device and return a signed token — id_token from Google, identityToken from Apple. The backend validates that token against the provider's public keys and issues its own JWT. That's the whole thing. Once I understood that the server was just validating a JWT — something it already knew how to do — it stopped feeling mysterious.

Getting it working across all platforms was four separate bug fixes. I'll cover them in detail in the Google Sign-In article.

Infrastructure: Terraform because I don't like clicking in portals

My Azure subscription had one month of free credits. GCP offers three. I moved to GCP.

I didn't want to learn where to click in the GCP console. The portal changes constantly and every tutorial has screenshots of a UI that no longer exists. I wanted something I could run again from scratch without rediscovering each step.

The goal was simple: terraform init && terraform apply. Phase 1 is three terminal commands — authenticate, set a project ID, enable billing. After that Terraform provisions everything: Cloud Run service, Artifact Registry, service accounts, IAM roles, Workload Identity Federation so GitHub Actions can deploy without any stored credentials. The deploy workflow pushes a Docker image and Cloud Run updates. No secrets sitting in GitHub settings beyond the ones you actually need.

Getting there took more iterations than I expected. Workload Identity Federation has ordering dependencies that aren't obvious — the identity pool has to exist before you can grant roles against it, but the service account needs those roles before Cloud Run can pull from Artifact Registry. The Terraform for Azure had its own issues around federated credentials and Container App identity. The infra modules went through several revisions.

But once it's done it just works. A buyer runs Terraform once, puts a handful of values into GitHub Secrets, and pushes. Every merge to master builds, tests, and deploys.

Stripe

The demo entity in MiniStack is a habit tracker. Free tier: 3 habits. Pro: unlimited. That's not because anyone buying a boilerplate wants to build a habit tracker — it's because it's a clean way to show subscription gating. The pattern is straightforward to swap out for whatever your actual paid feature is.

The implementation is a Stripe Checkout Session for subscribing, a Customer Portal session for managing or cancelling, and a webhook handler that updates the user's subscription status in the database. The backend returns 403 upgrade_required when a free-tier user hits a gated endpoint. The client handles that and redirects to the subscription screen.

Honest take on building with Claude

It worked for this kind of project. The backend code was fast and I could review it confidently because I know the domain. Terraform was solid. The frontend worked but I was a less useful reviewer there — issues showed up at runtime rather than in code review, because I'm not strong enough on React to spot them from reading.

What it doesn't replace is understanding. There were decisions throughout that I had to make — what to use, why, how the pieces fit together. Claude implemented those decisions. When something was wrong I had to notice and describe what was wrong. That requires knowing enough to have an opinion.

If you're hoping to build something you don't understand by delegating to an AI, this workflow won't save you. If you know the domain well enough to review what comes back and catch what's off, the speed gain is real.

MiniStack is a commercial template — US$197, one purchase, unlimited projects. You clone it, run node scripts/setup.js, answer three questions, and it renames everything across the monorepo. Then you wire up your credentials and push.

https://gormez.gumroad.com/l/ministack

Also in this series: the auth architecture in detail (https://dev.to/dgit/jwt-auth-across-web-and-mobile-in-aspnet-core-what-i-actually-built-and-why-10kd) — Google Sign-In: four bugs, four fixes — Terraform without the portal — Stripe subscription gating in ASP.NET Core (To be published soon)