Authentication & AuthorizationAuthentication & Authorization

Thuộc bộ kiến thức Backend Roadmap.

Tổng quan

Hầu như mọi backend không tầm thường đều phải trả lời hai câu hỏi trên gần như mỗi request: “đây là ai?” và “họ có được phép làm việc này không?”. Câu đầu là authentication (AuthN), câu sau là authorization (AuthZ). Làm sai hai thứ này là con đường nhanh nhất dẫn tới lộ dữ liệu, để một user hành động thay danh nghĩa user khác, hoặc trao chìa khóa hệ thống cho kẻ tấn công — đó là lý do “Broken Access Control” và “Identification and Authentication Failures” đều nằm gần đỉnh của OWASP Top 10.

Đây là một hướng dẫn mang tính phòng thủ (defensive). Mục tiêu là giúp bạn xây hệ thống identity và access khó bị lạm dụng: lưu password sao cho một lần database bị dump không phải là “toang” hoàn toàn, phát hành token không thể giả mạo hay replay mãi mãi, và thực thi permission theo hướng fail closed. Note này nối tiếp các ý tưởng thiết kế API trong ./06-apis.md và gắn chặt với các biện pháp phòng thủ rộng hơn trong ./12-web-security.md.

AuthN và AuthZ — phân biệt cốt lõi

	Authentication (AuthN)	Authorization (AuthZ)
Trả lời câu hỏi	Bạn là ai?	Bạn được phép làm gì?
Xảy ra	Trước (xác lập danh tính)	Sau khi đã biết danh tính
Tạo ra	Một identity / principal (user, service)	Quyết định cho phép / từ chối
Đầu vào điển hình	Password, token, certificate, biometric	Roles, attributes, quyền sở hữu, policies
Ví dụ lỗi	Kẻ tấn công đăng nhập thành người khác	Một user đã đăng nhập đọc được invoice của user khác
HTTP status	401 Unauthorized (đặt tên nhầm — thực chất là “chưa authenticate”)	403 Forbidden

Một cách ghi nhớ hữu ích: AuthN là bước kiểm tra hộ chiếu ở cửa khẩu; AuthZ là chuyện visa của bạn có cho vào một căn phòng cụ thể hay không. Bạn luôn phải authenticate trước khi có thể authorize một cách có nghĩa, nhưng một danh tính hợp lệ không đồng nghĩa với việc có quyền — mỗi hành động được bảo vệ đều cần một lần kiểm tra AuthZ riêng, thực thi ở phía server.

Kiến thức nền tảng

Xử lý password (defensive)

Password là credential phổ biến nhất và cũng là thứ hay bị làm sai nhất. Nguyên tắc quan trọng nhất: bạn không bao giờ lưu password, và cũng không “encrypt” nó — bạn lưu một bản hash chậm và có salt.

Vì sao phải hash chứ không encrypt?

Encryption là có thể đảo ngược (reversible): bất kỳ ai có key đều có thể biến ciphertext trở lại password gốc. Điều đó khiến key trở thành một điểm chết người duy nhất, và bạn (hoặc kẻ tấn công lấy được key) có thể khôi phục password dạng plaintext của mọi user. Hashing là một chiều (one-way): từ hash bạn không thể khôi phục lại đầu vào một cách thực tế. Khi đăng nhập, bạn hash password người dùng gửi lên rồi so sánh với hash đã lưu. Bạn không bao giờ cần password gốc, nên bạn cũng không bao giờ nên có khả năng tạo ra nó.

Vì sao MD5 / SHA-256 dùng một mình là sai cho password

MD5, SHA-1, và cả SHA-256 đều là hash mật mã đa dụng, được thiết kế để chạy nhanh. Nhanh lại chính là điều sai cho password: một GPU hiện đại tính được hàng tỷ hash SHA-256 mỗi giây, nên kẻ tấn công lấy được bảng hash của bạn có thể brute-force hoặc dictionary-attack các password yếu gần như tức thì. Rainbow table (bảng tính trước) khiến các fast hash không salt trở nên dễ đảo ngược với những password thông dụng.

Password hashing cần tính chất ngược lại: phải cố tình chậm và memory-hard (tốn nhiều bộ nhớ), có thể điều chỉnh để giữ độ chậm khi phần cứng mạnh lên. Hãy dùng một password hashing function (còn gọi là KDF — key derivation function) được thiết kế cho việc này.

