###### tags: `週一讀書會` `20221003`
# Solving Identity Management in Modern Applications筆記

## 20221003 - The Hydra of Modern Identity
### 龔鈺翔
若無適當的計畫，解決一個問題可能生出兩個問題出來
#### Identity Challenge
需要詳細計畫、設計、開發來達成，同時平衡業務(business)及安全需求、用戶體驗
並沒有一個方法可以套用在所有情境上
舉例:
* 面向消費者的APP可能需要可以從多個不同的社群帳號做登入都可以
* 工作用的使用者可能想要SSO來一次存取多個不同的內容
* 包含敏感內容的需要MFA，同時容易使用
* 手機一次性密碼
* 硬體金鑰
* 多個APP需要SSO，對使用者更方便，管理者也更好做身分驗證
但這個需要SSO那個點有高度可用性??高可靠性，不能成為使用者的阻礙

可能需要適應不同平台
* WEB可能要重導向
* 本地App可能更傾向嵌入App的登入方式或者利用底層OS提供的session
* 移動端APP可能要導向身分驗證器或內嵌登入介面
權衡以上才能有良好的體驗(設計需要考慮交付平台並給出適合該平台的登入方式)

身分驗證的設計要符合APP的敏感性、種類
* 看影片的APP需要護照等來驗證不太合理
* 但金融類的APP需要護照就比較合理(敏感性&法規)

考慮到使用者當地的相關法規
* GDPR

#### Objective
作者寫這本書的目的是介紹身分管理這個主題，著重在應用程式中身分管理的各方面，
例如:創建帳號、身分驗證、API授權、單點登入、帳號管理以及註銷用戶等方面
這本書會介紹三種常見的身分協議，
* OAuth2.0
* OIDC
* SAML2.0
包含協議如何運作、解決甚麼問題、給出簡單的案例。
##### OAuth2.0
##### OIDC
##### SAML 2.0

~~良好的身分管理設計可以簡化架構、將責任分到其他組件、提供用戶單一視角、統一訪問控制來簡化訪問問題、提供關鍵審查能力(追蹤使用者存取紀錄)等~~

首先討論帳號開通、幾個讓使用者方便使用的選項、API授權、身分驗證(~CH9)
再來介紹使用者首次登入之後發生的事:session、SSO、更強的身分驗證、帳戶管理、登出、刪除帳號(~CH15)
若使用其範例程式有問題可以找troubleshooting(CH16)
也分享一些會出問題的場景CH17
及曾經遇到的不尋常案例CH18
最後簡單描述合規性(compliance)CH20及導致的違規行為(breaches)CH19

接下來是作者給讀者的閱讀建議
作者認為1到15章都有前後關係，所以建議前15章照順序讀
如果沒辦法讀完，至少先照順序讀4~9章，因為關聯性最高
在15章之後的章節都是能性的章節，所以閱讀順序不重要
debug看16章
18章對讀者在做project的時候可能有用，裡面提到的不常見要求可以幫助確定計劃所要包含的事項
17、19章涵蓋不同種類的問題，對規劃和避免錯誤有幫助

~~在OAuth 2.0 和 OIDC的章節，提供了應用程式發送http請求的例子，若讀者使用SDK或函式庫來處理很好，但語法會不同。但是底層的調用都應該符合標準規範。在實際進行故障排除時可能會用瀏覽器工具或debugger，此時了解底層HTTP請求及響應會很有幫助~~
$\Alpha$ 名詞問題
在特定協議章節中使用其術語，在其他章節中使用通用術語
* 例如，OAuth 2.0章節中我們指的是授權伺服器(authorization server)，在OIDC中是OpenID提供者(OpenID Provider)，而在SAML 2.0章節中是身分提供者(identity provider)。在其他更加通用的章節，我們會使用identity provider作為位app驗證用戶身分的服務的名詞。
*
*
* 例外
* "應用程續"
一個例外是我對於客戶端app的術語。跨這些協議的客乎端app有許多名稱，客戶端、依賴方(relying party)、服務提供者、客戶端app等。“客戶端"和"依賴方"在某些規範中表示不同的的東西。為了降低對初學者的混淆，我們選擇使用"應用程續"來指代通過OAuth 2.0、OIDC或SAML 2.0發送身分驗證或API授權請求的應用程式。
* ”relying party”
為其他應用提供服務的提供者，但同時依賴於IDP做身分驗證
* ”simply users”
終端用戶

會有甚麼問題: OIDC和SAML 2.0客戶端(client)可能是其他客戶端的提供者(provider)

要這樣用的原因:介紹性質、介紹基本的案例、保持一致性

有時也用”relying party”，指的是依賴方但可能是為其他client提供服務的provider，而非應用程式
稱終端用戶為”simply users”

