8 Hiểu Lầm Phổ Biến Về Authentication Mà Dev Nào Cũng Từng Mắc Phải

Nếu bạn hỏi mình đâu là chủ đề mà dev nhầm lẫn nhiều nhất, câu trả lời chắc chắn là authentication authorization khác nhau như thế nào. Nghe tưởng đơn giản — xác thực và ủy quyền — nhưng bao nhiêu năm đi làm, mình thấy dev vẫn nhầm như chơi ăn gian. Có những dự án dùng JWT xong tưởng “thế là xong auth”, có những API trả về 401 khi đáng lẽ phải là 403, có những hệ thống lưu password dạng mã hóa 2 chiều thay vì hash.

Bài viết này sẽ chỉ ra 8 hiểu lầm phổ biến nhất về authentication authorization mà ngay cả dev 5+ năm kinh nghiệm cũng từng mắc phải. Mỗi hiểu lầm đều kèm theo hậu quả thực tế và cách xử lý đúng — không lý thuyết suông.

1. Authentication authorization khác nhau — Đừng Trộn Lẫn Hai Khái Niệm Này

Authentication (AuthN): Xác thực — “Bạn là ai?”
Authorization (AuthZ): Ủy quyền — “Bạn được làm gì?”

Nghe thì dễ, nhưng thực tế thì mình đã thấy không ít codebase viết kiểu thế này:

// Route trong Laravel - SAI
Route::middleware('auth:api')->get('/admin/users', ...);

// Auth middleware chỉ check bạn đã login chưa
// Nó KHÔNG check bạn có quyền admin không
// Phải dùng thêm policy hoặc gate để check authorization

Hậu quả: User thường login xong có thể truy cập mọi thứ, chỉ vì dev nghĩ “đã auth rồi” mà quên mất bước check quyền. Đây là lỗ hổng authentication authorization kinh điển — IDOR (Insecure Direct Object Reference) — nằm trong top 10 OWASP hàng năm.

Giải pháp: Tách biệt rõ hai tầng authentication authorization — middleware AuthN (xác thực token/session) và middleware AuthZ (kiểm tra role/permission). Trong Laravel dùng Gate hoặc Policy, trong Node.js dùng RBAC hoặc CASL. Điểm đáng chú ý ở đây là nhiều framework đã hỗ trợ sẵn cả hai tầng, nhưng dev thường chỉ bật tầng AuthN và bỏ quên AuthZ.

Nói một cách đơn giản: authentication authorization khác nhau ở chỗ một cái trả lời “bạn là ai”, còn cái kia trả lời “bạn được làm gì”. Bỏ qua bất kỳ cái nào cũng là thiếu sót nghiêm trọng.

2. JWT Không Phải Là Viên Đạn Bạc Cho Auth

Trong hệ thống authentication authorization, JWT (JSON Web Token) đang bị lạm dụng một cách tràn lan. Để hiểu rõ hơn về các loại token, bạn có thể xem bài Opaque Token là gì? So sánh Opaque Token và JWT. Dev thấy JWT “cool”, “stateless”, “không cần database” là đem nhét vào mọi dự án, bất chấp nó có phù hợp hay không. Thú thật là mình cũng từng mắc lỗi này ở dự án đầu tiên.

Sai lầm 1: Lưu sensitive data trong JWT payload

JWT payload chỉ được base64 encode, không phải encrypt. Bất kỳ ai có token đều có thể decode và đọc nội dung. Dev từng lưu cả password, số điện thoại, địa chỉ vào JWT — và nghĩ rằng “nó đã được mã hóa”. Vấn đề trong authentication authorization là base64 không phải mã hóa — nó chỉ là cách biểu diễn dữ liệu dưới dạng text.

// SAI: Decode JWT bằng tay là thấy hết
// jwt.io - paste token vào là đọc được toàn bộ payload
// Chỉ lưu userId, role, expiry - KHÔNG lưu sensitive data

// Ví dụ payload SAI:
{
  "userId": 123,
  "email": "user@example.com",
  "phone": "0901234567",  // KHÔNG NÊN
  "address": "123 ABC"     // KHÔNG NÊN
}

// Payload ĐÚNG:
{
  "sub": 123,
  "role": "user",
  "exp": 1700000000
}

Sai lầm 2: “JWT stateless nên không cần database”

