Authentication vs Authorization: Sự khác biệt và cách thiết kế đúng cho web app

15/05/2026

Authentication và Authorization là 2 hai khái niệm khác nhau trong quá trinh thiết kế web, app. Trong đó, Authentication (Xác thực) là quá trình xác minh bạn là ai, ví dụ: đăng nhập bằng email và mật khẩu. Authorization (Phân quyền) là quá trình xác định bạn được làm gì, ví dụ: chỉ admin mới được xóa bài viết.

Authentication xảy ra trước, Authorization xảy ra sau. Đây là hai lớp bảo mật độc lập và bắt buộc phải thiết kế đúng trong mọi web application.

1. Authentication là gì?

Authentication (viết tắt: AuthN) là quá trình xác minh danh tính của một người dùng, hệ thống, hoặc thiết bị đang cố gắng truy cập vào ứng dụng.

Nói đơn giản: “Bạn có thực sự là người bạn nói không?”

Ví dụ Authentication trong thực tế:

Nhập email + mật khẩu để đăng nhập Gmail
Quét vân tay để mở khóa điện thoại
Nhập mã OTP gửi về số điện thoại
Đăng nhập qua Google / Facebook (OAuth)
Sử dụng certificate trong API-to-API communication

Yếu tố xác thực (Authentication Factors):

Authentication dựa trên ba loại yếu tố:

Loại	Mô tả	Ví dụ
Something you know	Thứ bạn biết	Mật khẩu, PIN, câu hỏi bảo mật
Something you have	Thứ bạn có	Điện thoại, hardware key, smart card
Something you are	Thứ bạn là	Vân tay, nhận diện khuôn mặt, giọng nói

Multi-Factor Authentication (MFA) kết hợp từ hai yếu tố trở lên để tăng độ bảo mật.

2. Authorization là gì?

Authorization (viết tắt: AuthZ) là quá trình xác định người dùng đã xác thực được phép làm gì, tức là quyền hạn của họ trong hệ thống.

Nói đơn giản: “Bạn được phép truy cập vào đâu, làm gì?”

Ví dụ Authorization trong thực tế:

Admin được phép xóa tài khoản người dùng, user thường thì không
Chủ bài viết được phép chỉnh sửa bài của mình, người khác chỉ được đọc
Manager xem được báo cáo tài chính, nhân viên thì không có quyền
Free user bị giới hạn 5 lần export/tháng, Plus user không bị giới hạn

Authorization không phải là Authentication:

Một người dùng có thể đã xác thực thành công (login đúng mật khẩu) nhưng vẫn không được phép truy cập một tài nguyên cụ thể. Đây là sự khác biệt cốt lõi.

3. Authentication vs Authorization: So sánh trực tiếp

Tiêu chí	Authentication (AuthN)	Authorization (AuthZ)
Câu hỏi	Bạn là ai?	Bạn được làm gì?
Mục đích	Xác minh danh tính	Kiểm soát quyền truy cập
Thứ tự	Xảy ra trước	Xảy ra sau AuthN
Phụ thuộc	Độc lập	Phụ thuộc vào AuthN
Dữ liệu đầu vào	Credentials (mật khẩu, token, biometrics)	Permissions, roles, policies
Kết quả khi thất bại	HTTP `401 Unauthorized`	HTTP `403 Forbidden`
Công nghệ phổ biến	JWT, OAuth 2.0, SAML, OpenID Connect	RBAC, ABAC, ACL, OPA
Ví dụ thực tế	Đăng nhập bằng email/mật khẩu	Chỉ admin mới xóa được user

Ghi nhớ nhanh:

401 Unauthorized → Chưa xác thực (sai mật khẩu, chưa đăng nhập)
403 Forbidden → Đã xác thực nhưng không có quyền

4. Tại sao dễ nhầm lẫn Authentication vs Authorization và hậu quả khi thiết kế sai?

Nguồn gốc của sự nhầm lẫn

Tên gọi tiếng Anh gây nhiễu: 401 Unauthorized thực chất có nghĩa là “unauthenticated” (chưa xác thực), không phải “unauthorized” (không được phép). HTTP spec đặt tên này từ năm 1999 và đến nay vẫn giữ nguyên dù gây nhầm.

Ngoài ra, cả hai từ đều bắt đầu bằng “auth-” và thường được gộp vào cùng một module “auth” trong codebase, khiến dev dễ trộn lẫn trách nhiệm.