#### Sample Application
提供一個用OIDC和OAuth 2.0的範例應用
第9章解釋其如何用身分協議(OIDC等等)來作為身分管理解決方案的一部分
* 警告:範例程式碼為簡單捨棄許多功能，不能拿來實際應用到產品上
#### Design Questions
在開始寫自己的應用之前，建議思考以下問題，以便閱讀之後的章節
* 你的目標用戶? 員工、消費者或者是企業?
TA是誰
* 使用者將如何登入? 有一個現存的他們可用的帳號使他們想要繼續使用嗎?
TA要的登入方式&有沒有現成的帳號需要沿用
* 你的應用可否用匿名的方式，或者說一定要登入(驗證)嗎??
是否一定要登入，可否用匿名的方式
* 應用要跑在哪個平台(投放方式)?(網路或本地)?
確認應用所在平台、ANDROID WEB WINDOWS?
* 你的app需要呼叫任何API嗎? 誰是資料的擁有者?
* 你的app需要處理多敏感的資料?
像是銀行帳戶?或是只是簡單的區分使用者而已
* 什麼樣的存取控制需求是必須的?
存取全控制要做多細，盡量避免做太多??
* 一個使用者的對話(session)持續多久?
* 是否有多個應用在你的系統中嗎? 如果是，使用者是否會受益於單點登入(SSO)?(不要忘記支援論壇)
* 當使用者登出會發生甚麼?
* 是否有與此資料相關的合規要求(符合法律規定)?
#### Summary
用戶希望有順暢良好的體驗，身分管理應該要幫他們達成這個目標
為了達成這個目標，在開發身分管理時會遇到很多問題
#### Key Points
* 身分管理對開發者有許多挑戰
* 身分管理的方案要切合程式的敏感性、目標用戶體驗、及投放平台
* 身分管理這個問題一本書講不完
* 本書提供身分管理的概述以及常見的身分管理要求
* 介紹三種協議-用法、原理、如何發出一個簡單的request
* 提供一個範例程式來說明一些主題

### 謝昌諭
#### Identity Challenge
身分管理在實作中需要很多要素共同運作才能發揮作用，App需要仔細的規劃、設計、開發以實現身分管理，同時平衡源於需求和安全性的期望，以及良好的用戶體驗。但是，身分管理不是一個可以一體適用的問題，無法期待一個解決方案適用每個個案。
<font color=red>
* 在需求跟安全性中取捨
* 不存在通用準則，針對產品設計
</font>

比方說，面向消費者的App會期待能夠經由FB快速登入。甚至，他們會希望可以讓使用者使用多種社群媒體登入但仍被視為同一人。這個問題處理不善可能導致用戶因為註冊、登入操作麻煩而棄用。另一方面，作為雇員的使用者需要以工作帳號訪問公司的App，他們想要單點登入帶來的便利性。此外，公司組織通常擁有複雜的、基於規則的授權需求，用以管理組織中雇員的權限。
<font color=red>
* 使用者種類需要納入考慮
* 不良的使用者設計會導致app棄用
</font>

包含敏感內容的App需要比單純的密碼更加強力的認證方式，但這衍伸一個問題，甚麼形式的身分認證方案足夠安全同時對於用戶又足夠方便。強力的身分驗證有很多選項，設備自動生成並發送到手機的一次性密碼、帶有私鑰的hardware security tokens。需要的是用戶容易使用和接受的解決方案，過於複雜的方案可能讓用戶直接放棄使用。

若提供多個App，甚至是App外的支援接口(support portal)，用戶可能會想要單點登入(single sign-on)，使他們僅需要登入一次就可以訪問多個App。這對於用戶而言不僅較便利，也提供一個地方讓他們控制身分驗證策略(authentication policy)。然而，身份驗證是App的一個閘道(gateway)。它必須是高度可用的，並且可以比App本身擴展的更高(scaling up higher)。否則，它會突然變為一個障礙(obstacle)而非閘道。如果單點登入阻礙了對App的訪問，它就沒有好處了。

你的App設計可能需要適應各種來自交付平台(delivery platform)的限制。Web上，使用者可能期待瀏覽器重新導向到登入頁面進行身分驗證。相反，本地桌面App的用戶可能更傾向嵌入App的登入流程或者利用底層OS提供的session。不同的移動App可能使用不同的方法。有些可能將你重新導向到一個身分提供者以登入，但其他可能仍會直接在App中提示你輸入憑據(credentials)。你需要權衡這些不同的方法並設計，好提升適合該App式交付平台的用戶體驗。
<font color=red>設計需要考慮交付平台並給出適合該平台的登入方式</font>