Thuật toán	Loại	Ghi chú
Argon2id	KDF memory-hard	Người thắng Password Hashing Competition (2015). Lựa chọn mặc định được khuyến nghị hiện nay. Biến thể id chống cả side-channel lẫn tấn công GPU/ASIC.
scrypt	KDF memory-hard	Memory-hard, lựa chọn tốt khi không có Argon2.
bcrypt	Hash thích ứng (adaptive)	Đã được kiểm chứng từ 1999, hỗ trợ rộng rãi. Cắt đầu vào ở 72 byte — nên pre-hash đầu vào dài. Vững chắc, dù cũ hơn.
PBKDF2	Hash lặp	Được FIPS chấp thuận, nhưng không memory-hard (yếu hơn trước GPU). Chỉ dùng khi compliance bắt buộc, với số iteration cao.
MD5 / SHA-1 / SHA-256 (dùng một mình)	Fast hash	Không bao giờ dùng cho password. Ổn cho checksum/toàn vẹn dữ liệu, không phải cho credential.

Salt, pepper và work factor

• Salt — một giá trị ngẫu nhiên, duy nhất, sinh riêng cho mỗi password và lưu cùng với hash. Nó bảo đảm hai user có cùng password sẽ cho ra hash khác nhau, và vô hiệu hóa rainbow table. Salt không phải bí mật; nhiệm vụ của nó là tính duy nhất. Các function hiện đại như bcrypt/Argon2 tự sinh và nhúng salt cho bạn.
• Pepper — một giá trị bí mật thêm vào đầu vào trước khi hash, lưu tách biệt với database (ví dụ trong KMS/HSM hoặc config ứng dụng, không nằm trong DB). Nếu chỉ database bị lộ, pepper vẫn đứng chắn giữa kẻ tấn công và các hash. Đây là defense-in-depth, xếp chồng lên trên salt của từng password.
• Work factor (cost) — tham số điều chỉnh được làm cho việc hash chậm lại: cost (rounds) của bcrypt, time/memory/parallelism của Argon2, số iteration của PBKDF2. Đặt sao cho một lần hash mất một khoảng thời gian đáng kể (một phần đáng kể của giây) trên phần cứng của bạn, và tăng dần theo thời gian khi phần cứng nhanh hơn. OWASP có công bố các tham số khuyến nghị cập nhật.

Một bản hash bcrypt đã lưu vốn đã mã hóa cả thuật toán, cost và salt trong một chuỗi:

$2b$12$eImiTMZG4T2s7A0.rXhVFO....R4L2q3s0Vf9x6kQeZmO/1u2gJ8Km

• định danh thuật toán2b = bcrypt
• cost = 122^12 = 4096 iteration
• 22 ký tự salt (base64)
• 31 ký tự hash

Quy tắc bổ sung: so sánh hash theo constant time (dùng hàm verify của thư viện, không bao giờ dùng ==), áp dụng password policy hợp lý (ưu tiên độ dài hơn là độ phức tạp tùy tiện — NIST khuyến khích passphrase dài), kiểm tra password gửi lên với danh sách password đã lộ (ví dụ API k-anonymity của Have I Been Pwned), và rate-limit / khóa tạm khi thất bại liên tục.

Session-based (cookie-based) authentication

Mô hình cổ điển cho ứng dụng web trên browser: server giữ state, client chỉ giữ một ID mờ (opaque).

1. User gửi credentials qua TLS.
2. Server verify, rồi tạo một session record ở phía server (trong memory, Redis, hoặc DB) chứa user ID, roles, expiry, v.v.
3. Server trả về một session ID — một giá trị ngẫu nhiên, dài, không thể đoán — trong header Set-Cookie.
4. Browser tự động gửi cookie đó ở mọi request tiếp theo; server tra cứu session để nhận diện user.
5. Khi logout (hoặc hết hạn), server xóa session record — revocation là tức thì và đơn giản vì server sở hữu state.

Vì cookie chỉ là một con trỏ ngẫu nhiên, nó không mang dữ liệu nào mà kẻ tấn công có thể đọc hay chỉnh sửa — niềm tin nằm ở kho lưu trữ phía server.

Các cookie flag quan trọng