Hậu quả nghiêm trọng khi thiết kế sai

Trường hợp 1: Bỏ qua Authorization sau khi đã Authentication

// ❌ SAI: Chỉ kiểm tra login, không kiểm tra quyền app.delete('/api/users/:id', isLoggedIn, (req, res) => { User.delete(req.params.id); // Bất kỳ user nào cũng xóa được user khác! });

Lỗ hổng IDOR (Insecure Direct Object Reference), một trong những lỗi phổ biến nhất trong OWASP Top 10.

Trường hợp 2: Kiểm tra quyền chỉ ở frontend

javascript

// ❌ SAI: Ẩn nút "Delete" trên UI nhưng API không kiểm tra
{isAdmin && <button onClick={deleteUser}>Delete</button>}
// Attacker vẫn có thể gọi API trực tiếp bằng curl hoặc Postman!

Trường hợp 3: Lưu role trong JWT mà không verify phía server

Nếu server tin hoàn toàn vào claim "role": "admin" trong JWT mà không kiểm tra với database, attacker có thể chỉnh sửa token (nếu không dùng chữ ký đúng cách) để leo thang đặc quyền.

5. Các phương pháp Authentication phổ biến

5.1. Session-based Authentication

Server tạo session sau khi login, lưu session ID trong cookie. Mỗi request browser gửi kèm cookie, server tra cứu session store.

Ưu điểm: Dễ revoke (chỉ cần xóa session)
Nhược điểm: Khó scale horizontal, cần sticky session hoặc shared session store (Redis)

5.2. Token-based Authentication (JWT)

Sau khi login, server cấp JSON Web Token chứa claims (user ID, role, expiry). Client lưu token và gửi kèm mỗi request qua header Authorization: Bearer <token>.

Ưu điểm: Stateless, dễ scale, phù hợp microservices
Nhược điểm: Khó revoke trước expiry, token bị đánh cắp là mất kiểm soát

Cấu trúc JWT:

Header.Payload.Signature
eyJhbGc...  .eyJ1c2VySWQi...  .SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

5.3. OAuth 2.0

Giao thức ủy quyền (không phải xác thực thuần túy) cho phép ứng dụng thứ ba truy cập tài nguyên của user mà không cần biết mật khẩu. Thường kết hợp với OpenID Connect (OIDC) để thêm lớp authentication.

Các grant type phổ biến:

Authorization Code + PKCE: Web app, mobile app (khuyến nghị)
Client Credentials: Server-to-server (không có user)
Device Code: Smart TV, CLI tools

5.4. Passkeys / WebAuthn

Phương pháp xác thực thế hệ mới, loại bỏ hoàn toàn mật khẩu. Sử dụng public-key cryptography kết hợp với biometrics hoặc hardware key.

Ưu điểm: Chống phishing 100%, không có password để bị leak
Xu hướng 2026: Apple, Google, Microsoft đều đang đẩy mạnh Passkeys

6. Các mô hình Authorization phổ biến

6.1. ACL – Access Control List

Danh sách quy định cụ thể từng user/group được phép làm gì với từng tài nguyên.

File "report.pdf": Alice=READ, Bob=READ+WRITE, Admin=READ+WRITE+DELETE

Phù hợp: Hệ thống file, object storage, quy mô nhỏ

6.2. RBAC – Role-Based Access Control

Gán quyền theo vai trò (role), không gán trực tiếp cho từng user. User được gán một hoặc nhiều role.

Roles: admin, editor, viewer
admin → tất cả quyền
editor → read + write
viewer → read only

User Alice → role: editor
User Bob → role: viewer

Phù hợp: Hầu hết web app doanh nghiệp, SaaS B2B
Thư viện phổ biến: Casbin, CASL (JavaScript), Pundit (Ruby)

6.3. ABAC – Attribute-Based Access Control

Quyền được xác định dựa trên thuộc tính của user, tài nguyên, và môi trường.

Policy: User có thể chỉnh sửa tài liệu NẾU:
  - user.department == document.department
  - user.clearanceLevel >= document.sensitivityLevel  
  - current_time is within business_hours

Phù hợp: Hệ thống phức tạp, nhiều điều kiện động, enterprise
Thư viện phổ biến: Open Policy Agent (OPA), AWS IAM, Azure AD Conditional Access

6.4. ReBAC – Relationship-Based Access Control

Quyền dựa trên quan hệ giữa user và tài nguyên. Được Google giới thiệu qua hệ thống Zanzibar.