App的身分管理的設計需要回答所有這些問題，當考量到App的敏感性以及滿足相關的商業需求時會有更多問題。一個例子可能有助於展示糟糕的身分決策(identity decisions)會對用戶的App體驗產生多負面的影響。想像一下，你剛安裝了一個新的App勇於查看貓的影像，註冊過程中要求護照的掃描檔以及自拍影片。這無疑非常可疑，因為很難想像為何一個貓咪影像app需要護照資訊。糟糕的註冊和登入體驗會損害app的可用性以及使用率。另一方面，對於一個金融app而言，提供護照作為身分驗證的要求會顯得更合理。它可能是受到監管要求的影響。事實上，紀錄一段影片去驗證你的身分是由Monzo.i提供給挑戰者銀行app的一種創新的入職測試。如果你在製作一個貓咪影像app，一個無摩擦的社群媒體登入可能是完美的解方。然而，如果你正建立一個銀行app，你將會需要一種更加複雜的註冊過程以及身分驗證，同時包含強身分認證。app的身分管理解方必須符合該app的敏感性以及種類。
<font color=red>設計的身分管理機制需要考慮app的性質，為敏感資訊的app設置夠強的機制確保安全，而為不敏感的app設置簡單的認證加快登入速度</font>

這似乎不夠，構建app是另一個主要問題是對敏感身分資料的保護以及規範的隱私法規。隨著歐盟的GDPR(通用資料隱私條例)以及其他地方頒布的類似法規，收集或處理用戶資訊的app必須遵守隱私要求，違反會面臨嚴重的懲罰。前面提到的挑戰僅是在為你的app設計身分管理時可能面臨問題的範例。
<font color=red>設計需要使用地區的法規</font>

#### Objective
我們編寫本書的目的是根據我們構建和部屬app的經驗，向你介紹身分管理這一主題。測重點特別放在身分管理對於軟體app例如創建帳號、身分驗證、API授權、單點登入、帳號管理以及註銷用戶等方面。為了設定符合真實的期待，身分管理是一個巨大的主題。一本書無法讓你成為一位專家或涵蓋所有應該知道的東西。我們將會討論的身分協定規範超過800頁，並且它們僅呈現你所需要知道的一部分的資訊。我們無法希望涵蓋這些協定或每一種身分管理個案的所有面相。我們可以做的事提供一個介紹性質的概述，以幫助你了解典型app專案所需的身分管理的常見面向，三個標準身分協議如何為您解決基本的需求，以及示範程序如何解決某些真場景。
<font color=red></font>

我們會介紹三種流行的身分協議，即OAuth2.0、OIDC和SAML2.0，具體來說每個協議如何工作、解決甚麼問題、如何為簡單的案例實現身分驗證和授權請求以及如何解決問題。我們無法包含所有參數或使用案例，但你應該對每個協議的作用以及工作原理有基礎的理解。我們希望本身隨附的文本和範例程序能夠對您的app開發專案的身分管理提供有用的概述。我們也希望您受到啟發，進一步探索這個主題，以理解更高級的範例以及解決方案。

適當妥當的身分管理解決方案可以簡化整體架構。他可以讓app將某些職責委派到其他組件，並可以提供用戶單一視角並統一訪問控制以簡化訪問問題，提供關鍵審計功能(critical auditing capabilities)等等。

首先討論帳號開通以及幾個讓使用者設置的選項以便讓他們使用你的服務。然後我們深入討問API授權以及身分驗證，並給出當今三種受歡迎的協定的概述，OAuth2.0、OpenID Connect (OIDC)、Security Assertion Markup Language (SAML) 2.0。這些章節涵蓋了驗證用戶以及處理app和API認證。在介紹這些協定的基礎機制後，我們安排一個章節解釋本書附帶的範例程式碼以及如何使用它們。

隨後的章節介紹用戶首次登入會發生甚麼，包括有繪畫、單點登入、更強的身分驗證刑事、帳戶管理、登出以及取消配置(deprovisioning)。如果你的app在第一次運行中不完美，我們會附上一章節教學故障排除。我們也分享有關可能出現問題的場警資訊，以及一些我們曾遇到的不尋常案例。最後我們簡要概述合規性(compliance)以及導致某些非常不幸的違規行為(breaches)的錯誤。也許也從過去學習。

我們建議案順序閱讀這些章節，至少通讀第15章，因為許多章節的內容都建立在前面的章節中。對於某些人群中的叛逆者，我們特別建議至少閱讀第4~9章，因為這兩章對於早期內容的依賴程度最高。15章之後的章節則大多可以按照任一順序閱讀。當你需要debug某個問題時，第16章關於故障排除是最相關的。第18章關於不常見的需求對於計劃早期的很有價值，因為它可以協助確定要整個計畫需要包含的項目。第17、19章涵蓋了不同類型的問題，將協助計畫以及避免錯誤。

在 OAuth 2.0以及OIDC的章節中，我們提供了app發送http請求的例子。我們體認到你可以使用函式庫或SDK促進此類調用，事實上我們很鼓勵這樣做。如果這樣，則語法會因為選擇的實現方式有異。然而，雖說每個函式庫或SDK都有所不同，但底層調用都應符合標準規範。當需要對實作進行故障排除時，可能會使用瀏覽器或者debugger來分析進行的調用，此時，了解我們所展示的底層http請求將很有用。即便您只是配置購買的app，咧解基本的請響應對於故障排查也有幫助。