Flag	Mục đích
HttpOnly	JavaScript không đọc được cookie (document.cookie), làm giảm nguy cơ đánh cắp token qua XSS.
Secure	Cookie chỉ được gửi qua HTTPS, không bao giờ qua HTTP plaintext.
SameSite=Lax / Strict	Hạn chế gửi cookie trên request cross-site, một biện pháp chống CSRF quan trọng. Strict an toàn nhất; Lax là mặc định phổ biến.
Domain / Path	Giới hạn phạm vi cookie xuống host/path hẹp nhất cần dùng.
Max-Age / Expires	Giới hạn vòng đời cookie; bỏ đi để tạo session cookie mất theo browser.
Tiền tố __Host-	Tiền tố tên cookie bắt buộc Secure, Path=/ và không có Domain — một mặc định hardening mạnh.

Set-Cookie: __Host-sid=9f2c...e71a; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600

Cái giá của session auth là tính stateful: mỗi server cần truy cập được kho session, điều này quan trọng khi scale ngang (nên mới có các kho chia sẻ như Redis). Điểm mạnh lớn là revocation dễ dàng và không có dữ liệu nhạy cảm nằm ở client.

Token-based authentication (JWT)

Thay vì server nhớ session, server trao cho client một token đã ký (signed) chứa sẵn các claim. Ở mỗi request, client trình token (thường qua Authorization: Bearer <token>), và server verify chữ ký — không cần tra cứu. Đây là mô hình stateless, phù hợp cho API, mobile client và microservice không chia sẻ kho session chung.

Định dạng phổ biến nhất là JSON Web Token (JWT).

Cấu trúc JWT: header.payload.signature

Ba phần được encode base64url, nối bằng dấu chấm:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNzAwMDAwMDAwLCJleHAiOjE3MDAwMDM2MDB9.dQw4w9WgXcQ7...signature...

• headereyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
• payloadeyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNzAwMDAwMDAwLCJleHAiOjE3MDAwMDM2MDB9
• signaturedQw4w9WgXcQ7...signature...

Sau khi decode:

// Header — thuật toán & loại token
{
  "alg": "HS256",
  "typ": "JWT"
}

// Payload — các claim
{
  "sub": "1234567890",   // subject (user ID)
  "name": "Alice",
  "role": "admin",
  "iss": "https://auth.example.com",  // issuer (bên phát hành)
  "aud": "https://api.example.com",   // audience (bên nhận dự kiến)
  "iat": 1700000000,     // issued at  (thời điểm phát hành, Unix time)
  "exp": 1700003600,     // expires    (hết hạn, Unix time) — 1 giờ sau
  "jti": "a3f1c9e2"      // ID duy nhất của token (hữu ích cho danh sách revoke)
}

// Signature (về mặt khái niệm):
// HMAC-SHA256( base64url(header) + "." + base64url(payload), secret )

Điểm cực kỳ quan trọng: payload chỉ được encode base64, KHÔNG encrypt — ai cũng đọc được. Không bao giờ đặt bí mật (password, số thẻ, PII bạn không muốn lộ) vào JWT. Chữ ký bảo đảm tính toàn vẹn (integrity) (không ai sửa được claim), chứ không phải tính bí mật (confidentiality).

Ký (signing): HS256 và RS256

	HS256 (HMAC)	RS256 (RSA)
Key	Một secret dùng chung	Key private ký, key public verify
Ai ký được	Bất kỳ ai có secret	Chỉ người giữ private key
Ai verify được	Bất kỳ ai có secret	Bất kỳ ai có public key
Phù hợp nhất	Một service vừa phát hành vừa verify	Nhiều service / bên thứ ba chỉ verify (ví dụ provider OAuth/OIDC)

Lưu ý bảo mật: luôn ghim cứng (pin) thuật toán mong đợi ở phía verify. Tấn công alg: none khét tiếng và tấn công nhầm lẫn “RS256 bị verify như HS256, dùng public key làm secret cho HMAC” đều xuất phát từ việc tin vào header alg của chính token. Hãy verify với một allow-list thuật toán tường minh.

Claims, expiry và refresh token

Các registered claim chuẩn (iss, sub, aud, exp, nbf, iat, jti) được định nghĩa bởi RFC 7519; luôn validate exp (và lý tưởng là cả iss/aud) ở mỗi request. Giữ access token có thời hạn ngắn (vài phút tới một giờ) để một token bị đánh cắp cũng nhanh chóng hết hạn.