User Alice là "owner" của Document X → được phép edit
User Bob là "viewer" của Document X → chỉ được đọc
User Carol là "editor" của Folder Y chứa Document X → được edit Document X

Phù hợp: Google Docs, Notion, Dropbox-style sharing
Thư viện phổ biến: OpenFGA, SpiceDB, Permify

7. Thiết kế Authentication đúng cho web app

Nguyên tắc cơ bản

1. Không tự xây dựng authentication từ đầu
Dùng các giải pháp đã được kiểm chứng: Auth0, Supabase Auth, AWS Cognito, Clerk, NextAuth.js. Tự viết auth dễ tạo ra lỗ hổng nghiêm trọng.

2. Hash mật khẩu đúng cách

javascript

// ✅ ĐÚNG: Dùng bcrypt với cost factor >= 12
const hash = await bcrypt.hash(password, 12);

// ❌ SAI: MD5, SHA1, SHA256 không phù hợp cho mật khẩu
const hash = crypto.createHash('md5').update(password).digest('hex');

3. Implement MFA cho tài khoản quan trọng
Tối thiểu nên hỗ trợ TOTP (Google Authenticator). Năm 2026, SMS OTP đã được NIST khuyến cáo hạn chế do dễ bị SIM swap.

4. Secure token storage

javascript

// ✅ ĐÚNG: Refresh token trong httpOnly cookie
res.cookie('refreshToken', token, {
  httpOnly: true,    // JavaScript không đọc được
  secure: true,      // Chỉ qua HTTPS
  sameSite: 'strict', // Chống CSRF
  maxAge: 7 * 24 * 60 * 60 * 1000
});

// ❌ SAI: Lưu sensitive token trong localStorage
localStorage.setItem('accessToken', token); // Dễ bị XSS đánh cắp

5. Rate limiting và brute force protection

javascript

// Giới hạn 5 lần login sai → lock tài khoản 15 phút
// Implement CAPTCHA sau 3 lần thất bại
// Log và alert khi phát hiện credential stuffing

6. Thiết kế token lifecycle đúng

Access token: Thời gian ngắn (15 phút – 1 giờ), stateless JWT
Refresh token: Thời gian dài (7–30 ngày), lưu trong DB để có thể revoke
Implement token rotation: cấp refresh token mới mỗi lần dùng, invalidate token cũ

8. Thiết kế Authorization đúng cho web app

Nguyên tắc Least Privilege

“Mỗi thành phần chỉ nhận đúng và đủ quyền cần thiết để hoàn thành nhiệm vụ của mình, không hơn.”

javascript

// ✅ ĐÚNG: Kiểm tra quyền cụ thể ở mỗi endpoint
app.delete('/api/posts/:id', authenticate, async (req, res) => {
  const post = await Post.findById(req.params.id);
  
  // Kiểm tra ownership HOẶC admin role
  if (post.authorId !== req.user.id && req.user.role !== 'admin') {
    return res.status(403).json({ error: 'Forbidden' });
  }
  
  await post.delete();
  res.json({ success: true });
});

Defense in Depth: Kiểm tra quyền ở nhiều lớp

Request → [API Gateway: rate limit, token validate]
        → [Middleware: authenticate, load user roles]  
        → [Route handler: check specific permission]
        → [Service layer: business logic permission]
        → [Database: row-level security nếu cần]

Tách biệt Authentication và Authorization middleware

javascript

// ✅ Tách riêng 2 middleware
const authenticate = async (req, res, next) => {
  // Chỉ xác minh token, load user info
  const user = await verifyToken(req.headers.authorization);
  if (!user) return res.status(401).json({ error: 'Unauthenticated' });
  req.user = user;
  next();
};

const authorize = (permission) => (req, res, next) => {
  // Chỉ kiểm tra quyền, không quan tâm identity
  if (!req.user.permissions.includes(permission)) {
    return res.status(403).json({ error: 'Forbidden' });
  }
  next();
};

// Sử dụng
app.delete('/api/users/:id', 
  authenticate,                     // AuthN
  authorize('users:delete'),        // AuthZ
  userController.delete
);

Audit logging

Mọi hành động nhạy cảm cần được log đầy đủ:

javascript

{
  timestamp: "2026-05-15T10:30:00Z",
  userId: "usr_123",
  action: "user.delete",
  targetResource: "usr_456",
  result: "success",  // hoặc "forbidden"
  ipAddress: "1.2.3.4",
  userAgent: "Mozilla/5.0..."
}