有關命名的需要注意的是順序。我們涵蓋的協定各自使用不同的術語。這造成難以對某修組成部分使用同樣的術語。我們在幾種方法間討論，最終決定在涉及特定協議的章節中，我們會使用該協議的術語，而在其他章節中，則將使用更為通用的術語。例如，OAuth 2.0章節中我們指的是授權伺服器(authorization server)，在OIDC中是OpenID提供者(OpenID Provider)，而在SAML 2.0章節中是身分提供者(identity provider)。在其他更加通用的章節，我們會使用identity provider作為位app驗證用戶身分的服務的名詞。一個例外是我對於客戶端app的術語。跨這些協議的客乎端app有許多名稱，客戶端、依賴方(relying party)、服務提供者、客戶端app等。"客戶端"和"依賴方"在某些規範中表示不同的的東西。為了降低對初學者的混淆，我們選擇使用"應用程續"來指代通過OAuth 2.0、OIDC或SAML 2.0發送身分驗證或API授權請求的應用程式。這並不理想，因為它忽略的一個事實，在更多涉及的案例中，OIDC和SAML 2.0客戶端可能不適應用程式，而可以是一它客戶端提供者。因為我們的重點是介紹性質的、基本的使用範例，我們決定在各章之間權衡，以簡化並保持醫治性。我們偶爾使用術語"依賴方"，其中的實體"依賴方"可以是為其他客戶端提供服務的提供商，而非簡單的應用程式。我們也將終端用戶稱為簡單用戶，因為我們不需要區分用戶類型。

#### Sample Application
為了補充文字，我們提供了一個使用OIDC和OAuth2.0協議的示範app。第9章解釋了示範app以及它是如何設計為將身分協議用作身分管理解決方案的一部分。我們需要在這給出常見的警告。作為範例程式碼，本書的程式碼範例和範例app為了簡單捨棄許多功能。他們不是可投入生產的程式碼，不應該用作生產app的基礎。

#### Design Questions
要開始你自己的app，我們建議考慮以下幾個問題，為閱讀以下章節做準備:
* 你的用戶是什麼人? 員工、消費者或者是企業?
* 使用者將如何登入? 有一個現存的他們可用的帳號使他們可以重複使用嗎?
* 你的app可以被用於匿名或者它是需要身分驗證的?
* 哪一種交付方式是你的app期望提供的?(網路或本地)?
* 你的app需要呼叫任何API嗎? 如果要誰擁有你的app需要的資料?
* 你的app需要處理多敏感的資料?
* 什麼樣的存取控制需求是需要的?
* 一個使用者的對話持續多久?
* 有超過一個以上的app在你的系統中嗎? 如果是，使用者是否會受益於單點登入?(不要忘記支援論壇)
* 當使用者登出會發生甚麼?
* 是否有與此資料相關的合規要求?

#### Summary
現代用戶希望使用app時獲得順暢、精心設計的體驗。身分管理應該幫助他們快速訪問app，而非妨礙它們。為了實現這一目標，開發人員在為現代app開發身分管理解決方案時面臨很多問題，並且需要對他們可用的各種選項進行分類。下一章節會通過介紹身分生命週期中的事件來幫助理解身分管理解決方案的組成部分。

#### Key Points
* 身分管理對現代app開發人員包含許多挑戰。
* 身分管理解決方案必須對該app敏感性、期望的用戶體驗合交付平台是妥當的。
* 身分管理是一個巨大的主題，比本書可以涵蓋的更多。
* 我們會提供身分管理以及其對你的app典型的需求的概述。
* 我們會涵蓋三種協定，它們被用於什麼、它們如何工作以及如豪做出一個基礎的身分認證或認證請求。
* 我們會提供一些示範程式碼幫助解釋某些討論的主題。