Để tránh bắt user đăng nhập lại vài phút một lần, ghép một access token ngắn hạn với một refresh token dài hạn:

• Access token — ngắn hạn, gửi ở mỗi API call, cấp quyền truy cập.
• Refresh token — dài hạn, chỉ gửi tới auth server để lấy access token mới. Lưu cẩn thận hơn (giá trị cao hơn), và dùng rotation: mỗi lần dùng sẽ phát hành refresh token mới và vô hiệu hóa cái cũ, nhờ đó một refresh token bị đánh cắp rồi dùng lại có thể bị phát hiện (reuse detection) và cả “họ” token bị revoke.

Lưu token ở phía client như thế nào

Nơi lưu	Ưu điểm	Nhược điểm
Cookie HttpOnly	JS không đọc được → chống đánh cắp qua XSS; tự động gửi kèm	Cần bảo vệ CSRF (SameSite, CSRF token)
localStorage / sessionStorage	Đơn giản, hợp với SPA và header Authorization	Mọi JS đều đọc được → bất kỳ XSS nào = mất token; rủi ro XSS lớn hơn
Trong bộ nhớ (biến JS)	Không persist; mất khi refresh → cửa sổ đánh cắp nhỏ	Mất khi reload; thường ghép với một refresh cookie

Mẫu hiện đại thực dụng cho browser: refresh token trong cookie HttpOnly, Secure, SameSite; access token giữ trong bộ nhớ. Đó là lý do việc lưu token là một quyết định bảo mật, không chỉ là chi tiết cài đặt.

Bài toán revocation

Session auth revoke tức thì (xóa record). JWT stateless thì hợp lệ cho tới khi hết hạn — đó vừa là điểm mấu chốt, vừa là toàn bộ vấn đề. Bạn không thể “thu hồi” một token đã ký. Các biện pháp giảm thiểu:

• Thời hạn ngắn để cửa sổ phơi nhiễm nhỏ.
• Một denylist / blocklist các jti đã revoke (kiểm tra ở mỗi request — nhưng điều này đưa state trở lại, làm mất một phần lợi thế stateless).
• Xoay vòng (rotation) token/refresh kèm reuse detection.
• Xoay signing key (phương án hạt nhân: vô hiệu hóa toàn bộ token).

Sự đánh đổi này — stateless và revocation dễ dàng — chính là quyết định trung tâm khi chọn giữa session và token.

HTTP Basic authentication

Scheme đơn giản nhất (RFC 7617): client gửi Authorization: Basic <base64(username:password)> ở mỗi request.

Authorization: Basic YWxpY2U6czNjcjN0   # base64("alice:s3cr3t")

base64 là encoding, không phải encryption — đảo ngược cực kỳ dễ. Vì vậy Basic auth gửi password (về cơ bản là dạng rõ) trên từng request một. Nó chỉ chấp nhận được khi dùng qua TLS (HTTPS), và ngay cả khi đó cũng không hợp với ứng dụng cho end-user (không có logout, credential bị gửi lại liên tục, dễ vô tình bị ghi vào log). Nó ổn cho tooling nội bộ hoặc server-to-server đơn giản sau TLS, nhưng với auth cho user thật thì hãy ưu tiên token hoặc session.

Khái niệm chính

OAuth 2.0 — delegated authorization

OAuth 2.0 (RFC 6749) là một framework cho delegated authorization (ủy quyền truy cập): nó cho phép một user cấp cho ứng dụng bên thứ ba quyền truy cập giới hạn vào tài nguyên của họ trên một service khác mà không chia sẻ password. Khi bạn bấm “Sign in with Google” hay cho một app “đăng bài thay bạn”, đó là OAuth cấp quyền truy cập có scope thông qua một token. Lưu ý: OAuth nói về authorization (truy cập tài nguyên), không phải chủ yếu về authentication — để login/danh tính, bạn xếp chồng OpenID Connect lên trên (xem bên dưới).

Các vai trò (roles)

Vai trò	Là ai
Resource Owner	User sở hữu dữ liệu.
Client	App yêu cầu truy cập thay mặt user.
Authorization Server	Phát hành token sau khi authenticate user & lấy consent (ví dụ auth server của Google).
Resource Server	API giữ tài nguyên được bảo vệ; chấp nhận access token.