9. Ví dụ thực tế Authentication vs Authorization trong E-commerce app

Các role trong hệ thống:

customer – Người mua hàng
seller – Người bán (quản lý shop của mình)
moderator – Kiểm duyệt nội dung
admin – Quản trị toàn hệ thống

Ma trận phân quyền:

Hành động	Customer	Seller	Moderator	Admin
Xem sản phẩm	✅	✅	✅	✅
Đặt hàng	✅	✅	❌	❌
Tạo/sửa sản phẩm của mình	❌	✅	❌	✅
Ẩn sản phẩm vi phạm	❌	❌	✅	✅
Xóa tài khoản	❌	❌	❌	✅
Xem báo cáo doanh thu	Của mình	Của shop	❌	Tất cả

Implementation với RBAC + ownership check:

javascript

// Seller chỉ sửa được sản phẩm của shop mình
app.put('/api/products/:id', authenticate, async (req, res) => {
  const product = await Product.findById(req.params.id);
  const user = req.user;

  const canEdit = 
    user.role === 'admin' ||
    (user.role === 'seller' && product.shopId === user.shopId) ||
    user.role === 'moderator'; // Chỉ ẩn, không sửa nội dung

  if (!canEdit) return res.status(403).json({ error: 'Forbidden' });

  await product.update(req.body);
  res.json(product);
});

10. Checklist bảo mật Authentication vs Authorization cho dev team

Authentication Checklist

Authorization Checklist

Kiểm tra quyền phía server (không chỉ frontend)
Áp dụng nguyên tắc Least Privilege
Tách biệt middleware authenticate và authorize
Kiểm tra ownership cho resource-specific actions
Không để authorization logic trong tầng presentation
Audit log cho mọi hành động nhạy cảm
Test cases cho cả “được phép” lẫn “bị từ chối”
Regular review và cleanup permissions
Kiểm tra phân quyền ở cả API Gateway lẫn service layer

Bạn còn thông tin nào về Authentication vs Authorization cần được giải đáp

Cả hai đều quan trọng như nhau và bổ sung cho nhau. Authentication không có Authorization thì user nào cũng làm được mọi thứ sau khi login. Authorization không có Authentication thì không biết ai đang làm gì để mà phân quyền.

JWT là cơ chế truyền tải có thể phục vụ cả hai mục đích. JWT thường chứa thông tin xác thực (user ID) và thông tin phân quyền (roles, permissions) cùng lúc trong payload.

OAuth 2.0 về bản chất là giao thức Authorization — cho phép ứng dụng thứ ba truy cập tài nguyên thay mặt user. Khi kết hợp với OpenID Connect (OIDC), nó mới trở thành cơ chế Authentication.

RBAC đơn giản hơn, dễ hiểu, dễ triển khai — phù hợp khi permissions gắn với role rõ ràng. ABAC linh hoạt hơn nhưng phức tạp hơn — phù hợp khi cần nhiều điều kiện động (thời gian, địa điểm, thuộc tính tài nguyên).

Đây là lỗi đặt tên lịch sử trong HTTP spec (RFC 7235, 1999). 401 Unauthorized thực chất có nghĩa là "unauthenticated". 403 Forbidden mới là "unauthorized" (có danh tính nhưng không có quyền). Nhầm lẫn này đã được cộng đồng thừa nhận nhưng không thể đổi vì backward compatibility.

Không khuyến nghị cho sensitive token. localStorage dễ bị đánh cắp qua XSS. Tốt hơn: lưu access token trong memory (JavaScript variable) và refresh token trong httpOnly cookie. Đây là pattern được gọi là "token in memory + silent refresh".

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat

Authentication vs Authorization: Sự khác biệt và cách thiết kế đúng cho web app

1. Authentication là gì?

Ví dụ Authentication trong thực tế:

Yếu tố xác thực (Authentication Factors):

2. Authorization là gì?

Ví dụ Authorization trong thực tế:

Authorization không phải là Authentication:

3. Authentication vs Authorization: So sánh trực tiếp

4. Tại sao dễ nhầm lẫn Authentication vs Authorization và hậu quả khi thiết kế sai?

Nguồn gốc của sự nhầm lẫn

Hậu quả nghiêm trọng khi thiết kế sai

5. Các phương pháp Authentication phổ biến

5.1. Session-based Authentication

5.2. Token-based Authentication (JWT)

5.3. OAuth 2.0

