第三章：台灣接案必備武器：Line Login 開發者後台申請與 Callback 串接

在上一章中，我們成功攻克了 Google 登入。但在台灣、日本與東南亞的商業環境中，幾乎沒有任何一個 B2C (企業對消費者) 的專案是可以跳過 Line 登入 的。

客戶一定會這樣要求你：「我要讓客人點一下就登入，不要叫他們記密碼！台灣人每支手機都有 Line 啦！」這句話背後的商業價值是驚人的：如果你成功引導使用者用 Line 登入你的網站，你不但能獲得他的基本資料，還能直接與你的 Line 官方帳號 (Line Official Account) 綁定。一旦綁定成功，你未來就能透過 Line Messaging API 直接發送「客製化的促銷訊息」到他的手機裡，跳出推播通知！這就是現代化 SaaS 平台最強大的行銷武器。

本章我們將手把手帶你闖關 Line Developers 開發者後台，並將 Line 登入優雅地融合進我們原有的 Auth.js 架構中。

🟢 步驟一：Line Developers 後台闖關指南

與 Google Cloud Console 的企業級介面不同，Line 的後台相對簡單，但裡面藏了很多隱藏的地雷。

1. 建立 Provider (開發商/公司名稱)

前往 LINE Developers Console 並登入你的個人 Line 帳號。
點擊 Providers 旁邊的 Create 按鈕。 (註：Provider 的概念就等於「開發這支程式的公司或團隊名稱」，例如 `VibeTutor Inc.`。這個名稱會出現在使用者的授權畫面上，所以請填寫真實且專業的名稱)。

2. 建立 LINE Login Channel

一個 Provider 底下可以擁有多個 Channel (例如一個是 Login，一個是 Messaging API 機器人)。

點擊剛建好的 Provider，選擇 「Create a new channel」。
選擇 「LINE Login」。
開始填寫資料：
- Channel type: LINE Login
- Provider: VibeTutor Inc.
- Region to provide the service: 選擇 Taiwan 或 Global。
- Channel icon: 強烈建議上傳，這是給使用者的第一印象。
- Channel name: 填入 `VibeTutor 官網登入`。
- Channel description: 填寫簡單的服務介紹。
- App types: 勾選 `Web app` (我們是網頁登入，千萬不要勾選 Native app)。
勾選同意條款後，點擊 Create 建立。

3. 取得通關密鑰 (Channel ID & Secret)

建立成功後，你會來到 Channel 的總覽頁面。在 Basic settings 標籤頁往下滾動，你會看到兩個極度重要的資訊：

Channel ID：請複製它，它等於 OAuth 裡的 Client ID。
Channel secret：請複製它，它等於 OAuth 裡的 Client Secret。

4. 設定回呼網址 (Callback URL)

在上一章我們學過，當使用者在 Line 登入成功後，Line 需要知道要把「授權碼 (Auth Code)」丟到哪個網址給我們。

切換到 LINE Login 標籤頁。
找到 Web app 區塊，點擊 Callback URL 旁邊的 Edit。
填入 Auth.js 預設的死板路徑： 👉 `http://localhost:3000/api/auth/callback/line` (🚨 注意：未來部署到 Vercel 時，務必回來這裡加上正式網域的 URL)
點擊 Update 儲存。

5. 終極魔王關：發布 (Publish) 你的 Channel

這是 99% 的新手都會卡關 的地方！在網頁的最上方，你會看到一個標籤寫著 `Developing` (開發中)。只要維持在這個狀態，除了你自己的 Line 帳號以外，全世界的人點擊登入都會跳出錯誤畫面！

請點擊 `Developing` 標籤，然後勇敢地按下 `Publish`。
狀態變成 `Published` 後，你的登入功能才算是真正上線了。

📧 步驟二：Line Email 取得權限申請 (特殊坑點)

與 Google 非常不同的一點是：Line 預設絕對不會把使用者的 Email 交給你！ 它只會給你使用者的名字 (displayName) 和大頭貼 (pictureURL)。

如果你的網站非常需要 Email 作為系統的唯一識別碼（例如你需要發送收據或重設密碼），你必須主動向 Line 申請。

