L’authentification « social login » via OAuth Google est devenue un standard d’UX en 2026 (informations vérifiées en avril 2026, susceptibles d’évoluer) : les utilisateurs détestent créer des comptes et préfèrent cliquer sur « Continuer avec Google ». Pocketbase intègre nativement les flows OAuth pour Google, GitHub, Apple, Facebook, Microsoft et bien d’autres. Voici le tutoriel pour activer Google OAuth dans une app Pocketbase + frontend (web ou mobile) en 2026.

Voir le guide pratique Pocketbase pour les bases.

Étape 1 — Créer un projet Google Cloud

Aller sur console.cloud.google.com
Créer un nouveau projet (ex : monapp-prod)
APIs & Services → OAuth consent screen → External
Renseigner nom de l’app, email support, logo, domaine, scopes (email, profile)
Ajouter les domaines autorisés : api.exemple.sn, app.exemple.sn
APIs & Services → Credentials → Create Credentials → OAuth client ID → Web application
Authorized redirect URIs : https://api.exemple.sn/api/oauth2-redirect
Récupérer Client ID et Client Secret

Étape 2 — Configurer Pocketbase

Dashboard admin Pocketbase → Settings → Auth providers → Google
Cocher « Enable »
Coller Client ID et Client Secret obtenus à l’étape 1
Save

Étape 3 — Frontend JS

import PocketBase from "pocketbase";
const pb = new PocketBase("https://api.exemple.sn");

// Récupérer la liste des providers configurés
const methods = await pb.collection("users").listAuthMethods();
const googleProvider = methods.authProviders.find((p) => p.name === "google");

// Construire l'URL d'autorisation
const redirectUrl = "https://app.exemple.sn/oauth-callback";
const authUrl = googleProvider.authUrl + redirectUrl;

// Rediriger l'utilisateur
window.location.href = authUrl;

Étape 4 — Page de callback

// /oauth-callback page
import PocketBase from "pocketbase";
const pb = new PocketBase("https://api.exemple.sn");

const params = new URLSearchParams(window.location.search);
const code = params.get("code");
const state = params.get("state");

// Récupérer le provider Google
const methods = await pb.collection("users").listAuthMethods();
const provider = methods.authProviders.find((p) => p.name === "google");

// Échanger le code contre une session
const authData = await pb.collection("users").authWithOAuth2Code(
  "google",
  code,
  provider.codeVerifier,
  "https://app.exemple.sn/oauth-callback",
);

console.log("Connecté :", authData.record);
window.location.href = "/dashboard";

Étape 5 — Flow simplifié authWithOAuth2

Pour un flow encore plus simple en frontend SPA, le SDK propose authWithOAuth2 qui ouvre un popup et gère tout :

const authData = await pb.collection("users").authWithOAuth2({
  provider: "google",
});

if (authData) {
  console.log("Connecté :", pb.authStore.model);
}

Étape 6 — Apps mobiles (React Native, Flutter)