JWT không thể revoke. Khi bạn issue một token, nó sẽ sống đến khi hết hạn (exp). Nếu user bị hack, bạn không thể làm gì ngoài chờ token hết hạn — khác nào phát vé vào cửa mà không có cách thu hồi. Để revoke được, bạn PHẢI có database lưu blacklist hoặc dùng refresh token rotation.

Giải pháp:

• Dùng short-lived access token (5-15 phút) để giảm thiểu rủi ro khi token bị lộ
• Dùng refresh token lưu trong database (có thể revoke bất cứ lúc nào)
• Hoặc đơn giản nhất: dùng session-based auth (session ID lưu trong cookie) nếu bạn không có lý do gì để dùng JWT
• Theo OWASP JWT Security Cheat Sheet, luôn validate signature, kiểm tra expiration, và dùng thuật toán mạnh (RS256 hoặc ES256)

Thực tế: session-based auth vẫn chiếm đa số trong các web app thương mại. JWT phù hợp cho API service-to-service, mobile app, và single sign-on (SSO), không phải cho web app thông thường. Nếu bạn hỏi mình nên chọn gì cho web app đầu tiên — session-based auth luôn là lựa chọn an toàn hơn.

3. 401 vs 403 — Trả Sai HTTP Status Code Là Lỗi Phổ Biến

Đây là lỗi authentication authorization mà mình thấy nhiều nhất qua các lần review code. Nhiều dev cứ thấy lỗi liên quan đến quyền truy cập là trả về 401, mà không phân biệt rõ giữa “chưa đăng nhập” và “đã đăng nhập nhưng không có quyền”.

Lỗi phổ biến: Middleware auth lỗi trả về 401 — đúng. Nhưng nhiều dev dùng lại cái middleware đó cho cả authorization check, nên ai không có quyền cũng nhận 401 thay vì 403. Hoặc tệ hơn: trả về 401 kèm message “Bạn không có quyền truy cập” — vừa sai status code vừa sai message. Chuyện này liên quan trực tiếp đến việc hiểu authentication authorization khác nhau ở đâu.

Có một chi tiết thú vị là RFC 7235 định nghĩa 401 kèm header WWW-Authenticate để client biết cách xác thực lại. Nếu bạn trả 401 cho lỗi authorization, client sẽ cố gắng xác thực lại — vô nghĩa vì vấn đề nằm ở quyền, không phải danh tính.

4. Hash Password vs Encrypt Password — Hai Thứ Hoàn Toàn Khác Nhau

Mình từng thấy một dự án dùng AES-256 để “mã hóa” password. Khi hỏi tại sao, dev trả lời: “Để bảo mật, nếu hacker lấy được database cũng không đọc được password”. Vấn đề là: encrypt có thể giải mã, hash thì không. Đây là sự khác biệt sống còn trong bảo mật authentication authorization.

• Encrypt (mã hóa 2 chiều): Dùng để bảo vệ dữ liệu khi truyền/nghỉ, có thể giải mã về bản gốc (AES, RSA). Dùng cho: file, message, thông tin thẻ tín dụng.
• Hash (băm 1 chiều): Không thể giải mã, chỉ có thể so sánh. Dùng cho: password, checksum, integrity check. Giống như nghiền thịt thành patty — bạn không thể “un-nghiền” patty thành miếng thịt ban đầu.
• Hash với Salt: Thêm chuỗi ngẫu nhiên vào mỗi password trước khi hash để chống rainbow table attack. Mỗi user sẽ có salt riêng, nên cùng password “123456” nhưng hash ra giá trị khác nhau.

Hậu quả của việc encrypt password: Nếu encryption key bị lộ, hacker có thể decrypt toàn bộ password trong database — thảm họa bảo mật cấp độ “đóng công ty”. Đây là bài học mà LinkedIn đã phải trả giá đắt vào năm 2012 khi 6.5 triệu password hash bị leak do dùng SHA-1 không salt.

Đúng: Dùng bcrypt, argon2 hoặc scrypt — các thuật toán hash chuyên dụng cho password. Bcrypt mặc định cost factor 10 (~100ms để hash), chống brute force hiệu quả. Theo khuyến nghị từ OWASP Password Storage Cheat Sheet, Argon2id hiện là lựa chọn được ưu tiên nhất cho password hashing.

