Next.js, Expo ve Tauri arasında kimlik doğrulama ve ödemeler nasıl paylaşılır?
Tek kimlik modeli ve tek yetki deposu tutup tutamadığınıza bağlı. Web HttpOnly cookie oturumları kullanır; Expo, deep link OAuth geri çağrısından sonra bir bearer token'ı expo-secure-store'a kaydeder; Tauri webview'inde web oturumunu yeniden kullanır — hepsi aynı Better Auth örneğiyle doğrulanır. Ödemeler de aynı kurala uyar: 8 web geçidi ve RevenueCat mobil IAP, her yüzeyin okuduğu workspace düzeyi yetkileri yazan tek bir idempotent webhook defterine akar.
Platformlar arası SaaS'ın yırtıldığı iki dikiş
Web SaaS'ına mobil uygulama kaynaklamış bir ekibe asıl nerenin acıdığını sorun — cevap asla arayüz değildir. Kimlik ve paradır: tarayıcıda temiz dönen OAuth akışının uygulamaya deep link ile dönmesi gerekir; ve web'de ödeyen müşteri, yetkisinin telefonda anında görünmesini bekler.
Ekipler bunu genelde iki yarım çözüm yayınladıktan sonra fark eder: WKWebView içinde sessizce çalışmayan cookie mantığı ve web veritabanındaki Stripe aboneliğiyle çatışan RevenueCat yetkisi. Çözüm mimaridir — ve iki kez aynı çözümdür: tek kimlik modeli, tek yetki deposu.
Tek Better Auth örneği, üç oturum taşıyıcısı
supastack, @supastack/auth içinde yüzey başına giriş noktaları olan tek bir Better Auth yapılandırması tutar. İki web uygulaması (Next.js 16 ve TanStack Start) HttpOnly, SameSite=Lax cookie oturumları kullanır — varsayılan olarak CSRF güvenli ve Server Components dostu. Expo uygulaması, deep link geri çağrısının sonunda OAuth veya sihirli bağlantı tamamlanmasını bir bearer token ile değiştirir, expo-secure-store'da (iOS Keychain / Android Keystore) saklar ve Authorization başlığıyla gönderir; aynı auth ara katmanı doğrular.
Tauri'nin masaüstü kabuğu web uygulamasına bakan tek bir webview olduğundan web oturumunu doğrudan miras alır — bakımı gereken üçüncü bir auth akışı yok. Mobil auth kılavuzu ve deep link kılavuzu geri çağrı sözleşmesini belgeliyor; web + mobil monorepo kılavuzumuz paylaşılan istemci kodunu gösteriyor.
// packages/auth/src/client.ts — one client, two storages
import { createAuthClient } from "better-auth/react";
import { expoClient } from "@better-auth/expo/client";
export function createCrossPlatformAuthClient(baseURL: string, storage?: any) {
return createAuthClient({
baseURL,
plugins: storage ? [expoClient({ scheme: "myapp", storage })] : [],
});
}
// Web: cookie session. Mobile: bearer token in SecureStore.
// Desktop: the web app's own session inside the Tauri webview.Sekiz ödeme geçidi, tek sözleşme
Her web ödeme sağlayıcısı — Stripe, Lemon Squeezy, Polar, Creem, Dodo, Paddle, Whop ve PayPal — aynı @supastack/billing sözleşmesine bağlanır ve her imzalı webhook, yetkilere dokunmadan önce idempotent webhook_event defterine düşer. Sağlayıcı tekrarları ve sırasız teslimatlar, destek bileti değil veritabanı sınırında zararsız boş işlemler olur.
Mobil uygulama içi satın alımlar RevenueCat üzerinden aynı deftere katılır: mağaza fişleri sunucu tarafında doğrulanır ve yetkiler cihaza değil workspace'e yazılır — iOS'ta ödeyen bir kullanıcı web ve masaüstünde de anında ödemiş sayılır. RevenueCat kılavuzu App Store / Play bağlantısını, idempotent faturalama webhook'ları ise defterin neden taşıyıcı parça olduğunu anlatıyor.
Senkronizasyonu sıkıcı hâle getiren yetki modeli
Sıkıcı kalmasının sebebi: yetkiler workspace'te yaşar ve sunucuda çözümlenir. Hiçbir istemci 'ödendi' bilgisini tutmaz — web oturuma, mobil API'ye, masaüstü web uygulamasına sorar — ve üçü de aynı cevabı alır çünkü cevap verebilecek tek bir kayıt vardır.
Yeni telefonda satın alma geri yükleme, web'de Stripe yenilemesi, panelde eklenen bir Agency koltuğu — her biri, her yüzeyin bir sonraki sorgusunda okuduğu aynı yetki satırlarına yapılan yazmalardır. Senkronize edilecek bir şey olmadığı için kurulacak bir senkronizasyon motoru yoktur.
| Yüzey | Oturum taşıyıcısı | Ödeme yolu | Yetkilerin okunduğu yer |
|---|---|---|---|
| Next.js 16 web | HttpOnly cookie | 8 geçitten herhangi biri → webhook defteri | Paylaşılan Postgres yetki satırları |
| TanStack Start web | HttpOnly cookie | Aynı adaptörler, aynı defter | Paylaşılan Postgres yetki satırları |
| Expo iOS / Android | expo-secure-store'daki bearer token | RevenueCat IAP → sunucu-doğrulamalı fiş | Aynı satırlar (tipli API üzerinden) |
| Tauri 2 masaüstü | webview içindeki web oturumu | Kabuk içindeki web checkout'u | Aynı satırlar (web uygulaması üzerinden) |
| MV3 uzantısı | Workspace API anahtarı | — (workspace verisi okur) | Aynı satırlar (/api/v1 üzerinden) |
Kurmaktan kurtulduklarınız
Akşam mesaileriyle ölçersek, temel ile özellik listesi arasındaki fark budur: deep link auth dönüşü, SecureStore token kalıcılığı, tekrar korumalı sekiz webhook entegrasyonu, App Store fiş doğrulaması ve cihazlar arasında asla çelişmeyen bir yetki modeli. Hepsi teslim edilmiş, test edilmiş (693+ test kimlik bilgisi olmadan çalışır) ve belgelenmiş durumda.
$299'luk Full Bundle tüm yüzeyleri tek repoda içerir — koltuk sayıları ve ajans kademeleri fiyat sayfasında.
SSS: platformlar arası auth ve ödeme paylaşımı
Ekiplerin birleşik stack'e bağlanmadan önce sorduğu sorular:
- Mobil kullanıcılar web'den ayrı mı giriş yapar?, Hayır. OAuth veya sihirli bağlantı akışı deep link ile uygulamaya döner ve aynı oturumu verir; veren taraf aynı Better Auth örneği olduğundan web ve mobil 'siz kimsiniz' sorusunda aynı fikirdedir.
- iOS'ta ödeyip web uygulamasını kullanan biri olursa?, RevenueCat satın alımı sunucu tarafında teslim eder; yetki, web'in okuduğu aynı workspace satırlarına yazılır ve web uygulaması bir sonraki istekte 'ödendi' gösterir.
- Sadece web ile başlayıp uygulamaları sonra ekleyebilir miyim?, Evet — auth ve faturalama paylaşılan paketlerde yaşar; mobil ve masaüstü uygulamaları, o yüzeyleri açtığınız anda onları miras alır.
- Tauri uygulamasının kendi checkout'una ihtiyacı var mı?, Hayır — masaüstü kabuğu, webview'inde web uygulamasının oturum ve checkout'unu yeniden kullanır; savunulacak ikinci bir ödeme yüzeyi yoktur.