如何為你的應用程式加入登入功能：密碼、魔術連結、Google 與角色

要為應用程式加入登入功能，請先選擇一種方式：電子郵件與密碼、魔術連結（透過電子郵件寄送的一次性登入連結），或「使用 Google 登入」。然後使用經過驗證的驗證函式庫或託管服務來實作，而不是從頭自己寫。接著決定每一類使用者可以做什麼（角色），並在每個頁面與 API 請求中都在伺服器端強制執行。工作階段應該使用安全的 Cookie、會過期，並在登出時正確結束。

本指南逐一說明每種選擇，以及區分「能運作的登入」與「安全的登入」的細節。想了解背後的概念，請參閱什麼是身分驗證。

先決定：你真的需要登入嗎？

登入會增加使用門檻，也會帶來責任。以下情況才需要：

• 使用者有私人資料（他們的預約、文件、發票）
• 使用者能變更其他人會看到的內容
• 你收費才提供存取權
• 不同的人需要不同的權限（擁有者、員工、客戶）

行銷網站、公開目錄，或只會寄一封電子郵件給你的表單，不需要登入。候補名單不需要帳號，一個電子郵件欄位就夠了。

四種常見的登入方式

許多應用程式會結合兩種方式：Google 登入加上電子郵件魔術連結，是很受歡迎的搭配，能涵蓋大多數人，又不需要儲存任何密碼。

電子郵件與密碼

如果你提供密碼登入，以下幾點是不可妥協的：

• 使用緩慢的密碼雜湊演算法。 OWASP 的密碼儲存指引建議使用 Argon2id，並以 scrypt、bcrypt 或 PBKDF2 作為替代。絕不要以明文或快速的通用雜湊來儲存密碼。
• 密碼重設使用隨機、一次性且會過期的連結，寄到已驗證的電子郵件。
• 不要透露哪些電子郵件有帳號。 「如果此電子郵件已註冊，我們已寄出重設連結」比「找不到帳號」更好。
• 對登入與重設嘗試進行速率限制，以減緩密碼猜測攻擊。
• 允許長密碼與密碼管理器；不要強制使用奇怪的字元組合規則。

魔術連結與一次性驗證碼

魔術連結是寄給使用者的登入連結，點擊後即可登入。一次性驗證碼的概念相同，只是改為輸入而非點擊。

• 連結與驗證碼應很快過期，且只能使用一次。
• 連結應該在使用者點擊的那台裝置上完成登入，而且權杖不能留在日誌或分析工具中。
• 你需要可靠的電子郵件寄送功能，請參閱如何從應用程式寄送電子郵件。請用 Gmail 和 Outlook 測試，並檢查垃圾郵件匣。

使用 Google 登入（以及其他 OAuth 服務）

「使用 Google 登入」使用的是 OAuth 與 OpenID Connect：Google 確認使用者的身分，並把他們的電子郵件和姓名告訴你的應用程式。截至 2026 年 9 月，設定步驟在 Google Cloud Console 的 Google Auth Platform 區段中進行：

1. 建立或選擇一個專案，並填寫品牌塑造頁面，也就是使用者在同意畫面上看到的內容（應用程式名稱、支援電子郵件、標誌）。
2. 在用戶端頁面，建立類型為「網頁應用程式」的用戶端。
3. 新增你的已授權 JavaScript 來源與重新導向 URI：也就是你的應用程式實際運行的位址，以及登入後 Google 會把使用者送回的位址。
4. 把用戶端 ID 與用戶端密鑰存在應用程式的機密中。

根據 Google 的 OAuth 文件，以下是常見的問題：

• redirect_uri_mismatch：重新導向位址必須完全相符，包括 http 與 https、大小寫，以及結尾是否有斜線。請同時為你的預覽位址與正式網域各新增一個。
• 必須使用 HTTPS：重新導向 URI 必須使用 HTTPS，但在開發時的 localhost 例外。
• 應檢查 state 參數，於返回時檢查，以防止跨站請求偽造。好的函式庫會自動幫你做這件事。

如果你只要求基本的登入資訊（姓名、電子郵件、個人資料），Google 表示應用程式驗證並非強制。但要求存取使用者的 Gmail、雲端硬碟或日曆則不同，需要通過驗證。

自己建置還是使用服務？

