# Authentication BBB
- 驗證裝置及系統的使用者，可有多種身分確認機制，如:
-- [chatGPT](https://chat.openai.com/share/3f6de666-c607-44ae-91c0-27aecdf74749)
-- 使用者帳密驗證，包含登入網站
-- 人員、裝置、使用軟體所屬憑證驗證
-- 身分驗證的 token (ID )
-- FIDO

## FHIR API security
- Authentication : 裝置及人員Authentication
-- 裝置可配合雙向 SSL
-- 人員 some thing you have ,some thing you know
- Authentication 後，到 aothorization server 取得 JWT Token
### 簡單情境
- 現行系統都有人員管理及資安機制
- 可在現行系統微調擴充，避免增加開發者及使用者負擔
- 若現行系統 可改善

### 網頁系統
- 輸入帳密 (可為現行系統認證及發放憑證 JWT token)
- 返還 JWT token (直接或 email)
- RESTful HTTP request with token
### 手機 APP
- 認證
- 返還 JWT token，手機或安全雲端存放
-

## google authentication
https://cloud.google.com/api-gateway/docs/authenticating-users-jwt

## 網站帳密驗證

https://hackmd.io/MiQSCwx5Q1GSHFnuYJ-2lw?view

: European Federation for Cancer Images
https://cancerimage.eu/wp-content/uploads/2024/02/D6.1_final.pdf

oauth2 password credentials flow
https://blog.yorkxin.org/posts/oauth2-4-3-resource-owner-credentials-grant-flow/

https://auth0.com/docs/get-started/authentication-and-authorization-flow/resource-owner-password-flow


https://oauth.net/2/grant-types/password/

This flow provides no mechanism for things like multifactor authentication or delegated accounts, so is quite limiting in practice.
慈大 google 認證 登入 moodle

## Authentication(認證) 與 portal 的關係
- Patient portal
-- 提供跨系統、跨機構之文件及服務索引
-- 人員及腳色權限
- Authentication(認證)
-- 身分確認，可有多種機制
-- 近端(如個人、居家、機構、社曲)、普及與雲端(如 google)、portal 提供之身分驗證等機制
- 運作機制: 採用某種驗證機制，身分驗證後，取得標準之 JWT ID token。配合此 token ，連上 portal，模式:
-- A 回應可用服務列表
--- 在選擇特定服務 ID，回應服務 URL 及 Access token
-- B 直接向 portal 傳輸 ID token 及服務 ID，回應服務 URL 及 Access token
- EEEEEEEEEEEEEE
- portal 基於 ID token，判斷其擁有的功能
-- 可回應可
-

## 事前工作

## 管理人員、組織、裝置、帳密、及憑證
- 需先建立管理人員、組織、裝置、帳密、及憑證管理，方能進行身分確認
-- 人員、組織、裝置管理
-- 帳密管理
-- 憑證管理

## 應用情境
- 人員使用 openid 認證，產生 oAuth token，再使用此 token 連結到各服務伺服器及系統。
- 認證網頁、APP、物聯網裝置連結 FHIR 伺服器
- 參考 oAuth， 但 token 需有標準規格

## 以使用者所屬單位慣用系統進行認證，並產生 token

## 認證機制標準化需求
- 認證需搭配人員、裝置、及系統管理，由各機構自行管理較恰當
- 認證 token 可由各機構採用的認證伺服器發放
-- 但目前各式認證伺服器產生之**oAuth token 規格不一**
- FHIR 儲存庫需要**標準的 token 規格**，方利於其認證、及存取管控
- 某些應用情境， token 需人員識別資訊，以利稽核

## 建議的規格
JSON Web Token(JWT)，如 [英國 NHS 範例](
https://digital.nhs.uk/developer/guides-and-documentation/security-and-authorisation/user-restricted-restful-apis-nhs-login-separate-authentication-and-authorisation#step-6-generate-a-client-assertion)

## 腳色定義
- Authentication server(認證伺服器)
- Authorization server(授權伺服器)
- Web service servers and repositories
- Resource owner (內容擁有者): 內容所屬之人員或組織
- User (使用者): 被授權的使用人員或組織
- HTTP client system(裝置)
-- user 使用的 HTTP client 系統
--- 如瀏覽器、手機或電腦 APP、可直接連網之物連網裝置(如智慧手表、[PHG](https://hackmd.io/0JUUveCYT7qftYvPwukKWQ?view#IoMT))
-

### 基於已被授權之 documentReference ，向授權伺服器提出授權 token request
- 網頁調閱已被授權之 documentReference
-- 由 人員 id 及目前扮演的腳色查詢
-

## 授權內容與對象
Observation.performer
Condition.asserter
Procedure.asserter

****

## 討論議題
1. 如何建立易於維護及使用的雙因認證
-- 包含的因子:
--- 個人擁有
---- 密碼、手機、IC 卡、生物特徵等
--- 機構裝置
---- 電腦、感應裝置、網域、hub...
-- 須配合應用情境:電腦前工作、機構內移動場域、在家工作建立認證機制
2. 帳密、IC 卡、生物特徵、裝置、憑證管理
-- 使用 FHIR person、media(紀錄相片、影音、及其特徵)、PractitionerRole、Device
-- 配合人員異動、就醫(活動參與)流程
--- FHIR administration , appoint and encounter
3. 可現行機構系統擴充建構 authentication server (分散式登入入口)
-- 不使用外部 authentication server portal，如 google gmail 驗證
--- 好處
---- 可搭配機構人員異動流程
---- 搭配機構裝置及系統管理
---- 機構內成員可用現行驗證機制取得 openid
--- 缺點
---- 機構需維護 authentication server (小診所或家戶或可合作建置)
---- 需考慮機構外服務驗證自建之 authentication server openid
-- 機構內外 authentication server 可否同時存在?
4. 機構驗證後登入外部系統
-- 如 github, gmail...
5. 考慮到機構正式及臨時人員
-- 臨時人員: 病人及家屬、參訪人員、外部合作人員
6. 建構應用評估系統

## 參考資料
-https://www.hl7.org/fhir/security.html#authentication
- https://blog.restcase.com/4-most-used-rest-api-authentication-methods/