@xdev-asia/xdev-knowledge-mcp 1.0.38 → 1.0.40

package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/01-phan-1-kien-truc-nen-tang/lessons/04-bai-4-threat-modeling-stride-dread.md

@@ -27,19 +27,7 @@ course:
 
 ### 1.1. Quy trình Threat Modeling
 
-```
-┌──────────────────────────────────────────────────────────┐
-│                  Threat Modeling Process                   │
-│                                                           │
-│  1. Define Scope ──▶ 2. Decompose ──▶ 3. Identify       │
-│     & Objectives      Application       Threats          │
-│         │                                    │           │
-│         │              ┌─────────────────────┘           │
-│         │              ▼                                  │
-│         └──────── 6. Validate ◀── 5. Rate   ◀── 4. Mitigate │
-│                    & Iterate      Threats        Threats  │
-└──────────────────────────────────────────────────────────┘
-```
+![Quy trình Threat Modeling 6 bước — từ Define Scope đến Validate & Iterate](/storage/uploads/2026/04/healthcare-threat-modeling-process.png)
 
 ### 1.2. Khi nào cần Threat Modeling?
 
@@ -68,58 +56,46 @@ STRIDE là framework phân loại threats do Microsoft phát triển:
 
 #### S - Spoofing (Giả mạo danh tính)
 
-```
-Threat: Attacker giả mạo JWT token để truy cập Patient API
-───────────────────────────────────────────────────────────
-Attack Vector:
-  1. Steal JWT từ browser localStorage
-  2. Forge JWT với modified claims (role: "admin")
-  3. Replay expired token
-
-Affected Components:
-  - API Gateway
-  - Patient Service
-  - Clinical Service
-
-Mitigations:
-  ┌────────────────────────────────────────────┐
-  │ M1: Keycloak OIDC token validation         │
-  │     → quarkus-oidc auto-verifies signature │
-  │                                             │
-  │ M2: Short-lived access tokens (5 min)      │
-  │     → Reduce token theft window            │
-  │                                             │
-  │ M3: DPoP (Proof-of-Possession)             │
-  │     → Token bound to client certificate    │
-  │                                             │
-  │ M4: Refresh token rotation                 │
-  │     → One-time use refresh tokens          │
-  │                                             │
-  │ M5: mTLS between services                  │
-  │     → Service identity verification        │
-  └────────────────────────────────────────────┘
-```
+![Spoofing Attack — giả mạo JWT token để truy cập Patient API và các biện pháp phòng chống](/storage/uploads/2026/04/healthcare-stride-spoofing-attack.png)
+
+**Threat:** Attacker giả mạo JWT token để truy cập Patient API
+
+**Attack Vector:**
+
+1. Steal JWT từ browser localStorage
+2. Forge JWT với modified claims (role: "admin")
+3. Replay expired token
+
+**Affected Components:** API Gateway, Patient Service, Clinical Service
+
+**Mitigations:**
+
+- **M1:** Keycloak OIDC token validation — quarkus-oidc auto-verifies signature
+- **M2:** Short-lived access tokens (5 min) — giảm token theft window
+- **M3:** DPoP (Proof-of-Possession) — token bound to client certificate
+- **M4:** Refresh token rotation — one-time use refresh tokens
+- **M5:** mTLS between services — service identity verification
 
 #### T - Tampering (Giả mạo dữ liệu)
 
-```
-Threat: Insider sửa đổi kết quả xét nghiệm trong lab_db
-───────────────────────────────────────────────────────────
-Attack Vector:
-  1. DBA trực tiếp UPDATE lab_results table
-  2. Khai thác SQL injection để sửa dữ liệu
-  3. Intercept và modify API response
-
-Mitigations:
-  ┌────────────────────────────────────────────┐
-  │ M1: pgAudit logging (log all DML)          │
-  │ M2: Database triggers cho change tracking  │
-  │ M3: Digital signatures cho lab results     │
-  │ M4: Immutable audit log (append-only)      │
-  │ M5: Dual control cho critical changes      │
-  │ M6: Row versioning with checksums          │
-  └────────────────────────────────────────────┘
-```
+![Tampering Attack — insider sửa đổi kết quả xét nghiệm và các biện pháp bảo vệ tính toàn vẹn dữ liệu](/storage/uploads/2026/04/healthcare-stride-tampering-integrity.png)
+
+**Threat:** Insider sửa đổi kết quả xét nghiệm trong lab_db
+
+**Attack Vector:**
+
+1. DBA trực tiếp UPDATE lab_results table
+2. Khai thác SQL injection để sửa dữ liệu
+3. Intercept và modify API response
+
+**Mitigations:**
+
+- **M1:** pgAudit logging (log all DML)
+- **M2:** Database triggers cho change tracking
+- **M3:** Digital signatures cho lab results
+- **M4:** Immutable audit log (append-only)
+- **M5:** Dual control cho critical changes
+- **M6:** Row versioning with checksums
 
 ```sql
 -- Integrity protection: Row versioning with checksum
@@ -227,25 +203,25 @@ public PatientSummaryDTO getPatient(@PathParam("id") UUID id) {
 
 #### D - Denial of Service
 
-```
-Threat: Tấn công DDoS khiến hệ thống cấp cứu ngừng hoạt động
-───────────────────────────────────────────────────────────
-Impact trong Y Tế:
-  - Không thể tra cứu dị ứng thuốc → kê đơn sai → nguy hiểm
-  - Không truy cập được lab results → chẩn đoán chậm
-  - Hệ thống đặt lịch down → bệnh nhân không thể đến khám
-
-Mitigations:
-  ┌────────────────────────────────────────────┐
-  │ M1: Rate limiting at API Gateway           │
-  │ M2: Circuit breaker (Quarkus Fault Toler.) │
-  │ M3: Auto-scaling Kubernetes pods           │
-  │ M4: CDN/WAF (Cloudflare, AWS Shield)       │
-  │ M5: Database connection pooling            │
-  │ M6: Fallback mode / offline capability     │
-  │ M7: Priority queuing for ER requests       │
-  └────────────────────────────────────────────┘
-```
+![DoS mitigation — 7 lớp bảo vệ chống DDoS cho hệ thống y tế](/storage/uploads/2026/04/healthcare-stride-dos-mitigation.png)
+
+**Threat:** Tấn công DDoS khiến hệ thống cấp cứu ngừng hoạt động
+
+**Impact trong Y Tế:**
+
+- Không thể tra cứu dị ứng thuốc → kê đơn sai → nguy hiểm
+- Không truy cập được lab results → chẩn đoán chậm
+- Hệ thống đặt lịch down → bệnh nhân không thể đến khám
+
+**Mitigations:**
+
+- **M1:** Rate limiting at API Gateway
+- **M2:** Circuit breaker (Quarkus Fault Tolerance)
+- **M3:** Auto-scaling Kubernetes pods
+- **M4:** CDN/WAF (Cloudflare, AWS Shield)
+- **M5:** Database connection pooling
+- **M6:** Fallback mode / offline capability
+- **M7:** Priority queuing for ER requests
 
 #### E - Elevation of Privilege
 
@@ -349,39 +325,28 @@ public class PrescriptionResource {
 
 ### 5.1. Attack Tree: Steal Patient Medical Records
 
-```
-Goal: Steal Patient Medical Records
-│
-├── 1. External Attack
-│   ├── 1.1 Exploit Web Application
-│   │   ├── 1.1.1 SQL Injection [DREAD: 8.6] ★
-│   │   ├── 1.1.2 XSS to steal session [DREAD: 7.2]
-│   │   └── 1.1.3 IDOR to access other patients [DREAD: 7.0]
-│   │
-│   ├── 1.2 Compromise Authentication
-│   │   ├── 1.2.1 Credential stuffing [DREAD: 5.4]
-│   │   ├── 1.2.2 Phishing doctor credentials [DREAD: 6.8]
-│   │   └── 1.2.3 Brute force Keycloak [DREAD: 3.2]
-│   │
-│   └── 1.3 Network Attack
-│       ├── 1.3.1 MITM on API calls [DREAD: 4.6]
-│       └── 1.3.2 DNS spoofing [DREAD: 4.2]
-│
-├── 2. Internal Attack (Insider Threat)
-│   ├── 2.1 Privileged User Abuse
-│   │   ├── 2.1.1 DBA exports database [DREAD: 6.8]
-│   │   ├── 2.1.2 Admin disables audit [DREAD: 5.6]
-│   │   └── 2.1.3 Doctor accesses non-patient [DREAD: 6.0]
-│   │
-│   └── 2.2 Stolen Credentials
-│       ├── 2.2.1 Shared workstation session [DREAD: 6.2]
-│       └── 2.2.2 Post-it password [DREAD: 5.0]
-│
-└── 3. Supply Chain Attack
-    ├── 3.1 Compromised dependency [DREAD: 7.8]
-    ├── 3.2 Malicious Docker image [DREAD: 6.4]
-    └── 3.3 Compromised CI/CD pipeline [DREAD: 7.0]
-```
+![Attack Tree — các vector tấn công đánh cắp hồ sơ bệnh nhân với DREAD scoring](/storage/uploads/2026/04/healthcare-attack-tree.png)
+
+**Goal: Steal Patient Medical Records**
+
+| Attack Path | DREAD | Priority |
+|---|---|---|
+| 1.1.1 SQL Injection | 8.6 | CRITICAL |
+| 1.1.2 XSS to steal session | 7.2 | HIGH |
+| 1.1.3 IDOR to access other patients | 7.0 | HIGH |
+| 1.2.1 Credential stuffing | 5.4 | MEDIUM |
+| 1.2.2 Phishing doctor credentials | 6.8 | HIGH |
+| 1.2.3 Brute force Keycloak | 3.2 | LOW |
+| 1.3.1 MITM on API calls | 4.6 | MEDIUM |
+| 1.3.2 DNS spoofing | 4.2 | MEDIUM |
+| 2.1.1 DBA exports database | 6.8 | HIGH |
+| 2.1.2 Admin disables audit | 5.6 | MEDIUM |
+| 2.1.3 Doctor accesses non-patient | 6.0 | MEDIUM |
+| 2.2.1 Shared workstation session | 6.2 | MEDIUM |
+| 2.2.2 Post-it password | 5.0 | MEDIUM |
+| 3.1 Compromised dependency | 7.8 | HIGH |
+| 3.2 Malicious Docker image | 6.4 | HIGH |
+| 3.3 Compromised CI/CD pipeline | 7.0 | HIGH |
 
 ## 6. Từ Threat Model đến Security Requirements
 

package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/02-phan-2-iam-keycloak/lessons/01-bai-5-setup-keycloak-realm-benh-vien.md

@@ -26,46 +26,13 @@ course:
 
 Khi xây dựng hệ thống y tế cho nhiều bệnh viện/phòng khám, có 3 chiến lược:
 
-```
-Strategy A: Realm per Hospital (Isolation cao)
-┌───────────────────────────────────────────┐
-│ Keycloak Instance                         │
-│  ┌──────────┐ ┌──────────┐ ┌──────────┐  │
-│  │ BV Chợ   │ │ BV Bình  │ │ BV Nhân  │  │
-│  │ Rẫy      │ │ Dân      │ │ Dân 115  │  │
-│  │ Realm    │ │ Realm    │ │ Realm    │  │
-│  └──────────┘ └──────────┘ └──────────┘  │
-│  → Isolated users, roles, clients         │
-│  → Best for: Independent hospitals        │
-└───────────────────────────────────────────┘
-
-Strategy B: Shared Realm + Organizations (Keycloak 26+)
-┌───────────────────────────────────────────┐
-│ Keycloak Instance                         │
-│  ┌──────────────────────────────────────┐ │
-│  │         Healthcare Realm              │ │
-│  │  ┌─────────┐ ┌─────────┐ ┌────────┐  │ │
-│  │  │ Org:    │ │ Org:    │ │ Org:   │  │ │
-│  │  │ BV CR   │ │ BV BD   │ │ BV ND  │  │ │
-│  │  └─────────┘ └─────────┘ └────────┘  │ │
-│  │  → Shared identity + org isolation    │ │
-│  │  → Best for: Hospital networks        │ │
-│  └──────────────────────────────────────┘ │
-└───────────────────────────────────────────┘
-
-Strategy C: Shared Realm + Groups (Simple)
-┌───────────────────────────────────────────┐
-│ Keycloak Instance                         │
-│  ┌──────────────────────────────────────┐ │
-│  │         Healthcare Realm              │ │
-│  │  Groups: /hospitals/bv-cho-ray        │ │
-│  │          /hospitals/bv-binh-dan       │ │
-│  │          /hospitals/bv-nhan-dan       │ │
-│  │  → Simple, less isolation             │ │
-│  │  → Best for: Small clinic networks    │ │
-│  └──────────────────────────────────────┘ │
-└───────────────────────────────────────────┘
-```
+![3 chiến lược Keycloak Multi-tenancy cho hệ thống đa bệnh viện](/storage/uploads/2026/04/healthcare-keycloak-multitenancy.png)
+
+| Strategy | Mô hình | Isolation | Phù hợp |
+|----------|---------|-----------|----------|
+| **A: Realm per Hospital** | Mỗi bệnh viện 1 Realm riêng | Cao nhất — isolated users, roles, clients | Bệnh viện độc lập |
+| **B: Shared Realm + Organizations** | 1 Healthcare Realm, mỗi BV là 1 Organization | Trung bình — shared identity + org isolation | Chuỗi bệnh viện, Sở Y tế |
+| **C: Shared Realm + Groups** | 1 Realm, phân chia bằng Groups | Thấp — simple, less isolation | Phòng khám nhỏ |
 
 ### 1.2. Khuyến nghị cho Y Tế Việt Nam
 
@@ -143,29 +110,23 @@ Strategy C: Shared Realm + Groups (Simple)
 
 ### 3.1. Clients Overview
 
-```
-┌─────────────────────────────────────────────────────┐
-│              Healthcare Keycloak Clients              │
-├─────────────────────┬───────────────────────────────┤
-│ Client              │ Type        │ Description      │
-├─────────────────────┼─────────────┼─────────────────┤
-│ his-web-app         │ Public      │ HIS Web Frontend │
-│ emr-web-app         │ Public      │ EMR Web Frontend │
-│ patient-portal      │ Public      │ Patient Portal   │
-│ mobile-doctor-app   │ Public      │ Doctor Mobile App│
-│ patient-service     │ Confidential│ Patient API      │
-│ clinical-service    │ Confidential│ Clinical API     │
-│ lab-service         │ Confidential│ Lab Results API  │
-│ pharmacy-service    │ Confidential│ Pharmacy API     │
-│ scheduling-service  │ Confidential│ Scheduling API   │
-│ billing-service     │ Confidential│ Billing API      │
-│ notification-service│ Confidential│ Notifications    │
-│ audit-service       │ Confidential│ Audit/Logging    │
-│ api-gateway         │ Confidential│ Kong/APISIX      │
-│ admin-cli           │ Confidential│ Admin Operations │
-│ fhir-server         │ Confidential│ HAPI FHIR Server │
-└─────────────────────┴─────────────┴─────────────────┘
-```
+| Client | Type | Description |
+|--------|------|-------------|
+| his-web-app | Public | HIS Web Frontend |
+| emr-web-app | Public | EMR Web Frontend |
+| patient-portal | Public | Patient Portal |
+| mobile-doctor-app | Public | Doctor Mobile App |
+| patient-service | Confidential | Patient API |
+| clinical-service | Confidential | Clinical API |
+| lab-service | Confidential | Lab Results API |
+| pharmacy-service | Confidential | Pharmacy API |
+| scheduling-service | Confidential | Scheduling API |
+| billing-service | Confidential | Billing API |
+| notification-service | Confidential | Notifications |
+| audit-service | Confidential | Audit/Logging |
+| api-gateway | Confidential | Kong/APISIX |
+| admin-cli | Confidential | Admin Operations |
+| fhir-server | Confidential | HAPI FHIR Server |
 
 ### 3.2. Patient Portal Client (Public)
 
@@ -400,27 +361,15 @@ Realm Roles:
 
 ### 6.2. Shared Workstation Support
 
-```
-Bệnh viện thường có shared workstations — nhiều bác sĩ/y tá
-dùng chung 1 máy tính. Giải pháp:
-
-┌──────────────────────────────────────────────┐
-│ Option 1: Fast User Switching               │
-│ → Keycloak short session + badge login       │
-│ → Pro: Nhanh, tiện lợi                      │
-│ → Con: Cần infrastructure (badge reader)     │
-├──────────────────────────────────────────────┤
-│ Option 2: Auto-logoff + Quick re-auth       │
-│ → Session timeout 10-15 min + PIN            │
-│ → Pro: Simple, no hardware needed            │
-│ → Con: Slower than badge                     │
-├──────────────────────────────────────────────┤
-│ Option 3: Virtual Desktop (VDI)             │
-│ → Each user has own virtual desktop          │
-│ → Pro: Full isolation                        │
-│ → Con: Expensive, higher latency             │
-└──────────────────────────────────────────────┘
-```
+Bệnh viện thường có shared workstations — nhiều bác sĩ/y tá dùng chung 1 máy tính. Giải pháp:
+
+![3 phương án xác thực trên shared workstation bệnh viện](/storage/uploads/2026/04/healthcare-shared-workstation-auth.png)
+
+| Option | Cơ chế | Ưu điểm | Hạn chế |
+|--------|---------|---------|----------|
+| **1. Fast User Switching** | Keycloak short session + badge login | Nhanh, tiện lợi | Cần infrastructure (badge reader) |
+| **2. Auto-logoff + Quick re-auth** | Session timeout 10-15 min + PIN | Simple, no hardware needed | Chậm hơn badge |
+| **3. Virtual Desktop (VDI)** | Mỗi user 1 virtual desktop riêng | Full isolation | Đắt, higher latency |
 
 ## 7. Realm Export/Import Automation
 

package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/02-phan-2-iam-keycloak/lessons/02-bai-6-phan-quyen-rbac-abac.md

@@ -23,7 +23,6 @@ course:
 
 ![Kiến trúc 4 lớp kiểm soát truy cập: RBAC, ABAC, RLS, Patient Consent](/storage/uploads/2026/04/healthcare-rbac-abac-layers.png)
 
-
 ### 1.1. Role-Based Access Control (RBAC)
 
 RBAC gán quyền dựa trên **vai trò** của người dùng trong tổ chức:
@@ -58,28 +57,12 @@ Policy: ALLOW if
 
 ### 1.3. Kết hợp RBAC + ABAC cho Y Tế
 
-```
-┌──────────────────────────────────────────────────────┐
-│              Healthcare Access Decision               │
-│                                                       │
-│  Layer 1: RBAC (Keycloak Roles)                      │
-│  ├── Is user a doctor? → Can access clinical data     │
-│  ├── Is user a nurse? → Can access vital signs        │
-│  └── Is user a patient? → Can access own records      │
-│                                                       │
-│  Layer 2: ABAC (Keycloak Authorization Services)     │
-│  ├── Department match? → Only own department data     │
-│  ├── Treatment relationship? → Assigned patients only │
-│  ├── Time-based? → After-hours requires MFA           │
-│  └── Location-based? → External requires VPN          │
-│                                                       │
-│  Layer 3: RLS (PostgreSQL Row-Level Security)        │
-│  └── Database enforces per-row access based on JWT    │
-│                                                       │
-│  Layer 4: Consent (Patient consent check)            │
-│  └── Patient has granted access for this purpose?     │
-└──────────────────────────────────────────────────────┘
-```
+| Layer | Tên | Cơ chế | Ví dụ |
+|-------|-----|---------|--------|
+| **Layer 1** | RBAC (Keycloak Roles) | Is user a doctor? → Can access clinical data. Is user a nurse? → Can access vital signs. Is user a patient? → Can access own records. | `@RolesAllowed("doctor")` |
+| **Layer 2** | ABAC (Keycloak Authorization Services) | Department match? → Only own department data. Treatment relationship? → Assigned patients only. Time-based? → After-hours requires MFA. Location-based? → External requires VPN. | Custom policies |
+| **Layer 3** | RLS (PostgreSQL Row-Level Security) | Database enforces per-row access based on JWT claims | `CREATE POLICY` |
+| **Layer 4** | Consent (Patient consent check) | Patient has granted access for this purpose? | FHIR Consent resource |
 
 ## 2. Keycloak Authorization Services
 

package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/02-phan-2-iam-keycloak/lessons/03-bai-7-smart-on-fhir-oauth2-oidc.md

@@ -23,7 +23,6 @@ course:
 
 ![SMART on FHIR Launch Flow — OAuth2/OIDC qua Keycloak cho EHR](/storage/uploads/2026/04/healthcare-smart-fhir-launch-flow.png)
 
-
 ### 1.1. SMART là gì?
 
 **SMART (Substitutable Medical Applications, Reusable Technologies)** on FHIR là một tiêu chuẩn mở cho phép các ứng dụng third-party truy cập dữ liệu y tế một cách an toàn thông qua FHIR APIs. SMART định nghĩa:
@@ -35,41 +34,31 @@ course:
 
 ### 1.2. SMART App Launch Flows
 
-```
-┌──────────────────────────────────────────────────────┐
-│               EHR Launch Flow                         │
-│                                                       │
-│ 1. User clicks "Launch App" in EHR                   │
-│ 2. EHR sends launch request with context              │
-│    (patient ID, encounter ID)                        │
-│ 3. App redirects to Authorization Server (Keycloak)  │
-│ 4. User authenticates (or SSO)                       │
-│ 5. Keycloak issues access token with SMART scopes    │
-│ 6. App uses token to access FHIR resources           │
-└──────────────────────────────────────────────────────┘
-
-┌──────────────────────────────────────────────────────┐
-│            Standalone Launch Flow                     │
-│                                                       │
-│ 1. User opens app directly (e.g., mobile app)        │
-│ 2. App redirects to Keycloak for authentication      │
-│ 3. User authenticates with credentials + MFA         │
-│ 4. App requests SMART scopes                         │
-│ 5. If patient context needed → patient picker        │
-│ 6. Keycloak issues access token                      │
-│ 7. App accesses FHIR resources                       │
-└──────────────────────────────────────────────────────┘
-
-┌──────────────────────────────────────────────────────┐
-│       Backend Services Authorization                  │
-│                                                       │
-│ 1. Service authenticates with signed JWT assertion   │
-│ 2. Keycloak validates JWT and issues access token    │
-│ 3. Service accesses FHIR resources                   │
-│ → No user interaction required                       │
-│ → Used for: data sync, analytics, reporting          │
-└──────────────────────────────────────────────────────┘
-```
+**EHR Launch Flow:**
+
+1. User clicks "Launch App" in EHR
+2. EHR sends launch request with context (patient ID, encounter ID)
+3. App redirects to Authorization Server (Keycloak)
+4. User authenticates (or SSO)
+5. Keycloak issues access token with SMART scopes
+6. App uses token to access FHIR resources
+
+**Standalone Launch Flow:**
+
+1. User opens app directly (e.g., mobile app)
+2. App redirects to Keycloak for authentication
+3. User authenticates with credentials + MFA
+4. App requests SMART scopes
+5. If patient context needed → patient picker
+6. Keycloak issues access token
+7. App accesses FHIR resources
+
+**Backend Services Authorization:**
+
+1. Service authenticates with signed JWT assertion
+2. Keycloak validates JWT and issues access token
+3. Service accesses FHIR resources
+→ No user interaction required. Used for: data sync, analytics, reporting.
 
 ## 2. SMART Scopes
 

package/content/series/architecture/xay-dung-he-thong-y-te-microservices/chapters/02-phan-2-iam-keycloak/lessons/04-bai-8-mfa-passkeys-emergency-access.md

@@ -23,7 +23,6 @@ course:
 
 ![Ma trận MFA cho nhân viên y tế — Passkeys, TOTP, Emergency Access](/storage/uploads/2026/04/healthcare-mfa-decision-matrix.png)
 
-
 ### 1.1. Thách thức MFA trong Bệnh viện
 
 Bệnh viện có môi trường vận hành đặc biệt so với doanh nghiệp thông thường:
@@ -38,28 +37,13 @@ Bệnh viện có môi trường vận hành đặc biệt so với doanh nghi
 
 ### 1.2. MFA Factor Matrix
 
-```
-┌──────────────────────────────────────────────────────────┐
-│               Healthcare MFA Decision Matrix              │
-├──────────────┬───────────┬────────────┬──────────────────┤
-│ User Type    │ Primary   │ Secondary  │ Fallback          │
-├──────────────┼───────────┼────────────┼──────────────────┤
-│ Doctor       │ Passkey/  │ TOTP App   │ Recovery codes    │
-│              │ WebAuthn  │            │                    │
-├──────────────┼───────────┼────────────┼──────────────────┤
-│ Nurse        │ Proximity │ PIN (6     │ TOTP App          │
-│              │ Badge     │ digits)    │                    │
-├──────────────┼───────────┼────────────┼──────────────────┤
-│ Lab Tech     │ TOTP App  │ Security   │ Recovery codes    │
-│              │           │ Key        │                    │
-├──────────────┼───────────┼────────────┼──────────────────┤
-│ Admin        │ Security  │ TOTP App   │ Admin recovery    │
-│              │ Key       │            │ procedure          │
-├──────────────┼───────────┼────────────┼──────────────────┤
-│ Patient      │ SMS OTP   │ Email OTP  │ Support call       │
-│ Portal       │           │            │                    │
-└──────────────┴───────────┴────────────┴──────────────────┘
-```
+| User Type | Primary | Secondary | Fallback |
+|-----------|---------|-----------|----------|
+| **Doctor** | Passkey / WebAuthn | TOTP App | Recovery codes |
+| **Nurse** | Proximity Badge | PIN (6 digits) | TOTP App |
+| **Lab Tech** | TOTP App | Security Key | Recovery codes |
+| **Admin** | Security Key | TOTP App | Admin recovery procedure |
+| **Patient Portal** | SMS OTP | Email OTP | Support call |
 
 ## 2. Keycloak Authentication Flow cho Y Tế