前兩種都是合理的選擇。託管服務幫你處理更多事情，但會增加一項依賴，有時還會依活躍使用者收費；請在其官網查看目前的定價。函式庫讓所有資料都留在你的資料庫中，但需要你自己正確設定更多細節。不論選擇哪一種，都請讓 AI 使用它，而不是自行手寫密碼或工作階段的邏輯。

角色與權限

登入告訴你「誰」是使用者，權限則決定他「能做什麼」。一開始保持簡單：

比角色名稱更重要的規則：

• 每次都在伺服器端檢查。 在頁面中隱藏按鈕，無法阻止有人直接呼叫 API。
• 依擁有者限定範圍。 會員要求取「預約 123」時，只有當它屬於他時才應該回傳。
• 使用者不能自行升級權限。 在更新個人資料時，忽略從瀏覽器送來的角色欄位。
• 預設為無存取權。 新的路由應該要求登入，除非你明確決定不需要。

用兩個帳號測試：以其中一個帳號登入，記下某筆紀錄的 ID，再以另一個帳號登入並嘗試開啟它。我們的安全檢查清單包含完整的測試。

工作階段安全

登入後，應用程式會透過工作階段（通常是 Cookie）記住使用者。OWASP 的工作階段管理指引建議：

• 工作階段 Cookie 設定 Secure（僅限 HTTPS）、HttpOnly（頁面腳本無法讀取）與 SameSite
• 登入時發出新的工作階段 ID，權限變更時也要再發一次
• 在伺服器上強制執行閒置逾時與絕對最長存續時間
• 登出時在伺服器上結束工作階段，而不只是刪除 Cookie
• 使用者變更密碼時，工作階段失效

教學中常見把登入權杖存在瀏覽器的 local storage 裡，但這會讓任何在頁面上執行的腳本都能讀取它們；對網頁應用程式來說，安全的 Cookie 通常是更好的預設選擇。

涵蓋基本要點的提示詞

為這個應用程式加入使用者帳號。使用者可以用電子郵件與密碼註冊與登入，或使用 Google 登入。請使用 [函式庫或服務] 而非自行撰寫的驗證程式碼。使用 Argon2id 或 bcrypt 對密碼進行雜湊。加入透過電子郵件進行的密碼重設，使用一次性連結，並在一小時後過期。把工作階段保存在安全的 HttpOnly Cookie 中。保護 /dashboard 以及每一個 /api 路由，只有已登入的使用者可以使用，並確保使用者只能看到自己的專案。新增「admin」角色，可以查看所有使用者；只有管理員能進入 /admin，並在伺服器端檢查。

然後進行測試：註冊、登出、登入、重設密碼，在未登入時嘗試開啟私人網址，並嘗試開啟其他使用者的紀錄。

AI 製作的登入中常見的錯誤

• 只在頁面上保護。 頁面會把未登入的使用者重新導向，但 API 仍會把資料回傳給任何人。
• 機密放在瀏覽器中。 OAuth 用戶端密鑰與驗證服務的管理金鑰，都應放在伺服器端。
• 預覽與正式網址搞混。 Google 的重新導向 URI 或重設密碼郵件中的連結指向預覽網址，因此發布後登入就壞了。
• 沒有電子郵件驗證。 任何人都能以 anyone@company.com 註冊。在授予與該電子郵件綁定的任何權限之前，請先驗證電子郵件。
• 只測試正常流程。 請嘗試錯誤的密碼、過期的連結，以及第二個帳號。

在 Mythex 中加入登入功能

在 Mythex 上，為你應用程式的使用者加入登入，是你為自己的應用程式所做的事，它與你自己的 Mythex 帳號是分開的。Mythex 不提供內建的驗證產品，因此你需要自行帶入驗證函式庫或服務，以及它的金鑰：

1. 選擇一種做法，例如把電子郵件與密碼存在你自己的資料庫中，或使用託管服務的 SDK。
2. 如果你自己儲存使用者，應用程式就需要資料庫；請在對話中要求，或使用 /database。
3. 把服務的金鑰存在專案機密中（/secrets 或專案設定）。
4. 使用類似上面的提示詞，然後在預覽中測試。如果要使用 Google 登入，請同時為預覽與已發布的位址新增重新導向 URI。

參閱文件中的為應用程式加入登入。如果你要打造付費產品，如何建立 SaaS MVP 會同時涵蓋帳號與計費。

常見問題