5.4. Passkeys / WebAuthn

6. Các mô hình Authorization phổ biến

6.1. ACL – Access Control List

6.2. RBAC – Role-Based Access Control

6.3. ABAC – Attribute-Based Access Control

6.4. ReBAC – Relationship-Based Access Control

7. Thiết kế Authentication đúng cho web app

Nguyên tắc cơ bản

8. Thiết kế Authorization đúng cho web app

Nguyên tắc Least Privilege

Defense in Depth: Kiểm tra quyền ở nhiều lớp

Tách biệt Authentication và Authorization middleware

Audit logging

9. Ví dụ thực tế Authentication vs Authorization trong E-commerce app

Các role trong hệ thống:

Ma trận phân quyền:

Implementation với RBAC + ownership check:

10. Checklist bảo mật Authentication vs Authorization cho dev team

Authentication Checklist

Authorization Checklist

Bạn còn thông tin nào về Authentication vs Authorization cần được giải đáp

Các tin tức khác

Lộ trình học bảo mật Web cho Developer từ A–Z (2026)

7 lỗ hổng bảo mật web developer hay bỏ sót dù đã có mã hóa HTTPS

Lỗ hổng bảo mật thường gặp trong hệ thống tích hợp AI

Authentication vs Authorization: Sự khác biệt và cách thiết kế đúng cho web app

1. Authentication là gì?

Ví dụ Authentication trong thực tế:

Yếu tố xác thực (Authentication Factors):

2. Authorization là gì?

Ví dụ Authorization trong thực tế:

Authorization không phải là Authentication:

3. Authentication vs Authorization: So sánh trực tiếp

4. Tại sao dễ nhầm lẫn Authentication vs Authorization và hậu quả khi thiết kế sai?

Nguồn gốc của sự nhầm lẫn

Hậu quả nghiêm trọng khi thiết kế sai

5. Các phương pháp Authentication phổ biến

5.1. Session-based Authentication

5.2. Token-based Authentication (JWT)

5.3. OAuth 2.0

5.4. Passkeys / WebAuthn

6. Các mô hình Authorization phổ biến

6.1. ACL – Access Control List

6.2. RBAC – Role-Based Access Control

6.3. ABAC – Attribute-Based Access Control

6.4. ReBAC – Relationship-Based Access Control

7. Thiết kế Authentication đúng cho web app

Nguyên tắc cơ bản

8. Thiết kế Authorization đúng cho web app

Nguyên tắc Least Privilege

Defense in Depth: Kiểm tra quyền ở nhiều lớp

Tách biệt Authentication và Authorization middleware

Audit logging

9. Ví dụ thực tế Authentication vs Authorization trong E-commerce app

Các role trong hệ thống:

Ma trận phân quyền:

Implementation với RBAC + ownership check:

10. Checklist bảo mật Authentication vs Authorization cho dev team

Authentication Checklist

Authorization Checklist

Bạn còn thông tin nào về Authentication vs Authorization cần được giải đáp

Authentication vs Authorization: Cái nào quan trọng hơn?

JWT là Authentication hay Authorization?

OAuth 2.0 là Authentication hay Authorization?

Sự khác biệt giữa RBAC và ABAC?

Tại sao 401 lại gọi là "Unauthorized" dù có nghĩa là chưa xác thực?

Có nên lưu JWT trong localStorage không?

Đội ngũ giáo viên của trung tâm gồm những ai? Làm sao để trung tâm đảm bảo được chất lượng giảng dạy của giáo viên?

Giáo trình có hỗ trợ đa phương tiện như video, bài giảng online không?

Giảng viên có hỗ trợ học viên ngoài giờ không?

Có yêu cầu gì về thiết bị học tập không (máy tính, tai nghe, phần mềm…)?

Với lớp học online, em cần chuẩn bị gì để đảm bảo học hiệu quả?

Trung tâm có cấp chứng chỉ sau khi hoàn thành khóa học không?

Trung tâm có buổi học thử trước khi đăng ký khóa học chính thức không?

Giáo trình và tài liệu học được lấy từ nguồn nào? Trung tâm có gửi tài liệu bản mềm không?

Chương trình được xây dựng theo chuẩn nào?

Các tin tức khác

Lộ trình học bảo mật Web cho Developer từ A–Z (2026)

7 lỗ hổng bảo mật web developer hay bỏ sót dù đã có mã hóa HTTPS

Lỗ hổng bảo mật thường gặp trong hệ thống tích hợp AI