Token & scope

• Access token — credential ngắn hạn client gửi tới resource server. Thường (nhưng không luôn) là JWT.
• Refresh token — dùng để lấy access token mới mà không phải hỏi user lại.
• Scopes — các chuỗi cách nhau bằng dấu cách (read:email, write:repo) giới hạn token được làm gì. Hãy thực thi least privilege: chỉ xin những scope thực sự cần.

Các grant type

Grant	Trường hợp dùng
Authorization Code + PKCE	Mặc định cho app hướng user — web, SPA, mobile, native. PKCE nay được khuyến nghị cho mọi loại client.
Client Credentials	Machine-to-machine (không có user); client tự authenticate như chính nó.
Refresh Token	Đổi refresh token lấy access token mới.
Device Authorization	Thiết bị hạn chế nhập liệu (TV, CLI) — user authorize trên thiết bị thứ hai.
Implicit	Đã deprecated — token nằm trong URL fragment quá dễ lộ. Dùng Auth Code + PKCE.
Resource Owner Password	Đã deprecated — app cầm password thô, đi ngược mục đích của OAuth.

Authorization Code flow với PKCE — đi qua từng bước

PKCE (Proof Key for Code Exchange, RFC 7636) ngăn kẻ tấn công chặn được authorization code khỏi việc đổi nó lấy token, vì chỉ client gốc biết code_verifier bí mật.

Hai điểm bảo mật thiết yếu trong flow này: tham số state (một giá trị ngẫu nhiên được echo lại để chống CSRF trên bước redirect) và khớp redirect_uri chính xác (để code không thể bị chuyển hướng tới kẻ tấn công).

Client Credentials flow (machine-to-machine)

Không có user tham gia — một service tự authenticate như chính nó:

Service ──▶ POST /token
            grant_type=client_credentials
            client_id, client_secret, scope
        ◀── access_token
Service ──▶ GET /resource  (Authorization: Bearer access_token) ──▶ Resource Server

OpenID Connect (OIDC) — identity xếp chồng trên OAuth

OAuth 2.0 cho resource server biết client được làm gì, nhưng không cho biết một cách đáng tin user là ai. OpenID Connect là một lớp identity mỏng nằm trên OAuth 2.0, chuẩn hóa phần authentication. Đây mới là thứ thực sự vận hành “Sign in with …”.

Bổ sung then chốt là ID token — một JWT mô tả user đã được authenticate, phát hành cùng với access token trong cùng Authorization Code flow. Trong khi access token của OAuth dành cho resource server, thì ID token dành cho client để biết ai vừa đăng nhập.

// Payload của ID token sau khi decode
{
  "iss": "https://accounts.google.com",  // ai phát hành
  "sub": "10769150350006150715113082",   // user ID duy nhất, ổn định
  "aud": "your-client-id.apps...",        // token này dành cho client CỦA BẠN
  "email": "alice@example.com",
  "email_verified": true,
  "name": "Alice",
  "iat": 1700000000,
  "exp": 1700003600,
  "nonce": "n-0S6_WzA2Mj"                 // buộc token với auth request của bạn (chống replay)
}

OIDC còn thêm: các claim chuẩn (email, name, picture), scope openid, endpoint UserInfo, và Discovery (/.well-known/openid-configuration) để client tự cấu hình. Hãy ưu tiên một provider/thư viện OIDC trưởng thành thay vì tự viết login.

SAML — SSO doanh nghiệp (tóm tắt)

SAML 2.0 (Security Assertion Markup Language) là chuẩn cũ hơn, dựa trên XML, cho federated single sign-on, vẫn thống trị trong môi trường enterprise/B2B. Các vai trò: Identity Provider (IdP) (ví dụ Okta, Azure AD) authenticate user và phát hành một assertion XML đã ký; Service Provider (SP) (app của bạn) tin assertion đó và cho user đăng nhập. Nó giải cùng bài toán “đăng nhập một lần, truy cập nhiều app” như OIDC, nhưng bằng XML và POST redirect qua browser thay vì JSON/JWT. Với app consumer/API mới, hãy ưu tiên OIDC; hỗ trợ SAML khi khách hàng doanh nghiệp yêu cầu.

Các mô hình authorization

Khi đã biết user là ai, bạn quyết định họ được làm gì. Các mô hình phổ biến:

RBAC — Role-Based Access Control

Permission được gom vào các role; user được gán role. “Admin xóa được; editor ghi được; viewer đọc được.” Đơn giản, phổ biến, dễ suy luận và audit. Có thể gặp role explosion (bùng nổ role) khi luật chi tiết dần (editor-of-team-A-in-region-EU).

1. 01useralice
2. 02rolesadmin
3. 03permissions{read, write, delete}
4. 04resource/articles

ABAC — Attribute-Based Access Control

Quyết định được tính từ attribute của subject, resource, action và environment. “Một bác sĩ được đọc hồ sơ nếu cùng khoa và đang trong ca trực.” Diễn đạt mạnh hơn RBAC nhiều và rất hợp với luật phụ thuộc ngữ cảnh, nhưng khó test và audit hơn.

allow if user.department == resource.department
       and user.role == "doctor"
       and env.time in shift_hours

ACL — Access Control List

Permission gắn trực tiếp vào từng resource: một danh sách (principal → action được phép). Nghĩ tới permission của filesystem hay “tài liệu này được chia sẻ cho Bob (view) và Carol (edit)”. Rất hợp cho chia sẻ theo từng object (kiểu Google Docs); không scale tốt như một policy toàn hệ thống.

ReBAC / policy engine

• ReBAC (Relationship-Based Access Control) — permission suy ra từ quan hệ trong một graph (“bạn sửa được tài liệu nếu bạn sở hữu folder chứa nó”). Được Google Zanzibar phổ biến; cài đặt bởi các công cụ như OpenFGA / SpiceDB.
• Policy engine — đưa AuthZ ra một engine chuyên biệt để luật nằm ngoài code ứng dụng. Ví dụ: Open Policy Agent (OPA) với ngôn ngữ Rego, hoặc XACML. Cách này tách policy khỏi code, tập trung việc audit, và cho phép đổi luật mà không cần redeploy.

Mô hình	Độ chi tiết	Hợp nhất cho	Cần cẩn thận
RBAC	Thô (theo role)	Đa số app, chức năng công việc rõ ràng	Role explosion
ABAC	Mịn (theo attribute)	Luật phụ thuộc ngữ cảnh	Độ phức tạp, test
ACL	Theo từng object	Chia sẻ từng resource	Scale toàn hệ thống
ReBAC	Graph quan hệ	Sở hữu lồng nhau, chia sẻ	Chi phí mô hình hóa & hạ tầng

Best Practices

So sánh các cơ chế authentication

Cơ chế	State	Revocation	Hợp nhất cho	Rủi ro chính
Session + cookie	Stateful (kho ở server)	Dễ (xóa record)	App web render phía server	CSRF; scale kho session
JWT (bearer)	Stateless	Khó (tới khi hết hạn)	API, SPA, microservice	Đánh cắp token; không revoke được; lộ secret
Basic auth	Stateless	Không có (gửi credential mỗi lần)	Nội bộ/server-to-server qua TLS	Password gửi mỗi request
OAuth 2.0	Dựa trên token	Qua refresh/expiry	Truy cập ủy quyền cho bên thứ ba	Cấu hình sai (redirect_uri, scope)
OIDC	Dựa trên token	Qua refresh/expiry	Federated login (“Sign in with…”)	Như OAuth + validate ID token
SAML	Dựa trên assertion	Session ở SP/IdP	SSO doanh nghiệp	Độ phức tạp XML, signature wrapping
API key	Chuỗi stateless	Xoay/revoke key	Auth service đơn giản	Sống lâu; lộ trong code/log
mTLS	Dựa trên certificate	Revoke/hết hạn cert	Service mesh zero-trust	Quản lý vòng đời cert

Best practices chung

