###### tags: `週一讀書會` # 講稿 ## 20221003 (範圍1~9投影片) 20221003 今天要報告的是Solving Identity Management in Modern Applications的第一章The Hydra of Modern Identity。Hydra是希臘神話的九頭蛇，作者使用這個詞是因為他認為身分管理就是類似的任務，它存在多個問題需要解決，比方說創建帳號、驗證使用者、多要素驗證等等。如果沒有良好的計畫解決單一問題的同時可能會帶來更多的問題。 這是我們今天的outline，共有8個主題，其中第2~7主題與書中的標題一致，而第一主題是為了先定義好身分管理這一任務增加的。此外，第2個主題針對這一章節常出現地單一登入給出更多資訊。 身分管理或稱為身分與存取管理表示系統或者應用程式在建置與操作兩個階段中對於使用者資訊控制的任務。在建置階段包含新用戶註冊以及存取權授予。而操作階段則是對於前一階段中授予的權限進行識別，也可以理解為對於用戶的身分驗證。 這張圖可以呈現整個身分與存取管理不同階段的任務，左右分別是建置跟操作階段，上下則是針對身分以及存取權的管理。 再來書中主要提到的是身分管理系統設計上所需要面臨的幾個挑戰。 第一個挑戰是，設計身分管理系統是依據開發者希望套用的產品調整的，因此不存在通用的設計準則。比方說需要針對預期的使用者作特化，面向消費者的產品以社群媒體做為登入媒介可以提供方便性。而針對工作場合，採用SSO可以提高工作者的生產力此外，不同軟體的資料敏感性不同也會影響身分驗證的設計強度，在敏感軟體上會需要一次性密碼或是硬體金鑰，這裡的硬體金鑰，這稱為多要素認證。 前面提到的單一登入SSO，是一種存取控制，旨在希望多個相關聯卻獨立的軟體可以在一次登入後都能夠使用。這樣種設計的優缺點很明。優點部分，從使用者角度而言，不需要花時間記憶密碼就可以使用多個服務，也不需要重複輸入，而從日後運營維護方的角度，可以減少客服人員的需 求，且用戶資訊更便於管理。缺點部分，因為軟體綁定，一旦帳號被盜用造成的損害會更為全面且嚴重。對於身分驗證機制的方便性有一定要求，若方便性過低會導致使用者對所有軟體的棄用。某些需要保持訪問的軟體，比方說安全系統，SSO的風險較高。基於社群媒體登入的SSO有機會受到限制，比方說工作場合或者威權國家網路審查的影響。，最後若有多個安全級別需求，例如部分服務僅供高級用戶使用的情況，則需要增加更多驗證機制，違背SSO希望增加速度的初衷。 第二個挑戰是要適應該軟體的投放平台，因應不同的敏感內容也需要不同的驗證方式。比方說網頁使用者傾向重新導入到登入頁面的功能。本地端、桌面應用程式需要整合內嵌的登入方式或使用OS的帳戶連動。移動端需要導向特定身分驗證器，比方說手機本身的密碼、臉部辨識等等。 第三個挑戰是要符合該應用程式的種類以及資料敏感性做設計。書中舉了一個範例，若今天身分管理系統作用在一個用於分享貓咪照片的app，註冊過程中向用戶請求護照的掃描檔顯得非常不適合，因為該app不具有這個敏感的特性。反之，金融app例如網路銀行要求護照檔就顯得很合理。此外，設計時也需考慮使用者當地的相關法規，書中的例子是歐盟於2016年通過2018年開始執行的法規。 1. 要按照章節內容順序呈現 2. 要在註解加上給讀者的資訊 3. 用中文 4. 專有名詞也要show英文原文 5. 後面的東西要解釋 6. 要彩排 要花一些時間研究投影片整理的技巧 不要太多空白 多用圖示的方式解釋 draw IO畫圖 每一個頁面呈現要有適當的layout 字體等等要弄清楚 呈現出well prepare的東西 ## 20230116 (範圍22~29投影片) ### 25 再來講解有關應用程式授權的場景，即被授權者為應用程式的場景。 和應用程式授權相關的場景有二，分別是應用程式代表使用者呼叫API以及應用程式代表自身呼叫API。 之後的範例會使用OAuth 2.0的術語。 代表使用者呼叫的情況，意味著該API內容屬於使用者所有，因此這時授權的對象是使用者，由使用者決定該應用程式是否可以使用其擁有的資料。這通常出現在面向消費者的應用程式當中，因為商務公司中使用的應用程式以生產力為其目的，因此較少和個別雇員的資料有關，即便是人資等部門通常也不需要其資料擁有者的同意。 一個面向消費者的應用程式範例是在前面章節提到過的照片修圖軟體。若該軟體希望存取使用者在雲端或者社群網站的照片，他會向雲端或社群網站發送請求，此時雲端和社群網站所扮演的角色就是OAuth 2.0中的授權伺服器，同時將使用者重新導向到授權伺服器的認證頁面進行身分驗證，而後會跳出要求使用者同意應用程式存取資料的視窗。 值得注意的一點是，上面所說的例子中使用者僅會授權應用程式存取照片這一要素，而非其在授權伺服器上所有資料，這引出了OAuth 2.0中scope的概念。 代表應用程式自身呼叫的情況，此時API內容屬於授權伺服器，因此授權對象是授權伺服器本身。一般而言，應用程式與授權伺服器之間的授權是基於預先設置好的策略，即某個特定應用程式可以調用那些特定API、存取端點或進行什麼操作都是早於應用程式真正呼叫API前的。 ### 26 授權分為兩個部分，這頁以虛線將兩部分分隔，上半講述應用程式發送請求時有關請求範圍的問題。而下半部分則講述授權通過後，由授權伺服器給予應用程式的grant類型。 首先，延續前面所說的scope，其代表發出調用API時，應用程式請求的範圍，諸如存取多少資料、進行那些操作等。 實作上是將其作為發出的請求的參數之一傳遞到授權伺服器。 一個範例是假設請求對OpenID提供者關於用戶資訊這一資料端點的存取權限，則可能請求中的scope會寫為這個形式。 而若請求對使用者文件的存取權，則scope會使用這個形式。 授權通過後，授權伺服器會向應用程式，或者稱為客戶端發送grant，客戶端憑藉grant可以向授權伺服器交換到用於存取的token。 若所得到的grant是授權碼或者implocit grant type，表示API資源屬於使用者，即前面提到的情況一。授權碼是一種臨時碼，由使用者在授權伺服器同意後給予，其具有一些其他類型授權所沒有的益處。當使用者被重新導向到帶有授權碼的URL後，應用使用授權碼索取token，索取請求可以用client_secret加密，降低授權碼被截獲並濫用的風險。同時意味著token對於用戶和瀏覽器為invisible的。 若得到的grant是client credentials grant，表存取應用自身的資源， ### 29 上述兩個情況，無論資源歸屬為何，若請求被授權，則以持有的grant換取存取token token中可能包含額外自定義聲明，其有助於應用存取API時的實施，比方說前面提到的有關level 3的不同地域資料存取，可藉由聲明將所屬地域加入。 ### 30 第三點:驗證token代表level1策略，token內的聲明代表level2、3的授權 存取策略實施包含在API內部驗證token在響應前決定其是否允許應用程式的請求，以及驗證完成token後根據聲明進行更細部的存取策略實施。