[單點登入](https://zh.m.wikipedia.org/zh-tw/%E5%96%AE%E4%B8%80%E7%99%BB%E5%85%A5)

###### SAML 2.0
安全斷言標記式語言，一種基於XML協定用於在服務提供者(SP)和身分識別資訊提供者(IdP)間傳送驗證、授權資料的標準。基本的用途是實現瀏覽器的SSO。SSO意指通過單一次身分驗證後，身分資料會傳送到多個SaaS，無須重複登入。

###### 如何運作?
IdP指有含有使用者身分資訊的服務端，SP指接受到該資訊後提供服務給通過驗證者的服務端。當使用者需要服務時，他會登入SP，隨後SP將請求重新導向IdP並試圖從IdP得到驗證和授權資料。使用者在IdP完成驗證後，IdP會回傳訊息表示使用者通過驗證。此訊息作為證型IdP授權使用者的證據，SP會在接獲證據後提供服務。

IT管理者的角度，SAML SSO由IdP統一管理使用者資料，多數情況下SaaS若提供即時制度 Just-In-Time Provisioning(JIT Provisioning)，管理者無須在使用者使用該服務時新增資訊。

而對使用者而言，SSO不用記很多密碼。

###### 同學回饋

# <font color=red> --- 分隔線 ---</font>
## 20221107 - Evolution of Identity
### 龔鈺翔

### 謝昌諭
此章節描述一些過去用於身分管理的驗證/授權方法。選擇特定技術是為了凸顯各自的優缺點，可以幫助讀者評估執行計畫所需的方案。此外，也討論為何應該使用業內的標準協議而非開發自己的解決方案。
<font color=red>簡介作者給本章的概述</font>

#### Identity Management Approaches
了解舊技術的優缺很有價值，因為部分依舊在使用。此章部會列出所有而只有部分精心挑選的，用於說明在現實使用中的優缺。閱讀每個sol時需重點注意解決問題和優缺。這有助於評估並使用更新的方案。會先回到個個app都實現各自的驗證和使用者資料庫。
<font color=red>描述作者立場即可，不重要</font>

#### Per-Application Identity Silo
早期每個app都維護自己的身分資料庫和驗證/授權。大企業通常有核心業務app以及一些生產力app。各自擁有資料庫儲存身分、憑據、問至文件等，且都會讓用戶登入並依據自身資料庫進行驗證。這表示需要很多帳密，也因此當配置文件要素改變時多個app都需要修改。若有多個app則不可靠，因為文件數據可能不同步。用戶也會因為多組帳密和數據完整性而不高興。隨著app增加，讓每個app實施各自孤立的身分認證對企業而言不好。
<font color=red>描述早期各自為政的缺點即可，不需要太多著墨</font>

此類獨立的方法曾有許多應用，用戶通過特定帳密註冊app。若帳密在多個地方重複使用，則任一點入侵都使全部人面臨風險。若指定不同帳密則必須記住所有帳密或依賴帳戶回復功能。無論何者消費者都和早期企業相同的不便。
<font color=red>描述早期各自為政的缺點和問題依舊存在即可，不需要太多著墨</font>

#### Centralized User Repository
隨著發展，app越來越多，造就對更好的身分管理的需求。很多公司採用"目錄服務"存放和集中身分資訊，它針對經常讀取而不常修改的資訊做優化，比方說用戶的身分資料。app可以使用目錄服務存儲用戶資料跟憑據，也可以提示用戶登入並使用該服務的驗證輸入憑據。針對企業環境的大型現場商務app通常包含這種方法的支援。這種中心化方法比獨立的、逐app的方法有顯著提升。

身分管理和訪問的中心化有很多優勢。目錄複製功能使全世界託管的app可利用相同的身分資訊，消除不同步問題。跨app使用相同用戶名稱和密碼。此外還提供"單點控制"，可在該控制點實現密碼策略、必要時快速終止身分。目錄服務被廣泛採用，至少對於大公司而言是如此。
<font color=red>要呈現中心化的解決方法比過去獨立的，解決了多密碼、不同步的問題</font>

但是，它也有缺點。目錄本身不維護任何和客戶的session。用戶只有一組帳密，但每個app都需要重輸入，因為app需要各自向目錄進行驗證(沒有其他附加技術的情況下)。除了不便，用戶密碼也暴露給app。單一app的妥協造成全體的風險。當所有app都在可信任公司網路時已經夠糟糕。隨著公司採用雲端app，暴露給其他人擁有的雲端app有不可接受的風險。
<font color=red>描述其資安方面的問題</font>

#### Early SSO Servers
SSO提供進一步改進。SSO在目錄上增加維護session和記住用戶的層。雖說app工作方式不同但可以重新導向到SSO伺服器，以安全、預設的方式接受驗證結果。若登入相近不需要重登入。

與目錄服務相比，SSO伺服器提供很多優勢。用戶受益於登一用多。安全團對則受益於目錄只暴露給SSO伺服器而非全部app。IT部分也受益於一個單一位置實現身分驗證以及更強大的驗證機制。

但，早期SSO也有缺點。app和SSO的交互是專有的(proprietary)。SSO產品的實作很費時。在有資源的大公司更有可能做到。而且SSO基於cookie，瀏覽器對cookie訪問的限制表示在單一網域中運作。很多公司的SaaS服務而言這是一個限制。
<font color=red>強調解決過去問題及新問題即可</font>

#### Federated Identity and SAML 2.0
SaaS的增加對IAM帶來挑戰，SaaS app中沒有管理員工的好方法。公司很難追蹤員工在SaaS創建的帳號，用戶再次需要記住所有密碼。內部app的SSO沒有擴展到其他外部SaaS。

好在2005年發布新的SAML 2.0標準。它為跨域和聯合身分(federated identity)SSO提供解方。對於擁有SaaS app的企業而言很完美。雖說SAML 2.0概述側重面向消費者，但其為更好控制SaaS app的員工身分企業提供好的解方。

借助SAML 2.0，SaaS app可以將企業用戶重新定向到企業的身份驗證服務(IdP)上，以進行身分驗證。身分聯合(Identity federation)提供將app中使用身分和IdP的身分聯繫的方法。公司現在可以透過內部和SaaS app獲得SSO的優勢。用戶也只需要記憶單一帳密。企業有一個用於內部和外部身分的中心化控制點，如果需要，可以在企業IdP處快速關閉訪問。密碼策略和多要素驗證可以在同一位置實現。SAML 2.0解決企業很多身分問題。

儘管廣泛採用，SAML2.0也並非萬能。因為希望覆蓋更多場警，因此實現很複雜。雖說其在企業環境廣泛採用，但沒有可行的商業模式解決面向消費者的場景。用戶不可能為面相消費者的身分服務付費。後續會看到這是通過讓他人完全支付服務費用解決。另一個限制是它只解決身分驗證問題。app正轉變為基於API的架構，而SAML2.0解決身分問題但對API授權沒有幫助。

#### WS-Fed
Web Services Federation Language (WS-Fed)聯合框架由產業聯盟建立，以作為被稱作WS-∗規範的更大協議集合的一部分。<font color=red>WS-Fed 1.2 規範於 2009 年作為 OASIS 標準發布ii，並提供了“對在一個領域中管理的資源的授權訪問可以提供給在其他領域中管理身份的安全主體。”iii 它由 Microsoft 的 ADFS 服務器支持。 以及許多其他商業 SSO 產品，並提供與 SAML 2.0 的 Web 單點登錄和聯合功能類似的功能。 它已在許多企業環境中使用，並且與 SAML 2.0 一樣，今天仍在許多企業環境中使用。</font>

#### OpenID
起初的OpenID協議以用戶為中心的身分概念而值得一提。因為SAML2.0僅面向員工場景，消費者用戶仍需在面向消費者的網站註冊。為了"以用戶為中心"創建解決方案，因此催生出OpenID協議。除了和SAML 2.0、 WS-Fed相同的由組織控制的IdP外，OpenID還包括用戶控制身分的概念。消費者用戶可以設置自身的IdP並將app指向它已進行身分驗證。起初OpenID並未被廣泛使用，但它確實強大用戶中心的需求，並未OpenID Connect打下基礎。

#### OAuth 2.0
Web2.0和社群媒體下，很多面向消費者的網站建立，用戶可以上傳內容，導致app需要代為取回使用者行為的資料。比方說，FB上的照片，用戶希望用另一個打印網站來訪問。如果沒有更好的方案，用戶不得不和該網站共享社群媒體的憑據。後者被入侵，前者也有風險。前者帳密外洩，後者行為也無法被用戶控制。因此需要一種解決方案，運許用戶授權一個網站從另一個的API上檢索內容，而不用公開憑據。

OAuth協議提供解方。OAuth2.0規範允許用戶授權app，稱為client(打印網站)，該app可以向API，稱為資源伺服器(FB)發送請求，表示在用戶的資源伺服器取回用戶的資料。為此，app與授權伺服器交互，授權伺服器對用戶進行驗證作為同意app取用資源的一部分。app收到一個token，使其能代表用戶調用資源伺服器。OAuth 2.0解決API授權。

#### OpenID Connect (OIDC)

#### Standard Protocols

## 20230116 - Authorization and Policy Enforcement
前面的章節介紹了授權 API 調用和驗證用戶的機制。本章將討論授權與訪問策略的實施以及如何使用身份協議來幫助實施它們。

### Authorization vs. Policy Enforcement
管理使用者、app可以進行的操作有兩個不同的功能。授權(Authorization)一詞表示特權的授予。~~反之~~與其對比，訪問策略實施(Access policy enforcement)定義為"在接受對保護資源的請求前檢查是否被授予必要權限的行為"。比方說購買劇院門票，門票構成可以觀看的授權。演出當天，剪票員通過檢查執行政策，確保有授權的人可以進入。

授權可以在資源被請求前授予。它可以由包含所請求資源的實體或由受信任的第三方完成，並將授權信息安全地傳送到策略執行點。訪問策略的執行是在發出資源請求時完成的，理想情況下是在受保護資源內或附近的執行點執行，以減少它被繞過的可能性。

### 授權和存取政策執行的級別
授權和存取政策執行存在很多不同的級別可以指定或套用。
* 級別一
是否一個實體可以存取一個app或API?
* 級別二
一個實體可以在app或API中使用那些函數?
* 級別三
一個實體可以訪問或操作哪些資料?

#### 級別一 - app或API訪問
在最高級別中，授權和存取政策執行可以控制實體是否有權訪問app或API，這常出現在公司中。比方說一名員工無權訪問會計系統。如Fig8-1呈現，這個政策執行級別可能在app內或藉由一個app前的實體處理。執行可以通過一些組件(比方說驗證代理人或與身分和IAM系統一同工作的反向代理)在app外部執行。這種系統可以以高等級執行點運作，以偏離未被授權的訪問app的用戶。類似的方法可以用於API，兩種情況都有助於減少目標系統上的策略執行工作量。

<center><img src='https://i.imgur.com/S1GbLzn.png'></center>

#### 級別二 - Functional Access
功能級別的授權和存取政策實施管理一個實體可以對app、API做甚麼。比方說財務部門的初級帳號可以存取公司會計系統、輸入單筆記帳，但無法執行月末結算。此級別的授權和存取政策執行傾向於特定於app。它可能利用其他地方儲存的使用者資訊，比方說目錄服務中的角色、組別，但通常在app或API中執行。

#### 級別三 - Data Access
第三級授權和存取策略執行管理對資料的特定子集的存取。當功能集別APE定義實體可以做的功能，資料集別APE進一步限制對特定資料的存取。比方說，一個銷售訂單輸入系統，具有區域銷售經理角色的使用者在功能集別查看銷售訂單，但資料集別限制他們在特定區域。資料集別存取可能在app或API或底層儲存層執行。

### User vs. Application Authorization
需要授權和APE的情況有兩個，第一個是管理用戶在app可以做什麼，第二個是控制app可以請求API做甚麼。

使用者需要授權才能在app執行各種功能。app根據用戶的權限呈現介面，不會顯示無法使用的功能。此外，當使用者發出請求時，app後端或API必須先檢查是否有權限。

appv需要授權才能調用受保護的API。若API內容歸使用者所有，訪問需要用戶的授權。這發生在面相消費者的app中。若app代表自己訪問API，授權伺服器會根據授權伺服器管理員事先配置的權限授權app。

無論被授權的實體為何，控制存取通常包含三步驟:
* 授權和APE
* 授權資訊傳遞到執行點(如果需要)
* APE在執行點被執行
以下會先討論使用者的三步驟，然後再涉及app

### User Authorization
授權規範是複雜的議題。各很多方案被提出，涵蓋超出這本書的內容。作者假設AP以一系列關聯到使用者、app的屬性集合表示，並描述OIDC、SAML2.0如何可以用於傳遞有關一個使用者對一個app授權資訊，以及OAuth2.0如何能被用於授權存取給API和如何支援APE。用於向用戶傳達授權的屬性可以不同，但最常見有兩類。

#### User Profile Attributes
用戶的身分可能根據他們在基於角色的存取控制(role-based access control)模型被分配角色、一個組或訪問控制列表(ACL)的成員身分、基於屬性的存取控制(attribute-based access control)模型中部份的規則所評估的個人使用者配置文件屬性等等授予用戶身分授權。這些屬性為相對靜態、保持一致的要素，無論用戶存取時受保護資源時的所處位置或他們使用的設備。

若這種授權資訊是在app外指定的，例如在一個公司目錄服務或政策服務中，但可以被身分提供者存取用來驗證使用者，這些屬性可以被身分提供者傳遞到app。若授權是在app內指定的，身分提供者可以傳遞一個被驗證使用者的identifier給app，因此它可以取回關於使用者必要的驗證資訊。

授與使用者特權的授權步驟通常在使用向app請求前結束。比方說，一個新雇員加入公司的金融團隊，公司可能藉由宣告一個使用者角色在公司身分系統中以授權該雇員存取它的會計app。對於面向消費者的app，當用戶購買針對服務訂閱的特定級別時，使用者可能被宣告一個存取相關的使用者檔案屬性。

#### Transactional User Attributes
授權也可能基於授權或存取受保護資料時，使用者的物理環境的部分要素。這種要素可以包含使用者的地理位置，是否在公司內、防火牆內，或是否使用者的裝置是經過認證符合安全標準。星期幾或一天中何時也可以是授權機制使用的要素和強度。這些要素在授權時捕捉而非使用者檔案的一部分。這種要素若是由身分提供者捕獲，也可以以安全token的聲明形式提供給app。

#### Delivery
對於使用OIDC的app，使用者授權資訊以ID token中的聲明或OIDC提供者的使用者資訊端點響應傳遞給app。使用SAML2.0的app可藉由SAML2.0斷言中的屬性語句接受資訊。使用者的資訊(比方說使用者角色、組別或購買的訂閱級別)以及要素(使用者IP位置、授權方法強度)可以透過這種方式傳遞給app。一個app隨後可以使用這些資訊去進行APE。一個案例是經由ID token的使用者資訊傳遞去支援access enforcement，如圖8-2。這個案例中，app是一個電影租借app，其中使用者可以購買不同的訂閱級別(金銀銅)以存取不同電影選擇。ID token將訂閱集別傳給app。

<center><img src='https://i.imgur.com/qWyjNJd.png'></center>

1. 使用者被重新導向到OIDC OpenID提供者的登入位置
2. ID Token包含用戶購買的訂閱等級
3. ID Token中的訂閱資料被用於確定顯示的電影列表
4. 用戶選擇要觀看的電影
5. app後端檢查用戶是否具有他選擇電影所需要的訂閱等級

這個範例中，ID Token中關於使用者訂閱等級的資訊用於決定可以呈現給他的電影。它還用於進行APE。儘管前端限制使用者可以看得電影的列表，惡意用戶可能找到方法繞過，所以APE檢查必須在app後端，這裡無法繞過。這個範例使用OIDC，使用SAML2.0的app可以跟隨相同的模型，從SAML2.0斷言獲得授權資料。

#### Enforcement
在依賴安全token中的任何資訊錢，app必須驗證token。對於ID Token的例子，驗證步驟包含
* 驗證ID Token是正確格式的JWT(JSON Web Token)
* 驗證ID Token上的簽名
* 檢查Token是否過期
* 檢查發行的人是正確的OpenID提供者
* 檢查Token的要求是app

務必檢查OpenID提供者的文件，了解其驗證步驟需要的實作。一旦ID Token被驗證，app可以使用token中的聲明執行APE。

### Application Authorization
授權和APE的第二種是app調用API。

#### Application Attributes
app代表用戶呼叫API的請求由用戶授權，但app代表自己呼叫API的請求需要由基於配置的授權伺服器授權。這種政策通常在app呼叫API前配置。除非app或API數量非常龐大，政策規範通常是透過指示授權特定app呼叫特定API以及可以訪問的終端點、行為。若OAuth2.0被使用，政策可能根據scope指定，例如“get:documents”.。

#### Authorization
發出一個OAuth2.0請求以調用API的app指定它所要求的scope為一個授權請求的參數。比方說，app請求對一個OpenID提供者的使用者資訊端點的存取token以取回用戶屬性，它可能使用"scope = openid profile email"。呼叫自定義API以取回用戶文件的app可能要求一個"get:documents"的scope。

通過授權碼和隱式授權類型(implicit grant types)，被請求的API資源被用戶持有，因此OAuth2.0授權伺服器會提示用戶顯示請求的scope，以及在發布access token前獲得用戶對app請求的同意。通過客戶端憑據授予，被請求的API資源由app持有，且授予給每個app的特權在授權伺服器被指定(或從中存取的policy server)。它會在發布access token前使用這個資訊決定是否請求批准。

#### Delivery
無論是否受保護資源屬於用戶還是app，若請求被授權，授權伺服器會發布一個access token給app，允許其調用API。一個授權伺服器可能允許在access token中增加額外的客製化聲明，比方說關於用戶(角色等特權資料)的聲明。額外聲明可能對一個執行存取的API有用。對藉由客製化聲明的可擴展性以及關於用戶的屬性的支援會因授權伺服器實作而有變化。

#### Enforcement
一個API必須驗證access token和進行APE，確保app的請求在響應之前回應其請求。驗證和獲取有關access token資訊的步驟會根據授權伺服器的對access token的實作方式變化。應該查看授權伺服器文件得到如何驗證任何它所發布的token的詳細資訊。一旦access token被驗證，API可以使用token內的資訊，包含任何客製化聲明(如果允許)在響應請求前去執行它的APE。

### Summary
授權包含特權授予，而APE式在資源被請求時進行檢查，以驗證請求者已經被授予所需的特權。授權和APE可能被用於管理使用者是否可以在app做甚麼、app是否可以向API發送請求。
用戶授權可能基於用戶配置文件中的靜態要素，和/或授權時評估的動態要素，兩者都可以由app在安全token中傳送。
app授權可能基於用戶或授權伺服器承認的scope，並體現在傳送給app和用於調用API的access token中。
下一章節中，會討論一個範例app以及它如何結合使用OIDC和OAuth2.0來授權對API的訪問。

### Key Points
* 授權是授予訪問受保護資源的權限
* APE在發出請求時執行，並檢查是否請求者有足夠權限發出請求
* 授權和APE可使用在包含用戶和app呼叫API上
* 對用戶的授權政策可能基於用戶配置文件屬性，或者用戶驗證或發出請求時評估的動態要素
* 對app呼叫API的授權由用戶或授權伺服器授予，取決於使用的OAuth2.0類型
* 授權和APE可以在多個級別執行
* 安全token的聲明可以作為app和API的APE決策基礎

<font color=red></font>
<font color=red></font>
<font color=red></font>