在 Basic settings 標籤頁，滾動到最底部。
找到 Email address permission。
點擊 `Apply` 或 `Request`。
系統會要求你上傳一張截圖，證明你的網站有在某個地方提醒使用者你會收集 Email（你可以截圖你網站的隱私權政策 Policy）。
提交審核。通常如果是正常的應用程式，審核通過率極高。

⚠️ Vibe Coding 注意事項： 如果你沒有申請到這個權限，等等我們在 Auth.js 裡面強制索取 Email 時，Line 會直接報錯拒絕連線！如果你不需要 Email，只是需要使用者的 Line ID (Profile Subject) 來辨識身分，那你可以跳過這一步。

💻 步驟三：整合 Line Provider 到 Auth.js

好了，後台設定完畢，回到我們熟悉的程式碼世界。

1. 更新環境變數 (.env.local)

把你剛才複製下來的 Line 雙寶貼上去：

```env

既有的 Google 憑證...

AUTH_GOOGLE_ID="12345..." AUTH_GOOGLE_SECRET="GOCSPX-..."

新增 Line OAuth 憑證

AUTH_LINE_ID="你剛才複製的_Channel_ID" AUTH_LINE_SECRET="你剛才複製的_Channel_Secret" ```

2. 更新核心設定檔 (src/auth.ts)

打開 `src/auth.ts`，把 LineProvider 加進去陣列中。你會發現 Auth.js 的架構美得令人窒息，要新增一個登入方式，真的只要幾行字：

```typescript import NextAuth from "next-auth" import GoogleProvider from "next-auth/providers/google" import LineProvider from "next-auth/providers/line" // 引入 Line

export const { handlers, signIn, signOut, auth } = NextAuth({ providers: [ GoogleProvider({ clientId: process.env.AUTH_GOOGLE_ID, clientSecret: process.env.AUTH_GOOGLE_SECRET, }), LineProvider({ clientId: process.env.AUTH_LINE_ID, clientSecret: process.env.AUTH_LINE_SECRET,

  // 🚨 如果你剛剛沒有申請 Email 權限，這裡絕對不要加入額外的 scope 要求
  // 預設它只會要 'profile' 和 'openid'
  
  // 🚨 特殊地雷：OIDC 的防護機制
  // Auth.js 升級到 v5 之後嚴格遵守 OIDC 規範，Line API 回傳的 state 有時會有相容性問題
  // 如果你在點擊登入時遇到 state 錯誤，請解除註解以下這行：
  // checks: ["state"], 
}),

], }) ```

3. 測試雙位一體的登入畫面！

確保你的 `npm run dev` 伺服器正在運行。打開瀏覽器，手動輸入網址：`http://localhost:3000/api/auth/signin`

見證奇蹟的時刻到了！你的極簡登入畫面上，現在出現了兩顆按鈕：

Sign in with Google
Sign in with LINE

點擊 Line 登入，畫面會自動跳轉到 Line 的綠色授權畫面。如果你是在手機上點擊，它甚至會直接打開你手機裡的 Line App 進行免密碼授權！授權成功後，完美跳回你的 `localhost`。

🤝 商業進階題：Account Linking (帳號綁定) 的挑戰

當你同時提供兩種以上的登入方式時，身為架構師的你，立刻要面臨一個極度棘手的商業邏輯挑戰：

情境模擬： 小明昨天用 `ming@gmail.com` 點了「使用 Google 登入」，在你的網站上買了一堂課。今天小明換了一台手機，他忘了昨天是用什麼登入的，於是點了「使用 Line 登入」。剛好，他的 Line 綁定的 Email 也是 `ming@gmail.com`。

問題來了： 你的系統應該要把這兩次登入視為「同一個小明」，還是「兩個不同的小明」？

如果視為不同的人，小明登入後會氣瘋，因為他買的課不見了。
如果系統擅自把他們合併，可能會有資安風險（如果有人偽造了信箱）。

這個問題在業界被稱為 Account Linking (帳號綁定)。

幸運的是，在我們準備使用的 Supabase Adapter 架構下，它預設的行為邏輯是： 「不同的 Provider，只要是同一個 Email，系統會拒絕自動合併，除非使用者明確同意，以防止帳號劫持攻擊。」 要處理這種複雜的 Account Linking，你需要一個強大的關聯式資料庫。這就是我們下一章的重頭戲：拋棄 Cookie Session，全面擁抱 Supabase PostgreSQL 資料庫的 Adapter 對接實戰！