Khám phá ANCP – Giao thức đăng nhập tiên tiến dành riêng cho các AI agent, giúp chúng truy cập an toàn vào dữ liệu nhạy cảm mà không cần VPN, OAuth hay API Keys tĩnh. Tăng cường bảo mật Zero-Trust và khả năng tự chủ của AI.

Lê Lân

22/08/2025

Khám phá ANCP, giao thức xác thực tiên tiến dành riêng cho các đặc vụ AI, giúp chúng truy cập hệ thống an toàn mà không cần VPN, OAuth hay API Keys tĩnh. Tận dụng PGP, Zero-trust và khả năng suy luận danh tính ngay trong prompt, ANCP mở ra kỷ nguyên mới cho AI tự chủ.

Lê Lân

14/08/2025

Chào các bạn! Trong bài viết này, mình sẽ cùng các bạn 'mổ xẻ' những chiến lược xác thực (Authentication) phổ biến trong thế giới lập trình. Nghe có vẻ khô khan, nhưng mình hứa sẽ biến nó thành câu chuyện thú vị để bạn dễ dàng hình dung và áp dụng nhé!Bạn có bao giờ tự hỏi 'xác thực' và 'ủy quyền' trong lập trình nghĩa là gì không? Nghe tên thì 'sang chảnh' nhưng thực ra chúng rất gần gũi với cuộc sống hằng ngày của chúng ta đó!<b>Xác thực (Authentication):</b> Tưởng tượng bạn đang đứng trước cửa một câu lạc bộ đêm sang chảnh. Anh bảo vệ hỏi bạn 'Anh/chị là ai? Có phải là thành viên không?'. Bạn chìa thẻ thành viên (hoặc chứng minh thư, vân tay, hay một chiếc vé bí mật nào đó). Anh bảo vệ kiểm tra để xem bạn CÓ THỰC SỰ LÀ NGƯỜI ĐÓ KHÔNG. Đây chính là xác thực! Mục đích là để máy tính biết 'À, đây đúng là bạn đấy!'<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/bouncer_checking_id.png' alt='Anh bảo vệ kiểm tra ID'> <b>Ủy quyền (Authorization):</b> Sau khi anh bảo vệ xác nhận 'Ok, bạn đúng là thành viên VIP!', thì bây giờ đến lượt câu hỏi 'Vậy bạn được phép làm gì trong này?'. Bạn được vào phòng VIP không? Được gọi đồ uống miễn phí không? Hay chỉ được đứng ở khu vực chung? Việc quyết định bạn CÓ QUYỀN LÀM GÌ sau khi đã được xác thực, đó chính là ủy quyền. Nó định nghĩa 'Bạn được phép đọc, viết, xóa cái gì?' trong hệ thống.<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/access_levels.png' alt='Các cấp độ truy cập khác nhau'> Giờ thì đã rõ 'bạn là ai' và 'bạn được làm gì' rồi, chúng ta cùng khám phá những 'chiêu' mà các hệ thống dùng để làm điều đó nhé!<b>1. Basic Authentication – 'Ông nội' của các phương pháp xác thực</b><br>Kể cho bạn nghe về Basic Authentication, hay còn gọi là 'Ông nội' của các phương pháp xác thực! Đây là kiểu đơn giản nhất, kiểu như 'nhà nghèo' mà vẫn muốn có bảo vệ ấy mà.<br>Cách hoạt động cực kỳ đơn giản:<br>1. Bạn nhập tên người dùng (username) và mật khẩu (password) của mình.<br>2. Hệ thống sẽ 'kết nối' chúng lại với nhau theo kiểu `username:password` rồi 'ngụy trang' bằng cách mã hóa Base64 (kiểu mã hóa mà ai cũng có thể giải mã ngược lại được, không phải mã hóa bảo mật đâu nhé!).<br>3. Cái chuỗi 'ngụy trang' này được nhét vào phần 'Authorization' của mỗi yêu cầu gửi lên server, kèm theo chữ 'Basic' ở đầu. Ví dụ, nếu email là `[email protected]` và mật khẩu là `1234`, thì nó sẽ trông như vầy: `Authorization: Basic ZXhhbXBsZUBleGFtcGxlLmNvbToxMjM0`.<br>4. Khi server nhận được, nó sẽ 'gỡ bỏ lớp ngụy trang' (giải mã Base64), so sánh với thông tin lưu trong cơ sở dữ liệu. Nếu khớp, bạn được vào!<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/basic_auth_simple.png' alt='Mô hình Basic Authentication đơn giản'> <b>Ưu điểm:</b><br>- Dễ như ăn kẹo: Triển khai cực kỳ đơn giản, không cần đau đầu nhiều.<br>- Dùng được ngay: Phù hợp cho những dịch vụ không cần bảo mật quá cao, kiểu như mấy trang xem thời tiết ấy mà.<br><b>Nhược điểm:</b><br>- 'Yếu sinh lý' bảo mật: Chuỗi mã hóa Base64 thì ai cũng có thể giải mã ngược lại được. Tưởng tượng bạn ghi mật khẩu lên một mảnh giấy trong suốt rồi giấu dưới tấm kính vậy! Rất dễ bị lộ nếu không dùng HTTPS.<br>- Dễ bị tấn công: Cứ mỗi yêu cầu là lại gửi cả username/password đi, tăng nguy cơ bị chặn giữa đường.<b>2. JWT Authentication (JSON Web Tokens) – 'Phù thủy' niêm phong thông tin</b><br>JWT hay JSON Web Tokens – Nghe tên thôi đã thấy 'pro' rồi đúng không? Đây là một 'phù thủy' trong việc truyền thông tin an toàn giữa các bên, sử dụng các đối tượng JSON nhỏ gọn. Tưởng tượng nó như một lá thư niêm phong có dấu kiểm chứng, đảm bảo nội dung không bị ai đọc trộm hay sửa đổi trên đường đi!<br>Một JWT được cấu tạo từ 3 phần chính, được ngăn cách bởi dấu chấm (.), và mỗi phần đều được mã hóa Base64Url:<br><b>a. Header (Phần đầu):</b> Giống như bì thư, ghi rõ 'Thư này dùng mã khóa gì để niêm phong, và đây là loại thư gì (JWT)?'. Ví dụ: `{ 'alg': 'HS256', 'typ': 'JWT' }` (À, dùng thuật toán HS256, đây là JWT nhé!)<br><b>b. Payload (Nội dung):</b> Đây là 'trái tim' của JWT, chứa thông tin mà các bên muốn trao đổi. Nó giống như phần nội dung lá thư, ghi rõ bạn là ai, bạn có quyền gì, và thư này được viết khi nào, bao giờ hết hạn. Các trường như `iat` (thời gian tạo), `exp` (thời gian hết hạn) rất quan trọng để đảm bảo 'lá thư' vẫn còn hiệu lực và an toàn. Ví dụ: `{ "sub": "1234567890", "name": "John Doe", "admin": true, "iat": 1516239022 }` (À, ID là 1234567890, tên John Doe, là admin, được tạo lúc 1516239022).<br><b>c. Signature (Chữ ký):</b> Đây là phần 'niêm phong' và 'dấu kiểm chứng' cực kỳ quan trọng! Nó được tạo ra bằng cách 'pha trộn' Header, Payload và một 'mật khẩu bí mật' (secret key) mà chỉ server mới biết, thông qua một thuật toán mã hóa (như SHA256). Chữ ký này đảm bảo rằng không ai có thể 'đọc trộm' hay 'sửa đổi' nội dung của JWT. Nếu có ai đó cố tình chỉnh sửa dù chỉ một dấu chấm phẩy trong Header hay Payload, thì chữ ký sẽ lập tức 'mách lẻo' rằng 'Ê, có đứa động vào thư này rồi nhé!', và token sẽ bị coi là không hợp lệ. Ví dụ về cách tạo chữ ký dùng SHA 256: `HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)`<br>Khi kết hợp cả ba phần này lại, bạn sẽ có một 'lá bùa' JWT trông siêu dài và bí ẩn như thế này: `<Base64Url-encoded header>.<Base64Url-encoded payload>.<Base64Url-encoded signature>` hoặc cụ thể hơn là `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.KMUFsIDTnFmyG3nMiGM6H9FNFUROf3wh7SmqJp-QV30`.<br>À mà, JWT có hai bước kiểm tra quan trọng:<br>- <b>Xác minh (Verification):</b> Kiểm tra chữ ký để đảm bảo 'lá bùa' này đúng là do server tạo ra và không bị ai 'phù phép' (thay đổi) trên đường đi.<br>- <b>Xác nhận (Validation):</b> Kiểm tra các thông tin bên trong Payload (như hạn sử dụng) để đảm bảo 'lá bùa' vẫn còn hiệu lực và đúng 'đối tượng'.<br><b>Vậy JWT Authentication hoạt động thế nào trong thực tế?</b> Nó thường dùng kết hợp hai loại 'vé' đặc biệt:<br><b>a. Access Token (Vé vào cửa ngắn hạn):</b> Tưởng tượng Access Token như một 'vé vào cửa' mà bạn nhận được sau khi đã trình diện ID thành công. Vé này có hạn sử dụng RẤT NGẮN (vài phút đến vài giờ). Mỗi khi bạn muốn vào một 'khu vực VIP' nào đó trong ứng dụng, bạn sẽ trình cái vé này lên. Server thấy vé còn hạn và hợp lệ thì cho bạn vào. Hết hạn là bạn phải xin vé mới!<br><b>b. Refresh Token (Thẻ VIP gia hạn dài hạn):</b> Còn Refresh Token thì sao? Nó giống như một 'thẻ VIP' dài hạn hơn nhiều (vài ngày, vài tuần). Khi 'vé vào cửa' của bạn hết hạn, thay vì phải về nhà trình lại ID gốc (đăng nhập lại), bạn chỉ cần dùng 'thẻ VIP' này để 'đổi' lấy một 'vé vào cửa' mới toanh mà không cần đăng nhập lại từ đầu. Thường thì Refresh Token được cất kỹ trong 'ngăn kéo an toàn' (HTTP-Only secure cookie) ở phía client, còn ở server thì sẽ được lưu trong database để dễ quản lý và thu hồi nếu cần.<br><b>Quy trình JWT Auth (tổng hợp):</b><br>1. Bạn gửi 'thông tin cá nhân' (tên đăng nhập, mật khẩu) cho 'người gác cổng' (authentication server).<br>2. 'Người gác cổng' kiểm tra thông tin. Nếu 'đúng người', bạn sẽ được phát 2 thứ: một 'vé vào cửa' (Access Token) và một 'thẻ VIP gia hạn' (Refresh Token).<br>3. Bạn cất giữ cả hai thứ này cẩn thận. Mỗi khi muốn làm gì đó trong hệ thống, bạn sẽ dùng 'vé vào cửa' (Access Token) gửi kèm trong yêu cầu.<br>4. Nếu 'vé vào cửa' hết hạn (mà chắc chắn nó sẽ hết!), bạn đừng lo lắng! Lôi 'thẻ VIP gia hạn' (Refresh Token) ra, gửi cho 'người gác cổng' và yêu cầu một 'vé vào cửa' mới.<br>5. 'Người gác cổng' kiểm tra 'thẻ VIP'. Nếu 'thẻ' còn hiệu lực, bạn sẽ được cấp 'vé vào cửa' mới.<br>6. Và cứ thế, bạn lại tiếp tục 'tung hoành' trong hệ thống với 'vé vào cửa' mới toanh!<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ft3k5ipxj8ie9w5dvk4l.png' alt='Sơ đồ luồng JWT Authentication'> <b>Ưu điểm (Thích ở JWT):</b><br>- Không cần 'nhớ mặt' (Stateless): JWT tự chứa mọi thông tin cần thiết, server không cần lưu 'phiên làm việc' của bạn. Điều này siêu tiện lợi cho các hệ thống lớn, phân tán.<br>- Dễ dàng 'nhân bản' (Scalability): Vì không cần lưu trạng thái trên server, bạn có thể dễ dàng mở rộng hệ thống sang nhiều server khác mà không sợ 'rối loạn'.<br>- Linh hoạt như 'diễn viên múa' (Flexibility): Bạn có thể nhét đủ thứ thông tin 'tùy chỉnh' vào Payload, giúp JWT cực kỳ linh hoạt cho nhiều mục đích khác nhau.<br><b>Nhược điểm (Không thích lắm):</b><br>- 'Phát tướng' (Token Size): Nếu bạn nhét quá nhiều thông tin vào Payload, JWT có thể trở nên khá cồng kềnh, ảnh hưởng đến hiệu suất đường truyền.<br>- 'Hớ hênh' nếu không cẩn thận (Security): Nếu JWT bị lộ (bị đánh cắp) hoặc chữ ký không được bảo vệ tốt, kẻ xấu có thể lợi dụng. Bạn phải biết cách lưu trữ và xử lý JWT một cách cực kỳ an toàn.<br>Một ví dụ thực tế về triển khai JWT Authentication bằng Golang: <a href="https://github.com/the-arcade-01/golang-jwt-authentication">https://github.com/the-arcade-01/golang-jwt-authentication</a><b>3. OAuth 2.0 Authorization – 'Người đưa thư' đáng tin cậy</b><br>OAuth 2.0 (Open Authorization) – Nghe cái tên thì có vẻ giống Auth nhưng thực chất là Authorization nhé! Nó không phải để xác thực bạn là ai, mà là để cho phép một 'anh bạn' ứng dụng khác được quyền làm gì đó thay mặt bạn, mà KHÔNG CẦN biết mật khẩu của bạn. Tưởng tượng nó như việc bạn ủy quyền cho 'người đưa thư' được lấy hộ bưu phẩm của bạn, nhưng bạn không bao giờ phải đưa chìa khóa nhà cho anh ta cả!<br>Hãy hình dung thế này: Bạn có một ứng dụng chỉnh sửa ảnh siêu xịn, và bạn muốn ứng dụng này truy cập vào kho ảnh trên Google Drive của mình để lấy ảnh về chỉnh sửa. Bạn có muốn đưa luôn tài khoản Google của mình cho cái app đó không? Chắc chắn là KHÔNG rồi! Lúc này, OAuth 2.0 ra tay cứu nguy!<br>1. Ứng dụng chỉnh sửa ảnh sẽ 'nói' với Google (nhà cung cấp dịch vụ xác thực) rằng 'Tôi muốn truy cập ảnh của bạn X' (là bạn đó).<br>2. Google sẽ hỏi bạn: 'Bạn có đồng ý cho ứng dụng này truy cập ảnh của bạn không?' Kèm theo đó là danh sách các quyền mà ứng dụng yêu cầu (chỉ đọc ảnh thôi, hay có cả chỉnh sửa, xóa?).<br>3. Nếu bạn đồng ý, Google sẽ cấp cho ứng dụng đó một 'giấy phép đặc biệt' (Access Token) để truy cập vào đúng những gì bạn đã cho phép (ví dụ: chỉ ảnh, không phải email hay tài liệu khác).<br>4. Giờ thì ứng dụng có thể dùng 'giấy phép' đó để 'vào' Google Drive của bạn, lấy ảnh về mà không cần biết mật khẩu Google của bạn. An toàn, tiện lợi phải không nào? Ứng dụng của bạn chỉ cần `client_id` và `client_secret` để giao tiếp với nhà cung cấp dịch vụ OAuth, chứ không cần biết thông tin đăng nhập của bạn.<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://dev-to-uploads.s3.amazonaws.com/uploads/articles/newkidtu91hdzkov338k.png' alt='Sơ đồ luồng OAuth 2.0'> <b>Ưu điểm (OAuth 2.0 đỉnh cao ở chỗ):</b><br>- An toàn hơn 'két sắt': Người dùng không cần chia sẻ thông tin đăng nhập của mình cho ứng dụng bên thứ ba, giảm thiểu rủi ro bị đánh cắp tài khoản.<br>- Quyền hạn 'may đo': Bạn có thể cấp quyền rất chi tiết: chỉ đọc, chỉ ghi, chỉ truy cập ảnh, không truy cập email... Đảm bảo ứng dụng chỉ làm đúng những gì bạn cho phép.<br>- Trải nghiệm 'mượt mà': Dùng tài khoản Google, Facebook sẵn có để đăng nhập vào ứng dụng khác? Quá tiện rồi còn gì!<br><b>Nhược điểm (Cũng có cái 'hóc búa'):</b><br>- Phức tạp như 'mạng nhện': Triển khai OAuth 2.0 không hề đơn giản, có nhiều luồng (flow) và cần cân nhắc kỹ về bảo mật.<br>- Quản lý 'giấy phép' (Token Management): Cũng như JWT, việc quản lý Access Token và Refresh Token cần rất cẩn thận để tránh bị đánh cắp hay lạm dụng.<br>- Phụ thuộc 'người lớn': Bạn đang giao phó việc xác thực cho bên thứ ba (như Google, Facebook), nếu họ có vấn đề thì hệ thống của bạn cũng bị ảnh hưởng.<br>Bạn có thể tham khảo một ví dụ thực tế về triển khai OAuth 2.0 bằng Golang & React.js: <a href="https://github.com/the-arcade-01/react-golang-oauth-flow">https://github.com/the-arcade-01/react-golang-oauth-flow</a><b>4. Session-Based Authentication – 'Thẻ thư viện' truyền thống</b><br>Session-Based Authentication – Kiểu xác thực 'truyền thống', giống như bạn đi vào thư viện và được phát một 'thẻ thư viện' tạm thời vậy. Khi bạn đăng nhập thành công, server sẽ tạo ra một cái mã định danh duy nhất (gọi là 'Session ID'), lưu nó vào 'sổ ghi chép' của server (database) và gửi trả lại cho bạn. Bạn thì cất cái 'thẻ' này vào 'ví' (cookies) ở trình duyệt.<br><b>Session-Based Authentication hoạt động như thế nào?</b><br>1. Bạn 'gõ cửa' (đăng nhập) với tên và mật khẩu.<br>2. Server kiểm tra, thấy bạn là 'người nhà', liền cấp cho bạn một 'vé thông hành' độc nhất vô nhị (Session ID). Cái vé này được lưu trên server (có thể là trong một database siêu nhanh như Redis) kèm theo 'hạn sử dụng' (TTL – Time To Live). Sau đó, server gửi 'vé' này về cho bạn.<br>3. Trình duyệt của bạn nhận được 'vé' và tự động lưu nó vào 'kho bánh quy' (cookies) để dùng cho các lần sau.<br>4. Mỗi lần bạn gửi yêu cầu lên server, trình duyệt lại tự động gửi kèm cái 'vé thông hành' này.<br>5. Server nhận được 'vé', liền tra cứu trong 'sổ ghi chép' xem 'vé' này có tồn tại không, còn hạn không. Nếu hợp lệ, bạn được 'thông quan'!<br>Khi bạn 'thoát khỏi thư viện' (đăng xuất), cái 'vé thông hành' này sẽ bị hủy trên server. Hoặc nếu bạn 'quên không trả vé', nó cũng sẽ tự động hết hạn và biến mất sau một thời gian nhất định.<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://dev-to-uploads.s3.amazonaws.com/uploads/articles/adoabql6s872k0wi1xzl.png' alt='Sơ đồ luồng Session-Based Authentication'> <b>Ưu điểm (Session-Based có gì hay?):</b><br>- Dễ triển khai: Khá đơn giản để thiết lập cho những ứng dụng nhỏ.<br>- Kiểm soát chặt chẽ: Server hoàn toàn nắm quyền kiểm soát Session ID, có thể dễ dàng hủy bỏ session nếu phát hiện điều gì đó bất thường (ví dụ, bạn đổi mật khẩu, server hủy session cũ ngay lập tức).<br>- An toàn hơn Basic Auth: Session ID thường được lưu trữ an toàn trong database chứ không phải truyền đi truyền lại mật khẩu.<br><b>Nhược điểm (Cũng có 'hạn chế' đấy!):</b><br>- 'Ghét' hệ thống phân tán: Rất hợp với các ứng dụng nguyên khối (monolithic) chỉ có một server. Nhưng với kiến trúc microservices (nhiều server nhỏ lẻ làm việc cùng nhau), việc quản lý Session ID trở nên phức tạp hơn nhiều. Bạn cần một 'người gác cổng' chung (API Gateway) và một 'kho chứa Session ID' tập trung để tất cả các server đều có thể 'tra cứu'.<br>- Khó mở rộng theo chiều ngang: Nếu muốn thêm server mới, bạn phải đảm bảo server mới đó cũng có thể truy cập được kho session chung, điều này đôi khi rắc rối.<b>Lời kết và Tài liệu tham khảo</b><br>Vậy là chúng ta đã cùng nhau 'du hành' qua thế giới của các chiến lược xác thực rồi! Hy vọng những ví dụ vui vẻ và cách giải thích 'dễ nhai' này đã giúp bạn hình dung rõ ràng hơn về từng loại.<br>Nếu bạn có bất kỳ câu hỏi nào, hay có ý tưởng nào hay ho muốn chia sẻ, đừng ngần ngại để lại bình luận phía dưới nhé! Mình luôn sẵn lòng 'buôn chuyện' cùng các bạn.<br>À, nhân tiện, trong bài này mình chưa đề cập đến RBAC (Role-Based Access Control) và ABAC (Attribute-Based Access Control) vì chúng thiên về mô hình kiểm soát quyền truy cập hơn là chiến lược xác thực. Tuy nhiên, nếu bạn tò mò muốn tìm hiểu thêm, đây là vài đường link 'xịn xò' mà bạn có thể tham khảo:<br><a href="https://www.okta.com/blog/2020/09/attribute-based-access-control-abac/">Blog của Okta về ABAC</a><br><a href="https://auth0.com/docs/manage-users/access-control/rbac">Blog của Auth0 về RBAC</a><br>Để viết bài này, mình cũng đã 'nhâm nhi' qua các tài liệu cực kỳ giá trị dưới đây. Nếu bạn muốn 'đi sâu' hơn nữa vào thế giới xác thực, đây là những 'bí kíp' mà bạn không nên bỏ qua:<br><a href="https://auth0.com/docs/secure">https://auth0.com/docs/secure</a><br><a href="https://auth0.com/intro-to-iam/what-is-oauth-2">https://auth0.com/intro-to-iam/what-is-oauth-2</a><br><a href="https://roadmap.sh/api-design?fl=0">https://roadmap.sh/api-design?fl=0</a>

Lê Lân

17/07/2025

Tìm hiểu cách thuật toán Bcrypt xác minh mật khẩu mà vẫn đảm bảo tính bảo mật cao, từ khái niệm hashing một chiều đến vai trò của 'salt' và 'cost' giúp tạo ra các chuỗi băm duy nhất và an toàn.

Lê Lân

26/06/2025

Tóm tắt buổi tech talk về JWTs trong Go, hướng dẫn triển khai xác thực an toàn, cấu trúc JWT, luồng hoạt động và những lỗi cần tránh. Tìm hiểu cách tạo, xác thực token hiệu quả.

Lê Lân

18/06/2025