Ship the iOS/Android app — the backend is done. Apple, Google and passwordless sign-in, a clean bearer-token JSON API, user profiles and per-user data, plus an operator console to run it. Subscriptions wired for in-app plans, on plain PHP and SQLite.
Apple, Google and passwordless sign-in, a bearer-token JSON API, profiles and per-user data — the whole backend your app needs, on plain PHP and SQLite. No Firebase bill, no SDK to babysit.
Point your iOS or Android app at one PHP backend. It verifies Apple/Google/passwordless sign-in, hands the app a bearer token, and serves a clean JSON API over per-user data. No Firebase bill, no SDK to babysit.
The app sends the provider id_token; the backend verifies its RS256 signature against Apple/Google JWKS before trusting a single claim, then finds-or-creates the user through the same identity-linking path the web login uses. No client claim is taken on faith.
app_request_code emails a 6-digit code; app_verify_code checks it and returns a token. It reuses the exact login-code mechanism the website uses, so there is one auth pipeline to reason about and no passwords anywhere in the database.
Sign-in mints a long random at_ token returned once. Only a peppered HMAC-SHA256 hash and the device label hit the database; last_used_at is stamped per call, and any device can be revoked. A leaked DB hands an attacker nothing usable.
app_me, app_profile_update, app_logout and a full app_items CRUD ship as working, per-user-scoped endpoints with consistent JSON envelopes, status codes and validation. Clone app_items into your own models and keep the shape.
Each app token is throttled by a fixed-window limiter in SQLite — 300 requests per 60s out of the box, one env var to change. Over the line returns 429 with a Retry-After header. No Redis, no sidecar.
The member app is a backend console: app users with their auth provider and last-seen, the live app data, which sign-in methods are enabled, issue/revoke app tokens, and a copy-paste cURL + Swift quickstart. Subscriptions are wired for in-app plans.
Your app sends the provider id_token; the backend verifies its signature, finds-or-creates the user, and returns a bearer app token the app stores. Every call after that is one header.
# 1. Sign in: the app posts the Apple/Google id_token. curl -X POST https://api.yourapp.com/api.php?action=app_auth_apple \ -d '{"id_token":"eyJ...","nonce":"a1f3","device":"iPhone 15"}' { "ok": true, "token": "at_9f2a…", "user": { "id": 51, "email": "ada@app.dev" } } # 2. Every call after: one Authorization header. curl https://api.yourapp.com/api.php?action=app_items_list \ -H "Authorization: Bearer at_9f2a…" { "ok": true, "items": [ { "id": 12, "title": "Hello" } ] }
Every figure here is how the backend actually behaves the moment you deploy it — not a sales chart. It's a template.
Every request runs a short, readable path: verify the caller, resolve the token, run your code. It is plain PHP you can read top to bottom — no framework, no managed-auth dashboard.
A native id_token arrives with no trusted server channel behind it, so the backend fetches the provider JWKS, verifies the RS256 signature, then checks issuer, audience, expiry and the app-supplied nonce. Only a verified email is ever linked to an account.
On success the backend issues an at_ token and returns it once. The app stores it in the Keychain / Keystore and sends it as Authorization: Bearer on every later call. The server keeps only a peppered hash, so the plaintext never sits in the database.
require_app_user() hashes the incoming bearer token, matches it to its owner in one query, stamps last_used_at and applies the per-token rate limit — a bad or revoked token is a clean 401 before any work happens. No session, no CSRF; this is the app surface.
Every app_items query is filtered by the authenticated user id, so one account can never read or delete another's rows. Clone the resource, rename it, and your API answers in the same JSON shape the Stripe webhooks and admin console already speak.
Apple/Google/passwordless sign-in, id_token verification, bearer app tokens and a JSON API over per-user data all wire into one core. Point your iOS/Android app at it and ship.
Every install ships with this. Search users, replay webhooks, inspect billing and revoke keys — server-rendered, access-gated, no second app.
| User | Plan | Status | Joined |
|---|---|---|---|
| ada@example.com | Pro | active | 2d ago |
| grace@example.com | Scale | active | 5d ago |
| linus@example.com | Starter | past due | 3w ago |
| margaret@example.com | Pro | active | 1mo ago |
| blocked@example.com | Free | blocked | 1mo ago |
invoice.paidevt_1Q8x…a3customer.subscription.updatedevt_1Q8w…f1checkout.session.completedevt_1Q8w…7cinvoice.payment_failedevt_1Q8v…02charge.refundedevt_1Q8u…9dcurl -H "Authorization: Bearer ss_live_••••" \ https://app.yoursaas.com/api.php?resource=notes { "ok": true, "data": [ "note_18f2", "note_18f9" ], "rate_limit": "58/60", "credits_left": 1840 }
copy a template folder
composer install · Stripe + SES
rebrand · plans · run doctor
NGINX + PHP-FPM · take cards
unzip → live on a VPS — one afternoon.
Most SaaS dies of complexity, not competition.
| daily_hits | 100,000+ |
| cost / 10k logins | $1 |
| whole_stack / month | < $10 |
| reads_block_writes | never · WAL mode |
Define plans in app/subscriptions.php, attach Stripe price IDs, and the checkout flow stays generic across every project.
Default access for new users and trial accounts.
For a small paid SaaS tier.
For heavier usage and premium features.
For power users and high-credit products.
With bearer API keys they generate from their dashboard. Keys are hashed and peppered at rest, can be revoked or rotated, and are capped per user.
Per-key rate limits are built in, and each call can cost credits — so you bill by usage and protect your endpoints from one config.
Yes — plans set access levels and credit grants, so higher tiers get higher limits and more included calls.
Yes — parameterised SQL throughout, signed Stripe webhooks, CSRF, rate limiting and session hardening, all security-reviewed. Real plumbing, not a toy.
One small VPS runs the whole stack for a few dollars a month, and passwordless login emails on Amazon SES are about $1 per 10,000 sign-ins. Prefer Apple or Google sign-in? Both are built in and cost nothing to run — each just needs that provider's active developer account — so you can skip login emails entirely. No per-seat platform bills.
Passwordless sign-in, Stripe billing, credits and admin — already wired. Copy a folder, rename it, start charging.