隨手扎
【用Keycloak學習身份驗證與授權21】在Flow這段小旅途外的風景
在這一小段路中介紹了Password Flow、Implicit Flow、Code Flow、Refresh Token Flow、Client Credentials Flow、PKCE、Device Code Flow。有些模式已經被發現可能有潛在風險，有些模式無法單獨使用。這或許還不是全部，至少到現在為止都還沒有提到過金融級應用Flow–CIBA。
Client Initiated Backchannel Authentication Profile(CIBA)
本小節也不會詳細介紹CIBA(Client Initiated Backchannel Authentication)。儘管CIBA現在階段還只是草案(Draft)，但在Keycloak v15版本中已經可以使用。大概也已經確實有一些應用使用。
為什麼你不該繼續使用Implicit Flow?
在談到Implicit Flow時候，提到過:
將存取權杖暴露在使用者面前也不是非常好的做法
所以通常在處理完存取權杖後，應該會跳轉畫面，或至少將資訊清除。在網址列上的權杖(token)簡直不要太好取得：
window.location.hash
簡單一行就可以取得基礎，再做一些分析就可以輕易得到存取權杖。儘管在「Quick Start」的Web App中取得的是id_token，但access_token也是同樣。
但爲了讓客戶端處理，這是不得已選項。要是根本無法取得，就算走標準的code flow也沒法玩下去。但主要防範的不是坐在電腦前開著瀏覽器的資源擁有者，要注意的是注入風險。也就是XSS跨站腳本攻擊。
就算不是隱含模式，也很有可能有跳轉頁面的需求。在跳轉頁面後網址列上的token自然也就消失了。爲了讓跳轉的頁面能夠知道存取權杖，在跳轉前有可能將存取權杖儲存在localStorage或是sessionStorage。
但存localStorage或是sessionStorage是不是就是安全的？我沒有答案。同樣XSS攻擊也可以很容易的取得localStorage或是sessionStorage裡的資料。但或許可以使用特別的key，降低被猜測到取得的風險。
可以存取「歷史記錄」的擴充套件
XSS跨站腳本攻擊是不得不多加注意的風險外，其實隱含模式的風險增加也與越發強大的瀏覽器有關。或者說與越發多樣的瀏覽器擴充套件，與多樣的使用環境有關。
XSS跨站腳本攻擊在某種程度上還可以透過開發人員多加留意防範。但使用者使用什麼瀏覽器，又安裝了什麼擴充套件就不是開發人員可以輕易處理的風險了。
通常而言，window.hisory相關的API會限制腳本存取瀏覽器歷史記錄的能力，但是給瀏覽器擴充套件的API - WebExtensions API – history就強大許多。
下面的擴充套件只說明擴充套件確實有可能取得歷史記錄，不代表存在問題。甚至有些設計的我還覺得蠻方便的：
Improved History
History Master
也就是說明就算頁面跳轉了，惡意的瀏覽器擴充套件仍有可能透過歷史記錄找到存取權杖。使用擴充套件的風險遠不止這樣，類XSS攻擊的風險同樣存在，甚至可能更多風險。所以在使用時，應該同時留意使用了什麼瀏覽器，啓用了什麼擴充套件。
小節結語
OAuth的內容可能遠不止本系列提到的這麼多，未來還有可能再增加、改版。有些概念很遺憾我也沒有很好的理解，只能夠以額外的形式做一點補充。
接著會是稍微簡單一點，與keycloak有關的內容。在那之後，才會在提到Open-Id，這個可能經常與OAuth一起看到的名詞。