5. Token-Based Auth vs Session-Based Auth — Không Có Cái Nào “Tốt Hơn”

Trong lĩnh vực authentication authorization, dev thường nghĩ “token auth” và “session auth” là hai khái niệm đối lập. Thực tế thì session auth cũng dùng token (session ID). Sự khác biệt nằm ở nơi lưu trữ state, và đây là điểm mà nhiều dev hiểu sai khi so sánh authentication authorization khác nhau giữa hai phương thức này:

Không có cái nào “tốt hơn” tuyệt đối. Chọn giải pháp authentication authorization phù hợp với kiến trúc hệ thống của bạn, đừng chạy theo trend. Theo trải nghiệm thực tế của mình, hầu hết startup giai đoạn đầu nên chọn session-based auth vì đơn giản hơn rất nhiều, và chuyển sang JWT khi cần scale ra microservices.

6. OAuth 2.0 vs OpenID Connect — Đừng Nhầm Ủy Quyền Với Xác Thực

Đây là nhầm lẫn “kinh điển” và liên quan trực tiếp đến câu hỏi authentication authorization khác nhau ra sao ở cấp độ giao thức. Nhiều dev nhầm lẫn authentication authorization khi nghĩ OAuth 2.0 là giao thức xác thực. Sai! OAuth 2.0 là giao thức ủy quyền (authorization), không phải xác thực.

• OAuth 2.0: Cho phép ứng dụng A truy cập tài nguyên của user trên ứng dụng B (ví dụ: “Cho phép app này đăng lên Facebook của tôi”). OAuth 2.0 không nói cho bạn biết user là ai — nó chỉ cấp quyền truy cập.
• OpenID Connect (OIDC): Là lớp xác thực nằm trên OAuth 2.0. Thêm id_token (JWT) chứa thông tin user như email, name, avatar. Đây mới là thứ dùng để SSO.

Ví dụ thực tế: “Login với Google” trên website của bạn — đó là OpenID Connect (xác thực), không phải OAuth thuần. Google trả về id_token chứa email, name, avatar. Nếu chỉ dùng OAuth 2.0 thuần, bạn chỉ nhận được access_token mà không biết user là ai — giống như nhận chìa khóa nhà mà không biết nhà ai.

Nhiều dev triển khai “Login với Google” nhưng lại gọi nó là “OAuth login” trong document nội bộ. Nói một cách đơn giản, nếu bạn nhận được thông tin user (email, tên) sau khi login → bạn đang dùng OIDC. Nếu bạn chỉ nhận được quyền truy cập API → bạn đang dùng OAuth 2.0 thuần.

7. Password Policy Quá Khắt Khe Lại Phản Tác Dụng

Nhiều dev áp đặt password policy cực kỳ khắt khe nhưng lại phản tác dụng bảo mật. Theo trải nghiệm thực tế của mình, user bị ép đổi mật khẩu liên tục thường chọn cách đơn giản nhất: thêm số thứ tự vào cuối mật khẩu cũ.

• Bắt buộc đổi password mỗi 30 ngày: NIST SP 800-63B khuyến nghị KHÔNG bắt buộc đổi password định kỳ. Người dùng sẽ đặt password yếu hơn và dễ bị đoán (Password1, Password2, Password3…). Chỉ bắt buộc đổi khi có dấu hiệu lộ thông tin.
• Yêu cầu ký tự đặc biệt + số + chữ hoa/thường: Nghiên cứu cho thấy password dài (>12 ký tự) quan trọng hơn password phức tạp. Passphrase “tôi thích ăn phở bò tái nạm” khó brute force hơn “P@ss1” dù nó không có ký tự đặc biệt.
• Rate limiting cho login: Đây là thứ bắt buộc phải có, nhưng nhiều dev quên mất. Không rate limit = brute force thành công trong vài phút. Thêm delay tăng dần sau mỗi lần login sai (exponential backoff) là cách đơn giản nhất.
• Không check password đã bị leak: Dùng API như Have I Been Pwned để kiểm tra xem password mới có nằm trong danh sách đã bị lộ hay không — đây là best practice mà NIST cũng khuyến nghị.

