登出的連鎖

使用者只登入一次，背後卻可能建立多個工作階段。登出時，需要確認哪些工作階段應該結束，以及通知應該傳遞到哪裡。

登入一次，產生三把鑰匙

假設服務接入了“使用Google登入”。對使用者而言，只是點擊了一次按鈕。

但在內部，路徑上的每個系統都會建立並保存自己的工作階段。Google一份，Authrim一份，自家應用程式一份，共三份。

只要某處的工作階段仍然有效，使用者就可能繼續操作，或不輸入密碼就再次登入。

登出不只是顯示“已登出”。
需要先確定登出的範圍，再結束該範圍內的工作階段。

這裡的“鑰匙”指工作階段。存取權杖和更新權杖採用不同的機制，結束工作階段並不一定會使已簽發的權杖失效。撤銷權杖需要另行處理。

在OIDC中，工作階段登出、權杖撤銷、上游帳戶停用是三種不同操作。本文只討論工作階段。權杖何時失效，請參閱權杖內省與撤銷。

在這條連接中，上游身分提供商提供登入，應用請求登入。Authrim面向不同方向時，承擔的角色也會變化。

這就像旅行社：對旅客，它安排旅行；對航空公司，它是購買座位的客戶。Authrim也同時承擔兩種角色。

登入沿著路徑完成，而登出必須有人主動傳遞。

結束上游工作階段，不會自動刪除Authrim和應用程式中的工作階段。需要把結束請求傳到下游，再由各接收方結束對應工作階段。下圖展示的是所需通知方式和設定均已就緒時的連線。

區別在中間的箭頭：Authrim能否接收通知，並繼續傳送給下游？上游提供商和各應用程式也必須支援並設定所需方式，連線才能成立。

場景	傳遞中斷的後果
離職處理	人事部門撤銷存取權限後，筆記型電腦上的應用仍然打開，內部資料直到第二天早上仍可見。
共用終端	在零售、醫院或呼叫中心，前一位使用者已登出，另一個分頁卻仍顯示其管理介面。
裝置丟失	點擊了‘登出所有裝置’，實際卻只結束了目前工作階段。
事件回應	封禁了受入侵的帳戶，攻擊者的工作階段卻仍持續到過期。
稽核	‘請證明登出會傳遞到所有系統。’卻拿不出證據。

不是沒有登出按鈕，介面也確實發生變化。問題在於生效範圍比預想的小，因此不容易發現。

通知下游主要有兩種方式，其中依賴瀏覽器的方式會遇到更多限制。

上方透過不可見框架通知應用程式，可能受到瀏覽器隱私保護限制。下方的後通道直接連接伺服器，不依賴瀏覽器狀態。但這不代表一定送達：網路故障、接收方停機、逾時和5xx回應都可能造成失敗。重試、佇列和失敗記錄需要由實作提供。

Authrim的認證覆蓋接收後通道通知的能力。接收和向下游傳送需要分別驗證。

Authrim對上游是依賴方（RP），對應用程式是OpenID提供方（OP）。要繼續傳遞登出通知，兩種角色都必須遵循規範。

OP與RP的登出協定規範（profile）認證，為這兩種角色提供驗證依據。這裡的profile指一組特定的協定要求，不是設定檔。Authrim透過OpenID Foundation的自我認證流程，使用官方一致性測試，取得了兩側的登出協定規範認證。

認證表示提交版本通過了所申請協定規範的一致性測試。它不保證客戶網路及所有關聯應用程式中的工作階段都會立即結束。

上游和各應用程式必須支援所需方式，並設定通知端點與工作階段對應關係。停用上游帳戶不一定會觸發登出通知。還應在實際部署中驗證通知失敗、重試及失敗可見性。

認證版本與協定規範見OpenID Foundation的Certified OpenID Relying Parties & Logout Profiles列表。認證範圍見認證制度說明。

登出之後，哪裡還保留著登入狀態？

交接共用終端或終止離職員工存取時，需要確認的就是這個範圍。Authrim接收並轉發通知，連接上游與應用程式的工作階段結束處理。認證是實作的驗證依據，而關聯環境中的測試用於確認實際生效範圍。