OAuth 帳號解除綁定的內心戲與技術取捨 🤯

早上翻開昨天調整完的 UI，發現間距問題似乎真的改善不少，Clarity session 中用戶滑動的速度終於降下來一點點，內心小小竊喜了一下（至少昨天的糾結沒有白費啦 🥹）。但還沒來得及開心多久，就又碰上了另一個讓我頭痛的問題：Google 帳號解除綁定流程要怎麼設計得直覺又安全？

本來我以為這功能很簡單，無非就是按個按鈕呼叫一下 API，撤銷一下 Token 就結束了。但實際動手寫的時候才發現，事情完全沒這麼單純。尤其 OAuth 這種第三方登入的邏輯根本是魔鬼藏在細節裡，稍微沒考慮周全就會造成用戶的困惑甚至安全問題。原本寫了一段 revoke Google token 的邏輯，想說這樣比較乾淨，避免用戶再登入時產生不必要的授權提示。但回頭想想，OAuth token 本身就有有效期限，主動撤銷其實意義並不大，反而增加了 API 呼叫跟錯誤處理的複雜度。最後還是決定狠下心來把這段邏輯整個拿掉，乾淨俐落地只處理本地帳號綁定的狀態更新，讓流程變得更直覺一點。

但接下來又碰上另一個更棘手的問題：如果用戶當初是透過 Google OAuth 註冊的，那解除綁定後要怎麼處理他的登入狀態呢？畢竟我們的系統裡根本沒有他原本的密碼，這樣不就直接變成幽靈帳號了嗎？🤔 一開始我還天真地覺得，「那就順便強制登出所有裝置吧！」於是就很開心地在 AuthProvider 裡加了一個登出所有裝置的邏輯。但寫完後突然又覺得這樣會不會太暴力，用戶搞不好只是想換一個 Google 帳號綁定，沒必要直接被踢出去所有裝置，體驗可能會變差很多。

這個抉擇卡了我好一陣子，最後還是決定在 UI 提示上多花點功夫：當用戶要解除綁定 Google 帳號時，先跳出一個對話框，清楚告訴他「你會被登出所有裝置，確定嗎？」至少這樣做，用戶心裡會有個底，不會突然傻眼地發現自己被系統踢出去了。雖然 UI 上多了一個步驟，但至少能在用戶體驗跟安全之間達到一點平衡。

處理完 OAuth 這塊邏輯後，順勢把相關的會員文件也更新了一波，畢竟這些 OAuth 登入、Token 管理的細節如果沒有好好寫清楚，未來自己回頭看一定會滿頭問號 🤷‍♂️。順便調整了一下 EmailChangeForm 的顯示邏輯，對 OAuth 用戶直接隱藏修改電子郵件的功能，因為 OAuth 帳號的 email 根本不是我們能控制的，讓用戶修改反而會造成更多困擾，乾脆直接限制起來。

下午看了一下 Clarity 跟 Google Analytics 的載入方式，突然想到 GDPR 的 Cookie Consent 機制好像一直沒處理好。我之前都是直接載入這些分析工具，根本沒考慮過用戶的同意狀態，這樣長期下來可能會有法規上的風險（雖然台灣用戶好像沒人在意，但歐盟市場也總是要考慮一下吧 🥲）。於是花了一點時間把 CookieConsent 跟 MicrosoftClarity 元件改成動態載入，並在 GoogleAnalytics 組件裡面根據 consent 狀態決定要不要載入分析 Cookie。

做完這些修改後，心裡還是忍不住想：「這些細節到底用戶會不會在意啊？會不會根本沒差？是不是又陷入了自我滿足的工程師心態？」但想到這些小細節如果沒處理好，未來可能會變成技術債，或是造成用戶流失，還是覺得今天花這些時間是值得的吧。

回頭看今天處理的這些 OAuth 解除綁定、Cookie Consent 等細節，雖然每個功能看起來都很小，但背後的取捨跟思考卻一點都不簡單。創業到現在，我越來越發現，產品開發最難的從來不是寫出功能，而是決定哪些功能該做、哪些可以不做，甚至哪些功能應該要「少做一點」。這種判斷力好像永遠沒有標準答案，但我想只要持續觀察用戶、持續問自己「這樣真的有比較好嗎？」，應該就會慢慢接近那個理想的產品樣貌吧。