如何為應用程式加入登入功能：密碼、魔術連結、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，權限改變時也發出新的 ID
• 在伺服器端強制執行閒置逾時及絕對最長有效期
• 登出時在伺服器端結束工作階段，而不只是刪除 Cookie
• 用戶更改密碼時，使其工作階段失效

在教學中，把登入權杖儲存在瀏覽器的 local storage 中很常見，但這會令它暴露給任何在頁面上運行的腳本；對於網絡應用程式來說，安全 Cookie 通常是較好的預設選擇。

涵蓋基本要求的提示詞

為這個應用程式加入用戶帳戶。用戶可以以電郵和密碼註冊及登入，或使用 Google 登入。使用 [函式庫或供應商]，而不是自行撰寫驗證程式碼。以 Argon2id 或 bcrypt 雜湊密碼。加入以電郵發送的密碼重設功能，使用只能使用一次、一小時後過期的連結。把工作階段保存在安全的 HttpOnly Cookie 中。保護 /dashboard 及每一條 /api 路由，只允許已登入的用戶使用，並確保用戶只能查看自己的專案。加入「管理員」角色，可查看所有用戶；只有管理員才能進入 /admin，並在伺服器端檢查。

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

AI 生成登入功能的常見錯誤

• **只在頁面上做保護。**頁面會把未登入的用戶重新導向，但 API 仍會向任何人回傳資料。
• **把機密放在瀏覽器中。**OAuth 用戶端密鑰和驗證供應商的管理金鑰應放在伺服器端。
• **預覽與正式網址混淆。**Google 的重新導向 URI，或重設密碼電郵中的連結，指向預覽環境，因此發布後登入便會失效。
• **沒有電郵驗證。**任何人都可以註冊為 anyone@company.com。在授予與該電郵相關的任何權限之前，應先驗證電郵。
• **只測試正常情況。**試試錯誤的密碼、過期的連結，以及第二個帳戶。

在 Mythex 加入登入功能

在 Mythex，為你應用程式的用戶加入的登入功能，是應用程式的一部分，與你自己的 Mythex 帳戶分開。Mythex 不提供內建的驗證產品，因此你需要自行接入驗證函式庫或供應商及其金鑰：

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

詳情請參閱文件中的為你的應用程式加入登入功能。如果你正在建立付費產品，如何建立 SaaS MVP會同時涵蓋帳戶與收費。

常見問題