Best practice hiện tại: Khuyến khích dùng passphrase (câu dài dễ nhớ), hỗ trợ đăng nhập bằng magic link hoặc OTP, và bắt buộc multi-factor authentication (MFA) cho tài khoản admin. Cơ chế authentication authorization mạnh mẽ bắt đầu từ password policy hợp lý — không phải từ việc ép user nhớ một chuỗi ký tự vô nghĩa.

8. CORS Không Phải Là Tính Năng Bảo Mật Auth

Mình gặp rất nhiều dev nghĩ: “Set CORS là xong bảo mật, chỉ cho phép domain của mình gọi API”. Sai! CORS là cơ chế của browser, không phải của server. Nó chỉ ngăn browser gửi cross-origin request — không ngăn được:

• curl / Postman / HTTP client từ server-side gọi API trực tiếp
• Extension trình duyệt hoặc tool tự động bypass CORS
• Request giả mạo từ script chạy trên server khác
• Mobile app hoặc desktop app gọi API (không qua browser)

CORS chỉ là một lớp bảo vệ mỏng cho browser-based attack. Authentication authorization thực sự phải dựa trên token, session, CSRF token, và validate ở server-side. Đừng quên caching cũng cần được xử lý đúng cách khi kết hợp với auth — nếu không bạn sẽ gặp lỗi cache trả về dữ liệu của user khác.

Có một chi tiết thú vị là CORS preflight request (OPTIONS) có thể làm chậm API đáng kể nếu không được cache đúng. Header Access-Control-Max-Age cho phép browser cache kết quả preflight trong một khoảng thời gian — giảm latency đáng kể cho các API cần gọi cross-origin thường xuyên.

Checklist: Authentication Authorization Khác Nhau Ở Những Điểm Nào?

Trước khi đi vào kết luận, mình tổng hợp lại bảng so sánh ngắn gọn để bạn dễ tra cứu. Hiểu rõ authentication authorization khác nhau ở đâu sẽ giúp bạn tránh được phần lớn các sai lầm đã nêu ở trên:

Bảng so sánh trên cho thấy authentication authorization khác nhau từ câu hỏi cơ bản cho đến công cụ triển khai. Khi review code về authentication authorization, mình luôn kiểm tra cả hai tầng này theo thứ tự: AuthN trước, AuthZ sau. Không bao giờ bỏ qua bất kỳ tầng nào.

Điểm đáng chú ý ở đây là nhiều framework hiện đại như Laravel, Django, Spring Boot đã tách biệt sẵn hai tầng authentication authorization khác nhau trong kiến trúc middleware. Nhưng dev vẫn mắc lỗi vì không hiểu rằng bật middleware auth chỉ mới giải quyết nửa bài toán — nửa còn lại là authorization, và nó cần được triển khai rõ ràng cho từng endpoint.

Hiểu Rõ Authentication Authorization Khác Nhau — Nền Tảng Của Mọi Hệ Thống Bảo Mật

Authentication và Authorization là những khái niệm tưởng dễ nhưng dễ sai nhất trong lập trình. Một lỗi authentication authorization có thể khiến cả hệ thống sụp đổ — mất dữ liệu, mất tiền, mất uy tín. Hiểu rõ authentication authorization khác nhau như thế nào là bước đầu tiên để xây dựng một hệ thống bảo mật vững chắc.

Những điều cần nhớ:

• Phân biệt rõ authentication authorization — AuthN (xác thực) và AuthZ (ủy quyền) — đây là nền tảng của mọi hệ thống bảo mật
• JWT không phải “viên đạn bạc” — biết khi nào dùng, khi nào không
• Trả đúng HTTP status code: 401 cho chưa xác thực, 403 cho không đủ quyền
• Hash password bằng bcrypt/argon2, đừng bao giờ encrypt password
• Hiểu rõ OAuth 2.0 (authorization) vs OpenID Connect (authentication)
• Password policy: dài > phức tạp, không bắt buộc đổi định kỳ
• CORS không thay thế được server-side auth

Nếu bạn mới bắt đầu với auth, lời khuyên thực tế nhất mà mình có thể đưa ra: đừng tự build authentication authorization system từ đầu. Dùng thư viện đã được kiểm chứng (NextAuth.js, Laravel Sanctum, Passport.js) và tập trung vào logic business. Bạn đã bao giờ mắc phải những sai lầm này chưa? Hay có “ca để đời” nào về auth muốn chia sẻ?