Next.js でユーザー認証を実装するとき、**Magic Link** と **OAuth** のどちらを選ぶかで開発工数やユーザー体験が大きく変わります。初心者でも判断しやすいように、5つの観点で比較してみましょう。
## 1. ユーザー体験（UX）
- **Magic Link** はメールアドレスだけでサインインでき、パスワード入力が不要です。初回登録のハードルが低く、特に B2C 向けのシンプルなサービスに向いています。
- **OAuth** は Google や GitHub など外部プロバイダーのアカウントを利用します。既に使い慣れたアカウントでログインできるので、リピート利用者が多い場合に便利です。
## 2. 実装コスト
- **Magic Link** はメール送信ロジックとトークン管理だけで完結します。NextAuth.js の `Email` プロバイダーを使えば数行で設定可能です。
- **OAuth** は各プロバイダーごとにクライアント ID／シークレットの取得やスコープ設定が必要です。設定項目が増える分、ドキュメントを読む手間がかかります。
## 3. セキュリティ
- **Magic Link** は「使い捨て」トークンをメールで送るため、トークンが漏洩した場合は有効期限が短くリスクは限定的です。ただし、メールアカウント自体が乗っ取られると危険です。
- **OAuth** はプロバイダー側で多要素認証や不正検知が行われるため、比較的安全です。逆に、プロバイダーがサービス停止したら認証も止まります。
## 4. メンテナンス性
- **Magic Link** は自前のメールテンプレートや送信サービス（SendGrid, SES など）を管理する必要があります。メール配信の障害対応が増えることも。
- **OAuth** はプロバイダーが認証フローを提供してくれるので、認証ロジックの変更はほとんどありません。プロバイダー側の API 変更だけを追うだけで済みます。
## 5. 将来の拡張性
- **Magic Link** は基本的に「メールアドレス」だけの認証です。将来的に SNS アカウントや SSO を追加したい場合は、別途実装が必要です。
- **OAuth** は複数プロバイダーを同時に設定でき、後から追加しやすい構造です。企業向けに Azure AD や Okta などを組み込むことも容易です。
### 実装例（NextAuth.js）
以下は Next.js アプリに **Magic Link** と **Google OAuth** の両方を組み合わせた設定例です。`pages/api/auth/[...nextauth].ts` に配置します。
```ts
import NextAuth from "next-auth";
import EmailProvider from "next-auth/providers/email";
import GoogleProvider from "next-auth/providers/google";
export default NextAuth({
providers: [
// Magic Link
EmailProvider({
server: process.env.EMAIL_SERVER, // 例: SMTP URL
from: process.env.EMAIL_FROM,
}),
// Google OAuth
GoogleProvider({
clientId: process.env.GOOGLE_CLIENT_ID,
clientSecret: process.env.GOOGLE_CLIENT_SECRET,
}),
],
// 簡易的にデータベースは省略。実運用では DB へ保存推奨
secret: process.env.NEXTAUTH_SECRET,
});
この設定だけで、/api/auth/signin にアクセスすれば「メールで Magic Link を送る」ボタンと「Google でサインイン」ボタンが自動生成されます。初心者でも「どちらが自分のプロダクトに合うか」を実際に試しながら判断できるでしょう。
まとめ
- ユーザー層がパスワードに抵抗があるなら Magic Link が有効。
- 既存の SNS アカウントを活用したい、または企業向けに SSO を検討中なら OAuth が適しています。
- 開発リソースや将来の拡張計画を踏まえて、どちらか一方、もしくは両方を併用する選択肢も検討してください。