Fonctionnalités · Connexion et e-mail

Connexion avec sans Google Cloud.

« Continuer avec Google » et connexion par e-mail pour les personnes qui utilisent votre application — aucun projet Google Cloud, aucun client OAuth, aucune clé. Les e-mails de création de compte partent au nom de votre application, depuis votre propre domaine dès que celui-ci est vérifié.

Lire la documentationConfigurer l’agent

Ce que votre agent appelle

  • appAuthConfigure
  • appAuthStatus
  • appAuthEmailConnect
  • appAuthEmailStatus
claude · ~/franks-kitchenexemple

Let staff sign in with Google

Update(app/login/page.tsx)

1 line · Google button → TOFU_SIGN_IN_URL

Write(app/auth/confirm/route.ts)

new route · verifyOtp for the email link

tofu · appAuthConfigure confirmed: true

configured · Google sign-in, and email sign-in as well

Comment fonctionne la connexion Google

Tofu parle à Google, pour que votre application n’ait pas à le faire.

Le relais de Tofu sur oauth.trytofu.ai possède un seul client Google et une seule adresse de rappel permanente. Votre application y envoie le navigateur ; le relais authentifie la personne auprès du service d’authentification de votre application — le projet Supabase derrière sa base de données gérée.

E-mail de création de compte

L’e-mail de création de compte, au nom de votre application.

La connexion par e-mail est activée à la même étape, pour qu’un compte garde toujours un moyen de se reconnecter si une connexion tierce devient indisponible.

Le service d’authentification de votre application envoie ses e-mails (confirmation, magic-link, password-reset, invitation, address-change et reauthentication) via la configuration e-mail de Tofu, avec le nom de votre application comme expéditeur. Aucun mot de passe SMTP, aucun fournisseur d’e-mail auprès duquel s’inscrire.

Chaque message contient un code à usage unique en plus d’un lien : sinon, les analyseurs de messagerie qui ouvrent les liens en premier consommeraient le jeton avant votre utilisateur.

Depuis votre domaine

Six enregistrements DNS, aucun à la racine de votre domaine.

Une fois votre domaine connecté, appAuthEmailConnect crée une identité d’envoi pour send.frankskitchen.com et publie ses enregistrements — tous sous send., pour ne pas toucher aux e-mails que votre domaine reçoit déjà. Supprimez-les, et le domaine est exactement comme avant.

TypeNom, dans frankskitchen.comValeur
CNAME‹token 1›._domainkey.send‹token 1›.dkim.amazonses.com
CNAME‹token 2›._domainkey.send‹token 2›.dkim.amazonses.com
CNAME‹token 3›._domainkey.send‹token 3›.dkim.amazonses.com
MX 10bounce.sendfeedback-smtp.‹region›.amazonses.com
TXTbounce.sendv=spf1 include:amazonses.com ~all
TXT_dmarc.sendv=DMARC1; p=none; rua=mailto:…

Avec l’autorisation Cloudflare dont votre connexion de domaine dispose déjà, Tofu les écrit lui-même — sans seconde autorisation. Ailleurs, il vous les liste à ajouter et demande au fournisseur d’e-mail de les vérifier.

Tant que le fournisseur d’e-mail ne signale pas le domaine comme vérifié, les e-mails continuent de partir de notify.trytofu.app — la création de compte ne s’arrête jamais pendant l’attente.

La seule route qui appartient à votre application

Un lien qu’un analyseur ne peut pas consommer.

Chaque message pointe vers /auth/confirm sur l’adresse de votre application, et le jeton n’est consommé que lorsque votre application appelle verifyOtp — un analyseur qui ouvre le lien en premier atteint donc votre application, pas le service de connexion.

Une nouvelle application créée avec la skill /tofu reçoit cette route ; votre agent l’écrit. Une application déployée sans cette route permet quand même aux personnes de se connecter avec le code présent dans chaque message.

app/auth/confirm/route.tsnext.js
import { createClient } from '@/lib/supabase/server';
import { NextResponse } from 'next/server';

export async function GET(request) {
  const { searchParams, origin } = new URL(request.url);
  const token_hash = searchParams.get('token_hash');
  const type = searchParams.get('type');
  if (token_hash && type) {
    const supabase = await createClient();
    const { error } =
      await supabase.auth.verifyOtp({ type, token_hash });
    if (!error) return NextResponse.redirect(`${origin}/`);
  }
  return NextResponse.redirect(`${origin}/login?error=link`);
}

Bientôt disponible.

  • L’écran de consentement affiche le nom de Tofu. Google affiche le nom vérifié du client par lequel la connexion passe : les personnes lisent donc « continuer vers Tofu ». Votre propre nom à cet endroit exige votre propre client Google, qui n’est pas développé.

  • Uniquement avec une base de données gérée par Tofu. La connexion est configurée dans le service d’authentification derrière la base de données gérée de votre application. Une application sur Clerk, Auth0 ou son propre projet Supabase reste exactement telle quelle.

  • Google et e-mail, rien d’autre. Pas de connexion GitHub ou Apple pour les utilisateurs de votre application.

  • Les e-mails de connexion, pas les autres e-mails de votre application. Tofu envoie les messages de connexion et de création de compte ; les reçus, les notifications et tout ce que votre application envoie par ailleurs ne passent pas par Tofu.

  • Un expéditeur à votre nom exige votre propre domaine. Le domaine doit d’abord être connecté à l’application ; tant qu’il n’est pas vérifié, les e-mails partent de noreply@notify.trytofu.app.

  • L’expéditeur sur votre domaine est la partie la plus récente. Ses enregistrements, sa vérification et le changement d’expéditeur ont fonctionné de bout en bout sur le projet de test de Tofu, pas encore sur l’application d’un client.

Collez un prompt. En ligne en 10 minutes.

Votre application, sa base de données, votre domaine et votre connexion — avec l’agent que vous utilisez déjà, en 10 minutes environ.

Commencer gratuitement