Pour les apps mobiles, utilisez un deep link comme redirect URL (monapp://oauth) et un browser tab in-app pour le flow OAuth. Le SDK Pocketbase Flutter et React Native gère ça nativement.

Étape 7 — Email de l’utilisateur

Par défaut Pocketbase crée automatiquement un compte users avec l’email Google de l’utilisateur. Il considère que cet email est déjà vérifié (Google le valide déjà), donc pas d’envoi de mail de vérification.

Si vous avez déjà un compte créé manuellement avec le même email, Pocketbase associe automatiquement les deux à la première connexion OAuth.

Adaptation Afrique de l’Ouest

Le Sign-in with Google fonctionne identiquement depuis tous pays CEDEAO. Pour vos utilisateurs sénégalais ou ivoiriens, c’est même particulièrement utile car beaucoup ont un compte Gmail ou Workspace mais pas forcément un compte dédié à votre app.

Erreurs fréquentes

Erreur	Cause	Solution
« redirect_uri_mismatch »	URL pas dans Authorized URIs	Ajouter exactement la même URL côté Google Cloud
OAuth consent app non vérifiée	Mode test Google par défaut	Soumettre app pour vérification ou rester en test (max 100 users)
Popup bloquée	navigator	authWithOAuth2 doit être lancé en réponse à un user gesture (clic)
Email non disponible	Scope manquant	Cocher « email » et « profile » dans OAuth consent

Pourquoi PocketBase + OAuth Google en 2026

Quand on construit une application web pour le marche ouest-africain, on jongle entre deux contraintes : un budget hebergement serre (souvent moins de 5 EUR / mois, soit autour de 3 280 FCFA) et un besoin d’authentification sociale qui rassure l’utilisateur final. Google reste le fournisseur d’identite le plus universel : un compte Gmail ouvre les portes a presque tout l’ecosysteme Android utilise massivement de Dakar a Abidjan. PocketBase, distribue en binaire Go unique, repond pile a la premiere contrainte. Couple a OAuth 2.0 Google, il fournit une base auth pro sans backend custom.

L’objectif de ce tutoriel : monter de zero une instance PocketBase 0.22+ sur un VPS modeste, connecter le provider Google, generer le client OAuth dans Google Cloud Console, et tester le flow end-to-end depuis un front Vanilla JS. Apres ces 8 etapes, vous disposerez d’un endpoint /api/collections/users/auth-with-oauth2 fonctionnel, avec gestion automatique du compte (creation au premier login, fusion si email deja present).

Etape 1 : Preparer le VPS et le domaine

Avant toute chose, il faut un VPS Linux (Ubuntu 24.04 LTS recommande, 1 vCPU, 1 Go RAM suffit) et un nom de domaine pointe en A record sur l’IP publique. Pour un projet base au Senegal, un VPS Hetzner CX22 a environ 4,90 EUR / mois (~3 215 FCFA) reste le meilleur rapport qualite-prix latence vers l’Europe. Verifions que le DNS est bien propage avant d’aller plus loin.

dig +short auth.example.com

La sortie attendue est l’IP V4 de votre VPS. Si la commande renvoie vide, attendez 5 a 10 minutes la propagation DNS. Tant que cette etape n’est pas verte, inutile de demander un certificat TLS : Let’s Encrypt echouera au challenge HTTP-01.

Etape 2 : Telecharger et lancer PocketBase

PocketBase se distribue en binaire statique Go. Pas de runtime Node, pas de Python, pas de container : un seul executable et un dossier pb_data/. On telecharge la derniere release stable (0.22.x au moment de la redaction) directement depuis GitHub.

cd /opt
wget https://github.com/pocketbase/pocketbase/releases/download/v0.22.21/pocketbase_0.22.21_linux_amd64.zip
unzip pocketbase_0.22.21_linux_amd64.zip
chmod +x pocketbase
./pocketbase serve --http=0.0.0.0:8090

La sortie attendue affiche Server started at http://0.0.0.0:8090 et une URL d’admin avec un token a usage unique pour creer le premier superadmin. Ouvrez cette URL dans votre navigateur, choisissez un email et un mot de passe robuste : c’est ce compte qui permettra ensuite de gerer les collections et les providers OAuth.

Etape 3 : Mettre PocketBase en service systemd derriere Caddy

Lancer PocketBase a la main suffit pour tester, mais en production il faut un service qui redemarre automatiquement et un reverse proxy avec TLS. On utilise systemd pour la persistence et Caddy pour le HTTPS automatique (Let’s Encrypt integre, zero config).

sudo tee /etc/systemd/system/pocketbase.service <<'EOF'
[Unit]
Description=PocketBase
After=network.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/opt
ExecStart=/opt/pocketbase serve --http=127.0.0.1:8090
Restart=always

[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now pocketbase

Verifiez avec systemctl status pocketbase : la mention active (running) confirme le demarrage. Pour Caddy, un Caddyfile minimaliste suffit : auth.example.com { reverse_proxy 127.0.0.1:8090 }. Caddy negocie le certificat TLS en moins de 30 secondes au premier demarrage.

Etape 4 : Creer le client OAuth dans Google Cloud Console

Direction console.cloud.google.com. Creez un projet dedie (par exemple « auth-pocketbase-prod »), puis allez dans APIs & Services > OAuth consent screen. Choisissez « External », remplissez le nom de l’app, l’email de support et le domaine autorise (votre example.com). Ajoutez les scopes openid, email, profile : ce sont les seuls necessaires pour PocketBase.

Ensuite, Credentials > Create credentials > OAuth client ID > Web application. Le champ critique est « Authorized redirect URIs » : indiquez exactement https://auth.example.com/api/oauth2-redirect. Une URL incorrecte (slash final, http au lieu de https, sous-domaine different) provoque l’erreur redirect_uri_mismatch au moment du callback. Notez le Client ID et le Client Secret affiches : on les colle dans PocketBase a l’etape suivante.

Etape 5 : Configurer le provider Google dans PocketBase

Connectez-vous a l’admin PocketBase, allez dans Settings > Auth providers > Google. Activez le toggle, collez le Client ID et le Client Secret. Sauvegardez. Testez immediatement le bouton « Test » si disponible : il declenche un flow OAuth complet et remonte une erreur claire en cas de mauvaise config (scope manquant, redirect URI invalide).

Verifiez aussi que la collection users a bien le champ email en non-unique=false et que verified est gere automatiquement par le flow OAuth (Google fournit deja un email verifie). Si vous comptez fusionner les comptes existants email/password avec ceux Google, activez l’option « Create new auth users on every OAuth login » sur OFF.

Etape 6 : Implementer le bouton « Sign in with Google » cote front

Le SDK JS officiel de PocketBase gere tout le flow OAuth en une seule methode. Pas besoin de jongler avec les state, code_verifier ou PKCE : le SDK les genere correctement. Voici le snippet complet pour un front Vanilla JS.

import PocketBase from 'pocketbase';
const pb = new PocketBase('https://auth.example.com');

document.getElementById('google-btn').addEventListener('click', async () => {
  try {
    const authData = await pb.collection('users').authWithOAuth2({ provider: 'google' });
    console.log('User connecte :', authData.record.email);
    window.location.href = '/dashboard';
  } catch (err) {
    console.error('Echec OAuth :', err);
    alert('Connexion Google impossible. Reessayez.');
  }
});

Le SDK ouvre une popup vers Google, attend le callback, recupere le token et l’enregistre dans pb.authStore. Le retour authData.record contient l’utilisateur PocketBase pret a l’emploi. La redirection vers /dashboard se declenche uniquement si le flow a reussi.

Etape 7 : Securiser le authStore et le rate limiting

Par defaut, pb.authStore persiste le token dans localStorage. C’est commode mais expose au XSS. En production, deux mesures concretes : activer une CSP stricte (Content-Security-Policy) qui bloque l’inline script, et limiter le rate sur l’endpoint OAuth pour eviter le brute-force des state parameters. PocketBase 0.22 expose un middleware natif a configurer dans pb_hooks/main.pb.js.

onRecordAuthWithOAuth2Request((e) => {
  const ip = e.httpContext.realIP();
  // log + throttle ici
  console.log('OAuth tentative depuis', ip);
})

Cette hook s’execute a chaque appel auth-with-oauth2. Vous pouvez y brancher un compteur Redis ou simplement un Map en memoire pour bloquer les IP suspectes. La sortie console s’affiche dans les logs systemd via journalctl -u pocketbase -f.

Etape 8 : Tester le flow et debugger les erreurs courantes

Trois erreurs reviennent systematiquement quand on integre OAuth Google pour la premiere fois. Erreur 1 : redirect_uri_mismatch. Cause : l’URL declaree dans Google Cloud Console differe d’un caractere de celle envoyee par PocketBase. Solution : copier-coller exact depuis l’admin PocketBase > Settings > Auth providers > Google > Redirect URL.

Erreur 2 : invalid_client. Cause : le Client Secret a ete regenere ou mal copie (espaces invisibles). Solution : regenerer le secret cote Google et le re-coller. Erreur 3 : popup bloquee par le navigateur. Cause : le clic n’est pas un user gesture direct (par exemple appel asynchrone avant authWithOAuth2). Solution : appeler la methode immediatement dans le handler click.

À lire ensuite, consultez notre tutoriel PocketBase vs Firebase vs Supabase : comparatif honnete 2026 et le guide Forgejo Actions CI/CD pour automatiser les deploiements de votre instance PocketBase.

Annexe : sauvegarde et migration du dossier pb_data

Tout l’etat de votre instance PocketBase tient dans un seul dossier : pb_data/. Sauvegarder ce dossier suffit a restaurer integralement les utilisateurs, les tokens OAuth, les collections et les settings. La routine recommandee : un cron quotidien qui zip le dossier et l’envoie sur un stockage S3-compatible (Scaleway Object Storage Paris pour rester proche de l’Afrique de l’Ouest, ou Backblaze B2 pour le tarif).

0 3 * * * cd /opt && tar czf /tmp/pb_$(date +\%Y\%m\%d).tar.gz pb_data && aws s3 cp /tmp/pb_*.tar.gz s3://mon-bucket/pocketbase/ --endpoint-url https://s3.fr-par.scw.cloud

Sortie attendue : aucun message d’erreur, et un fichier .tar.gz visible dans le bucket Scaleway. Pour la migration vers un autre VPS, il suffit de stopper PocketBase, de copier pb_data/ via rsync, et de relancer le service. Aucune migration de schema, aucun dump SQL : c’est l’un des avantages cles face a Postgres.

Annexe : passer en multi-region avec Litestream

PocketBase utilise SQLite. Pour ceux qui veulent une replication continue vers un second VPS (par exemple Paris + Abidjan), Litestream streame les WAL SQLite vers un bucket S3 toutes les secondes. En cas de crash du primaire, on relance PocketBase sur le secondaire avec litestream restore et l’application repart en moins de deux minutes. Le cout : negligeable, Litestream est gratuit et open-source.

Configuration minimale dans /etc/litestream.yml : un bloc dbs pointant sur /opt/pb_data/data.db et une replica S3. Lancez litestream replicate en service systemd a cote de PocketBase. Surveillez les logs : un message sync ok toutes les secondes confirme que la replication tourne.

FAQ rapide PocketBase OAuth Google

Combien d’utilisateurs supporte une instance PocketBase sur un VPS 1 vCPU ? En usage authentification + lectures simples, on tient confortablement 5 000 utilisateurs actifs mensuels avec moins de 200 Mo de RAM consommee. Au-dela, passez sur 2 vCPU et activez Litestream pour la replication.

Peut-on combiner OAuth Google et email/password ? Oui, PocketBase gere les deux methodes sur la meme collection users. La fusion se fait automatiquement sur l’email si l’option est activee. Attention au phishing : un attaquant qui possede l’email pourrait theoriquement lier son compte Google a un compte existant.

Le binaire PocketBase fonctionne-t-il sur ARM (Raspberry Pi, Oracle Free Tier ARM64) ? Oui, des builds linux_arm64 sont disponibles sur la page releases GitHub. Performances comparables a x86 pour cet usage.