# Using JWT authentication and authorization tokens for integrated helathcare web applications ## Introduction - oAuth 及 open ID connect 常被用來在做系統整合之authentication and authorization. 這也很有潛力用於健康醫療領域，進行醫護人員或民眾使用系統之認證授權。 -- 但由於常見之健康醫療跨系統合作的過程，通常是 A 醫院資料授權給 B 醫院使用、醫院將資料授權民眾、或民眾授權某健康醫療應用，這應用情境(資料擁有者授權其他人員調閱資料)與目前 oAuth 規範主要針對的情境(可參考 IETF oAuth 原始文件):資料擁有者授權其伺服器端內容給另一應用軟體使用的情境不同。 --- **目前 smart on FHIR 參考此規範，授權其他 APP (同一使用者)存取 FHIR server 資料，這與電子病歷互通所需的授權情境並不相同** - 本文件基於 [IHE Internet User Authentication (IUA) 病歷互通授權架構](https://profiles.ihe.net/ITI/IUA/index.html#341-iua-actors-transactions-and-content-modules) 明訂使用者認證 JWT token 及病歷文件調閱 JWT token 規格 --- 雖然 smart on FHIR 是目前市場主流，但 [IHE IUA 有說其授權標準規範與 smart on FHIR 的差異，及為何要採 IHE IUA 授權機制](https://profiles.ihe.net/ITI/IUA/index.html#relation-to-smart-on-fhir) - 另外，IT 領域的專家通常並不太熟悉健康醫療需求及醫資標準。要辛苦的醫資系統開發人員讀通 oAuth 文件、熟悉醫資標準、了解目前公告之 FHIR security (僅有通用概述)，以此整理出合乎其發展系統使用情境之標準化認證授權機制，其挑戰度很大。 - 本規範基於 IHE XDS 及 IUA 電子病歷跨互通及授權規範，明定 ID token (使用者認證)及 Access token(病歷調閱) 規範，以配合病索引及授權伺服器，發放認證及授權 token 給 client 端應用系統。 以此利於 client 端應用系統存取各式雲端伺服器之健康醫療資料。 ## [XDS on FHIR system integration framework](https://hackmd.io/3-YA4NIlSduzirHccnIq6A?view) ## Token granting, access, using, and validation processing ![](https://i.imgur.com/bX6XwJ0.png) - 如上示意圖，認證及授權 token 整合應用架構中包含: Portal、Web application and repository(含 token validator)、HTTP client 三個子系統，其運作步驟如下: -1. HTTP client 向 Portal 進行 authentication，認證成功(註1,2) ，方可進行步驟 2. -2. HTTP client 向 Portal 請求 JWT token(註 3) -3. HTTP client 啟動 HTTP request (HTTP request header 中包含 JWT token) 向 Web application and repository 存取資料及服務 -3.1. Token validator 驗證 JWT token (註 4)，若成功，redirest 向 Web application and repository 要求提供服務，並接收內部伺服器回應的結果，再將結果回應給HTTP client 註: 1. Portal 須具備 Document and application registry, person and device manager, granting server, authenticator, and token provider等功能及子系統，其功能說明後續再補充 2. HTTP client 向 Portal 進行authentication，這可包含 client 端的系統、裝置、及使用者的驗證。這需有合適地安全機制，但其做法不在本文件探討範圍 3. Web application and repository 與 Token validator，有可能是同一套系統，也有可能是不同系統，但必須保護其傳遞的資訊(如在內部網路當中)，不讓外部擷取竊聽 4. Token 在 client 端傳送及存放過程，必須有洽當的安全保護機制。這可因應 client 種類(瀏覽器、手機或電腦 APP、醫療儀器、穿戴式裝置)，所處地點(醫療端、照護端、居家端)，及應用情境建立方便且安全的管理機制 5. **Granting(授予)、Authorization(授權) 這兩個詞彙常在 Web applications access control(存取控制) 規範文件當中出現，但其中英文的意義很相近。在抽象的規範文件中，這兩個詞彙常讓人搞混。上圖所提具體的系統整合架構，採用 Granting、get JWT token、Token validation 等詞彙，以清楚描述此架構 web 儲存庫的資料調閱存取控制過程，如下名詞定義說明:** ## 名詞定義說明 (需先加入一張 XDS on FHIR 架構圖) - Granting : 授予某一對象調閱儲存庫某份資料的權限 - Get jwt token: HTTP client 向 portal 請求及取得身分驗證ID token 或授權 Access token -- Portal 可基於Authorization 後 client 的身分，及授予(Granting) 之文件紀錄 - Token validation: repository 端驗證 Token - Document owner: 文件擁有者，授權其他使用者調閱文件。 先簡化情境，假設文件上傳者即為文件用有者 - Document counsumer: 文件調閱者(再補充) - (其他腳色說明再補充) ## 運作流程 - 包含上傳、授權(grainting)、查尋、Token 請求、調閱等步驟 ## Document granting - 基於某一 documentReference 及其指定的文件，Document owner 賦予 Document counsumer 在 portal 當中查詢此文件及請求此文件 access token 的權限，建議步驟: -1. owner 查詢 (或配合自動化流程) 選擇某 documentReference -2. 在使用介面 (或配合自動化流程) 指定 ## Type of JWT token - 上述架構發放的 Token 可為認證token(ID token) 或授權token(Access token) -- [ID token](https://hackmd.io/1V7FENfrSvGXVT8ecE5oYg?view) : 以此進入 web 系統，系統可有 RBAC 功能；可基於使用之 ID ，判斷其所屬腳色， 決定提供那些 web 服務 -- [Access token](https://hackmd.io/ede0fObcTcOiq5CovjKvBQ?view): 由此 token 決定可增修改查 Web application and repository 之服務(如 RESTful APIs) 或管理的資料 --- 基於 XDS on FHIR 交換之 FHIR document 及其在 portal registried documentReference，可授權 HTTP client 可調閱在 document repository 中特定的文件。可以此 FHIR 病歷授權調閱情境，明定 FHIR document access token 規格，以及 Web application and repository 當中 token validator validates access token 的步驟 ## 授權類別 - 授權使用者可用那些網頁或 APP 功能 - 授權他人調閱(不限定使用何種 APP)個人健康紀錄 - **授權 APP 存取資料擁有者(個人或機構)健康紀錄** - **指定特定系統存取特定人員、特定 resources 的 API** ## Steps for token validation and HTTP request access control ## Token specification 岳勳、彬彬提供 ## JWT token 驗證機制 Client 端向 server(token validator) 調閱存取資料時，其 HTTP header 必須包含 JWT token，server 收到 HTTP 請求後，必須檢查 JWT token 的簽章是否合法，payload 各參數與此 HTTP請求是否相符正確，以及 HTTP請求是否合乎 JWT token scope 範圍。其檢查步驟概述如下: 0. mTLS client 憑證與 JWT 當中指定的憑證 hash 值使否相符 1. Resource server 以portal公鑰驗證token 簽章是否正確(驗證JWT.signature) 2. 檢查iss、aud、iat、exp、ndf等參數是否與目前之 HTTP 連結相關資訊相符 3. (o) 檢查 HTTP request 與 scope 是否相符 其中 1,2 項次為通用的查驗項目，這可有通用的機制(在健康醫療及其他領域)來檢查 JWT token 是否有效，及現行 HTTP request 是否與 JWT payload 指定的參數相符。 -- [岳勳 2021 WG1 Token](https://hackmd.io/@kan71462/HJgnPeprK)