• Không bao giờ tự viết crypto hay auth. Dùng thư viện đã được kiểm chứng (bcrypt/Argon2, các SDK OAuth/OIDC uy tín) và, nếu được, một managed identity provider.
• Luôn qua TLS. Mọi credential, token và cookie phải đi qua HTTPS. Đặt Secure cho cookie; dùng HSTS.
• Bắt buộc MFA (multi-factor authentication) cho mọi thứ nhạy cảm: thứ bạn biết (password) + thứ bạn có (app TOTP, hardware key). Ưu tiên các yếu tố chống phishing như WebAuthn/FIDO2 (passkey) hơn SMS OTP, vốn dễ bị SIM-swap và chặn bắt.
• Least privilege. Chỉ cấp role/scope tối thiểu cần thiết; mặc định là từ chối; yêu cầu cấp quyền tường minh. Mọi endpoint được bảo vệ đều kiểm tra AuthZ ở phía server — đừng bao giờ tin client để “giấu một cái nút”.
• Thực thi AuthZ ở mọi request, ở cấp object. Lỗi API số 1 (OWASP API Top 10) là BOLA / IDOR — tin một ID từ client mà không kiểm tra caller có sở hữu object đó không. Luôn verify resource.owner == current_user (hoặc chạy policy check) cho mọi truy cập object.
• Access token ngắn hạn + refresh token xoay vòng kèm reuse detection. Validate exp, iss, aud, và ghim thuật toán ký ở mỗi JWT.
• Xử lý secret an toàn. Giữ signing key, client secret và pepper trong secrets manager / KMS / HSM — không bao giờ trong source control, không trong code phía client, không trong log.
• Rate-limit và throttle các endpoint auth (login, token, password-reset, MFA). Thêm exponential backoff, khóa tài khoản một cách thận trọng (tránh DoS qua lockout), và CAPTCHA khi bị lạm dụng. Điều này làm giảm credential stuffing và brute force. (Xem ./12-web-security.md và ./06-apis.md.)
• Bảo vệ toàn bộ vòng đời tài khoản. Password reset an toàn (token dùng một lần, hết hạn, không đoán được; đừng tiết lộ email có tồn tại hay không), email verification, và vô hiệu hóa session/token khi đổi password hoặc logout.
• Log và giám sát các sự kiện authentication (đăng nhập, thất bại, thay đổi quyền, phát hành token) để phát hiện và ứng phó sự cố — nhưng không log secret hay token đầy đủ.
• Fail closed. Mọi lỗi trong một quyết định AuthZ đều phải từ chối. Một exception trong bước kiểm tra permission không bao giờ được vô tình cấp quyền.
• Ngăn user enumeration và rò rỉ qua timing. Trả về lỗi chung chung (“username hoặc password không đúng”), và dùng so sánh constant-time cho secret.

Tài liệu tham khảo

• OWASP Top 10 — gồm Broken Access Control & Identification/Authentication Failures
• OWASP Authentication Cheat Sheet
• OWASP Password Storage Cheat Sheet
• OWASP Authorization Cheat Sheet
• RFC 6749 — The OAuth 2.0 Authorization Framework
• RFC 7636 — PKCE (Proof Key for Code Exchange)
• RFC 7519 — JSON Web Token (JWT)
• OpenID Connect Core 1.0
• jwt.io — Giới thiệu & công cụ debug JWT

Set-Cookie: __Host-sid=9f2c...e71a; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600

// Header — algorithm & token type
{
  "alg": "HS256",
  "typ": "JWT"
}

// Payload — the claims
{
  "sub": "1234567890",   // subject (the user ID)
  "name": "Alice",
  "role": "admin",
  "iss": "https://auth.example.com",  // issuer
  "aud": "https://api.example.com",   // audience
  "iat": 1700000000,     // issued at  (Unix time)
  "exp": 1700003600,     // expires    (Unix time) — 1 hour later
  "jti": "a3f1c9e2"      // unique token ID (useful for revocation lists)
}

// Signature (conceptually):
// HMAC-SHA256( base64url(header) + "." + base64url(payload), secret )

Authorization: Basic YWxpY2U6czNjcjN0   # base64("alice:s3cr3t")

Service ──▶ POST /token
            grant_type=client_credentials
            client_id, client_secret, scope
        ◀── access_token
Service ──▶ GET /resource  (Authorization: Bearer access_token) ──▶ Resource Server

// Decoded ID token payload
{
  "iss": "https://accounts.google.com",  // who issued it
  "sub": "10769150350006150715113082",   // stable unique user ID
  "aud": "your-client-id.apps...",        // this token is for YOUR client
  "email": "alice@example.com",
  "email_verified": true,
  "name": "Alice",
  "iat": 1700000000,
  "exp": 1700003600,
  "nonce": "n-0S6_WzA2Mj"                 // ties token to your auth request (replay defense)
}

allow if user.department == resource.department
       and user.role == "doctor"
       and env.time in shift_hours