顧客登出後，各裝置的登入狀態應如何處理？

先寫清楚登出的承諾

顧客按下「登出」，通常期望現用裝置不能再打開私人帳戶頁。這句話容易說，實作卻可能只做了一半。把頁面上的姓名移走，或轉回歡迎頁，只改了外觀，不能證明舊工作階段已失效。應把承諾寫成可測試的請求：瀏覽器再次帶着舊工作階段憑證要求私人資料時，伺服器須拒絕並要求重新認證。測試範圍包括下載、訂單紀錄和更改帳戶資料，不只是控制頁。NIST 以登入後發出的祕密值維繫工作階段；OWASP 建議在登出時由伺服器明確撤銷。這些是設計依據，但小商店仍須自行決定體驗和風險政策。

先決定按鈕代表「登出此裝置」還是「登出所有裝置」。兩者都有用途，但承諾不同。顧客在共用櫃檯電腦結束使用，可能仍想保留自己手機的登入；懷疑手機遺失的人則可能需要「所有裝置登出」功能。按鈕用語及完成訊息必須與實際範圍一致。若操作撤銷全部工作階段，應說明其他裝置需要重新登入；若只結束目前一個，不要暗示已全面保護帳戶。同一帳戶可能同時有多個瀏覽器設定檔、手機和平板。營運上要能分辨每個有效工作階段，介面和日誌卻不應洩露其祕密值。

同時處理伺服器與瀏覽器

如果系統以伺服器管理工作階段，顧客登出時須在伺服器的紀錄中令該識別值失效，並在回應中清除相應瀏覽器 cookie；所有私人路徑每次請求都要核對伺服器狀態。單純清除 cookie 不能撤銷別人可能持有的副本。反過來，伺服器已撤銷但瀏覽器仍保留舊狀態，也會造成介面混亂或反覆提交已失效的憑證。閒置及整體有效期同樣要由伺服器執行；關閉瀏覽器不可靠，因為瀏覽器可恢復分頁，手機程式亦未必發出關閉事件。因此完整設計包括伺服器撤銷、瀏覽器清理，以及之後私人請求被拒絕的測試。

若程式使用權杖，先記錄哪一種權杖可直接存取資料，以及更新權杖能否重新發出存取權。只撤銷畫面中看得見的權杖，可能仍留下重新登入的途徑。短期存取權杖若沒有撤銷查核或驗證狀態變更，可能直至到期仍可用；未釐清前，不應承諾所有裝置立即失效。伺服器管理的工作階段可直接撤銷；自包含權杖則通常需要撤銷策略和有限有效期。不要只為方便前端程式而把長期工作階段祕密值放在瀏覽器 local storage。NIST 特別提醒，此類位置可能受程式注入影響。技術文件要寫清機制，顧客文案則說明他們真正可以依賴的效果。

處理分頁、裝置與身分提供者

同一瀏覽器設定檔的多個分頁通常共用工作階段 cookie。一個分頁登出後，另一個分頁可能仍顯示已經載入的帳戶畫面，直至重新整理。即使伺服器已拒絕新請求，這個殘留畫面在共用電腦仍有私隱問題。可行時清理記憶體中的敏感狀態，避免私人回應被不當共用快取，並更新其他分頁的畫面。關鍵測試仍是從第二分頁再次要求私人資料，系統必須拒絕。舊畫面仍可見與伺服器繼續授權是兩種不同問題，上線清單須同時處理。

顧客也可能經另一個身分提供者登入，例如機構的單一登入服務。NIST 指出，提供者與使用其認證的網站，各自管理工作階段；結束其中一方不會自動結束另一方。顧客登出商店後，可能仍在身分提供者保持登入，然後獲發新的認證訊息返回；這不代表商店的舊工作階段仍然有效。反過來，提供者登出亦未必令商店失效。請畫出兩方各自擁有的工作階段，再測試預期次序。若介面提供較廣泛的聯合登出，須核實實際整合真的做到，不能單憑跳轉到提供者頁面便承諾「所有帳戶都已登出」。

以遺失裝置情境驗證

假設顧客家中有手提電腦，手機可能遺留在的士。先在兩部已正常登入的裝置，各做一次無害的私人資料請求，記下結果。在電腦選「登出此裝置」，檢查舊工作階段已被拒絕，而手機若按政策應保持登入，便仍可使用。之後重新登入電腦，選「登出所有裝置」；兩邊的舊工作階段都應無法再取資料，包括手機仍打開的分頁。若系統使用存取及更新權杖，也要測試更新能否重新取得權限。這是受控測試帳戶的情境，不涉及把真實顧客憑證交給測試人員。

完成畫面應說明實際發生了甚麼，以及顧客下一步可怎樣做。如果所選權杖設計不能即時撤銷所有裝置，就要如實描述可能的有效窗口，並為涉及敏感更改的場景優先選較安全設計。不要假定更改密碼必然令所有舊工作階段失效；這需要獨立驗證。重設密碼、懷疑帳戶受侵入和自願登出，是不同觸發事件，即使系統刻意共用撤銷機制，也要分清楚。客服程序亦應讓員工準確解釋「此裝置」與「所有裝置」，避免作出系統不能兌現的保證。當下訊息宜簡短實用。

涉及帳戶變更時，也應有明確對照表。修改密碼、加入新登入方法或申報裝置被盜，各自應撤銷目前工作階段、全部工作階段，還是指定裝置？會令顧客中斷使用的操作，事前應解釋，事後應確認。客服查到的應是正式政策，不是沒有記錄的猜測。對高風險事件，商戶可選擇比一般結束瀏覽更廣泛的撤銷；這是要寫清和測試的政策選擇。日誌可記下撤銷事件及範圍，但不可存放持有即能使用的祕密值。顧客其後應能循正常、經核實的登入程序重返帳戶。

把登出納入可重複驗收

上線前，依次測試目前分頁、同一瀏覽器的另一分頁、另一瀏覽器、另一裝置、閒置到期和整體期限。登出後直接輸入私人網址，以及重開原本已取得的下載網址，也要試。若有手機程式亦須納入，因為關閉程式不等於執行伺服器登出。核對 cookie 的適當安全屬性，以及私人回應不會經不當快取洩露。客服單或分析事件不應記錄工作階段祕密值；測試紀錄只需有情境、時間、預期範圍和接受或拒絕的結果。只要有一條私人路徑仍可取資料，公開承諾便未完成。

最後，登入架構一有改動，就指定負責人重新檢視工作階段行為。新增身分提供者、手機程式，或由伺服器工作階段轉用自包含權杖，都可能令舊測試假設失效。每次須重新核對顧客用語與實際功能。NIST 和 OWASP 提供原則及機制，並不替某家商店的登出按鈕作認證；可信程度來自商店自己可重複的請求測試。實際下一步是寫清兩種登出範圍，用測試帳戶在兩部裝置驗證，直至所有私人路徑按承諾拒絕舊憑證，才標示完成。

也要預先設計失敗情況。若登出請求無法到達伺服器，畫面卻顯示安心的「完成」，便會誤導顧客。應說明操作未完成、提供重試方法，在結果未明時提醒不要把私人畫面留在無人看管的裝置。若程式可離線排隊提交操作，不能把排隊中的登出當作伺服器已撤銷；重新連線後須確認伺服器接受，再更新畫面。顧客遺失裝置又無法登入時，客服亦須有升級處理途徑；程序應核實求助者身分，按既定方式撤銷，不應在客服訊息索取密碼。失敗文案也要像正常流程一樣測試。