🏗️ Architecture: How should 2FA be implemented — Twilio Verify managed servic...

Date: 2026-03-27
Time: 18:02:36 UTC
Session: gspace1-280.3
Agent: angular
Confidence: 93%
Status: ✅ Documented

📋 Decision Context

Question:

How should 2FA be implemented — Twilio Verify managed service vs fully in-house?

Task: Not specified

🎯 Decision Made

Chosen:

Fully in-house: existing TwilioService (SMS/WhatsApp) + EmailService (SendGrid) + Redis OTP store + otplib for TOTP. Zero new vendor dependencies.

Options Considered:

1. Twilio Verify for all channels
2. Hybrid: Twilio Verify for SMS/email + otplib for TOTP
3. Fully in-house with existing infrastructure

💭 Reasoning

All building blocks already exist: TwilioService for SMS/WhatsApp delivery, EmailService for email delivery, RedisService for persistent OTP store, AES-256-GCM encryption (OAuthService + SecretVaultService patterns), JwtService for trusted device tokens. The gap is ~300 lines of orchestration, not infrastructure. Twilio Verify at $0.05/verification adds vendor dependency for a security-critical path with no meaningful benefit at ~50 privileged users. TOTP must be local (otplib) because authenticator apps work offline — routing validation through external API defeats the purpose.

📁 Files Involved

• libs/libs-api/messaging-core/src/lib/services/twilio.service.ts
• libs/libs-api/messaging-core/src/lib/services/email.service.ts
• libs/libs-api/backend-core/src/lib/redis/redis.service.ts
• APIs/backend-api/src/app/auth/phone-auth.service.ts
• docs/superpowers/specs/2026-03-27-two-factor-authentication-design.md

🔗 Related

• Decision ID: dev_1774634556674_wsdrapr
• Session: 280
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation