Identity, Authentication and Authorization Boundaries#

API gateway ตรวจ JWT แล้วส่ง request เข้า Refund service ทีมจึงคิดว่า request “authorized” แต่ token แค่บอกว่า caller คือใครและมี claims บางอย่าง มันไม่ได้พิสูจน์ว่า caller อยู่ tenant เดียวกับ Charge, เป็น maker คนเดียวกับ approver หรือ Refund ยังผ่าน business invariant Authentication กับ authorization ต้องถูกแบ่งตาม owner และ decision

แยกคำถามด้าน Security#

• Identity proofing ผูก digital identity กับบุคคล/นิติบุคคลภายใต้ assurance process
• Authentication พิสูจน์ว่าผู้เรียกควบคุม authenticator/credential ที่ยอมรับ
• Federation ส่ง identity/authentication assertions ระหว่าง parties
• Authorization ตัดสินว่า principal ทำ action ต่อ resource ภายใต้ context ได้หรือไม่
• Transaction authorization ยืนยัน/ผูกการอนุมัติกับรายละเอียดธุรกรรมที่สำคัญ

NIST SP 800-63-4 แยก identity proofing, authentication และ federation ส่วน OAuth 2.0 เป็น authorization framework และ OIDC เพิ่ม identity layer อย่าเรียก JWT ว่า authorization ด้วยตัวมันเอง

สร้าง Principal ที่ Driving Boundary#

HTTP/auth adapter verify issuer, audience, signature, expiry และ policy ตาม deployment จากนั้น map protocol claims เป็น application type:

type Principal struct {
	SubjectID      string
	TenantID       string
	Permissions    PermissionSet
	AuthnContext   string
	SessionID      string
}

Domain model ไม่รับ raw JWT, http.Request หรือ OIDC claims เพราะ protocol/config เปลี่ยน และ claims ไม่ใช่ business facts ทุกตัว หากต้อง revalidate high-risk action ให้ application ขอ step-up/transaction authorization ผ่าน identity boundary

Workload principal อาจมาจาก mTLS/workload identity ไม่ใช่ human session Webhook sender authentication ใช้ signature/secret/certificate ตาม provider contract และไม่ควรถูก map เป็น employee Principal

แบ่งชั้นการทำ Authorization#

Can("refund:approve") เป็น coarse permission ไม่พอ ต้องตรวจ Charge tenant, refund state, amount policy, requester vs approver และ authoritative data

อนุมัติ Refund จาก Web Portal#

flow ที่แยก responsibility:

System map

Portal ไม่ตัดสิน maker-checker แม้อาจซ่อนปุ่มเพื่อ UX การซ่อนปุ่มไม่ใช่ security control Application ต้อง deny by default เมื่อ permission/context ไม่ครบ Domain policy รับข้อมูล identity ที่จำเป็น เช่น requester/approver IDs แต่ไม่รู้ JWT

RBAC, ABAC และความสัมพันธ์#

• RBAC เหมาะกับ permission bundles ตาม role แต่ role explosion เกิดเมื่อ tenant/context มาก
• ABAC ใช้ attributes ของ principal/resource/action/environment แต่ policy/testing ซับซ้อน
• Relationship-based model เหมาะกับ ownership/delegation graph บางบริบท

เลือกผสมได้ เช่น RBAC ให้ refund:approve, tenant/resource relationship จำกัด scope และ domain policy บังคับ approver ≠ requester External policy decision service ช่วย centralize บาง decisions แต่ต้องกำหนด availability, cache/freshness, policy version, audit และข้อมูล ที่ส่งออก ไม่ควรย้าย domain invariant ทั้งหมดออกเพราะเรียกว่า ABAC

OWASP Authorization Cheat Sheet แนะนำ least privilege, deny by default และ validate permission ทุก request

หลักฐานสำหรับ Audit#

Audit record ควรตอบ who, tenant, action, resource, decision, policy version, authentication context, correlation, time และ outcome โดยไม่เก็บ token/secret ควรแยก audit evidence จาก debug log และป้องกัน unauthorized alteration/access ตาม requirements

การบันทึก “user clicked approve” ไม่พอ ต้องบอก application decision และ state version ที่ใช้ ขณะเดียวกันอย่า log sensitive customer data เกินวัตถุประสงค์

แบบฝึกปฏิบัติ: Authorization Decision Table#

สร้าง cases:

เพิ่ม tests ที่ adapter, application, domain และ repository scope ตาม owner อย่าทดสอบทุกอย่าง ผ่าน HTTP เพียงระดับเดียว

รายการตรวจสอบ#

• Authentication/federation ไม่ถูกเรียกว่า business authorization
• Raw token/protocol types หยุดที่ driving boundary
• Principal มีข้อมูลเท่าที่ use case ต้องการ
• Permission, tenant/resource และ domain policy แยก reason/owner
• Human, workload และ webhook identities ไม่ปนกัน
• Deny by default และ audit policy version
• UI visibility ไม่ถูกใช้แทน server-side enforcement

อ่านเพิ่มเติม#

• NIST SP 800-63-4 — digital identity guidelines
• OAuth 2.0 RFC 6749 และ OpenID specifications
• OWASP Authorization Cheat Sheet
• OWASP Transaction Authorization