Xác thực là lớp bảo mật quan trọng nhất đối với các máy chủ MCP từ xa. Tìm hiểu tại sao OAuth 2.1 với OIDC là bắt buộc, cách ủy quyền token ngăn chặn cuộc tấn công Confused Deputy, và tại sao token passthrough là một trong những mẫu hình nguy hiểm nhất trong tích hợp AI.
Xác thực là cổng kiểm soát xác định liệu các khả năng mạnh mẽ của máy chủ MCP có sẵn cho người dùng hợp pháp hay cho kẻ tấn công. Nếu làm sai, mọi biện pháp kiểm soát bảo mật khác trở nên vô nghĩa — một máy chủ MCP không được xác thực hoặc được xác thực kém với quyền truy cập vào email, tệp và cơ sở dữ liệu là một lỗ hổng nghiêm trọng bất kể bạn đã tăng cường bảo mật mọi thứ khác tốt đến đâu.
Hướng dẫn của Dự án Bảo mật OWASP GenAI xác định xác thực và phân quyền là một trong tám lĩnh vực bảo mật cốt lõi cho các máy chủ MCP, với các yêu cầu cụ thể vượt xa những gì hầu hết các nhà phát triển triển khai theo mặc định. Bài viết này giải thích tại sao các yêu cầu đó tồn tại và cách triển khai chúng một cách chính xác.
Các máy chủ MCP đối mặt với bối cảnh xác thực phức tạp hơn các dịch vụ truyền thống vì chúng trung gian giữa nhiều bên chính:
Mỗi mối quan hệ này yêu cầu các biện pháp kiểm soát xác thực và phân quyền riêng. Một điểm yếu trong bất kỳ liên kết nào có thể bị khai thác để bỏ qua các liên kết khác.
Đối với các máy chủ MCP từ xa — những máy chủ được truy cập qua mạng thay vì thông qua STDIO cục bộ hoặc Unix sockets — hướng dẫn OWASP GenAI rất rõ ràng: OAuth 2.1 với OIDC là bắt buộc, không phải tùy chọn.
Yêu cầu này tồn tại vì:
OAuth 2.1 cung cấp kiểm soát phạm vi rõ ràng. Mọi token truy cập đều khai báo chính xác tài nguyên và hành động nào mà nó cho phép. Máy chủ MCP có thể xác minh tại thời điểm gọi công cụ rằng token được trình bày có phạm vi cụ thể cần thiết cho hành động đó — không chỉ là người dùng được xác thực, mà họ được phép cho hoạt động cụ thể này.
OIDC cung cấp danh tính mật mã. OpenID Connect bổ sung các khẳng định danh tính (ID token) mà máy chủ MCP có thể xác minh mà không cần khứ hồi đến nhà cung cấp danh tính. Máy chủ xác thực iss (issuer), aud (audience), exp (expiry) và chữ ký trên mỗi yêu cầu.
Các token OAuth 2.1 có thời hạn ngắn theo thiết kế. Đặc tả OAuth hiện đại (tổng hợp và thay thế các phương pháp hay nhất của OAuth 2.0) nhấn mạnh các token truy cập có thời hạn ngắn phải được làm mới thường xuyên. Điều này hạn chế cửa sổ thiệt hại nếu token bị xâm phạm.
Đừng chỉ xác thực token khi thiết lập phiên. Xác thực trên mỗi lần gọi công cụ:
def validate_token(token: str, required_scope: str) -> TokenClaims:
claims = jwt.decode(
token,
key=get_public_key(claims_preview['kid']),
algorithms=["RS256", "ES256"]
)
assert claims['iss'] == EXPECTED_ISSUER
assert EXPECTED_AUDIENCE in claims['aud']
assert claims['exp'] > time.time()
assert required_scope in claims['scope'].split()
return claims
Không bao giờ lưu kết quả xác thực trong bộ nhớ cache giữa các yêu cầu. Một token hợp lệ khi bắt đầu phiên có thể bị thu hồi giữa phiên.
Trong môi trường mà các MCP client thay đổi thường xuyên (ví dụ: các trợ lý AI khác nhau kết nối với cùng một máy chủ), các API key tĩnh hoặc bí mật được chia sẻ trước là không đủ. Sử dụng đăng ký client động với OAuth 2.1 hoặc OIDC để xác minh danh tính client tại thời điểm kết nối. Danh sách cho phép, chính sách kết nối được mã hóa cứng hoặc mutual TLS (mTLS) phù hợp cho các mối quan hệ tĩnh đã biết giữa các client và máy chủ cụ thể.
Bắt đầu dùng thử miễn phí ngay hôm nay và xem kết quả trong vài ngày.
Confused Deputy là một lỗ hổng phân quyền cổ điển với biểu hiện đặc biệt nguy hiểm trong kiến trúc MCP. Cuộc tấn công khai thác sự mơ hồ về quyền hạn của ai mà máy chủ MCP đang hành động.
Xem xét kịch bản này:
Khi Alice yêu cầu trợ lý AI “tóm tắt thư mục dự án của tôi”, máy chủ sử dụng token của Alice để truy cập các tệp của cô ấy — hành vi đúng. Nhưng nếu kẻ tấn công lừa máy chủ thực hiện yêu cầu sử dụng thông tin xác thực dịch vụ của chính nó (có thể thông qua cuộc tấn công đầu độc công cụ hoặc tiêm prompt gián tiếp), các quyền được nâng cao của máy chủ được sử dụng để truy cập các tệp mà Alice không được phép xem.
Máy chủ là “confused deputy” — nó đã bị lừa sử dụng quyền hạn của mình thay mặt cho người không có quyền hạn đó, hoạt động như một proxy cho việc leo thang đặc quyền.
Nhiều triển khai MCP chuyển tiếp token của client đến các API downstream để đơn giản. Điều này có vẻ trực quan — token của người dùng đại diện cho quyền của người dùng, vì vậy việc sử dụng nó cho tất cả các cuộc gọi downstream duy trì kiểm soát truy cập chính xác.
Vấn đề: các API downstream nhận ra máy chủ MCP là một trung gian đáng tin cậy có thể cấp các yêu cầu sử dụng cấp độ danh tính của máy chủ, không phải cấp độ của token người dùng được chuyển tiếp. Và nếu máy chủ MCP bao giờ hành động theo sáng kiến của chính nó — thông qua việc ra quyết định AI mà người dùng không yêu cầu rõ ràng — nó có thể sử dụng thông tin xác thực của chính nó thay vì token của người dùng.
Chuyển tiếp token người dùng cũng:
Thay vì chuyển tiếp token của client, máy chủ MCP nên lấy các token của riêng nó để truy cập dịch vụ downstream bằng cách sử dụng luồng On-Behalf-Of (OBO) của OAuth:
Người dùng xác thực với MCP client → client nhận token truy cập người dùng
MCP client trình bày token người dùng cho máy chủ MCP
Máy chủ MCP trao đổi token người dùng lấy token máy chủ thông qua luồng OBO:
POST /token
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
assertion=<user_access_token>
scope=<minimum_required_scope>
Máy chủ MCP sử dụng token OBO của riêng nó cho các cuộc gọi downstream
Token OBO:
Hướng dẫn OWASP GenAI đưa ra khuyến nghị cụ thể: cấp token truy cập có thời hạn được đo bằng phút, không phải giờ. Điều này áp dụng cho cả các token mà máy chủ MCP chấp nhận từ client và các token mà nó lấy để truy cập dịch vụ downstream.
Một token truy cập bị đánh cắp có giá trị trong toàn bộ thời hạn của nó bất kể người dùng hợp pháp đã đăng xuất, thay đổi mật khẩu hay thu hồi phiên của họ. Một token 24 giờ bị đánh cắp vào đầu phiên cung cấp cho kẻ tấn công 24 giờ truy cập liên tục. Một token 5 phút bị đánh cắp giữa phiên cung cấp tối đa 5 phút.
Token có thời hạn ngắn cũng thực thi các sự kiện xác thực lại thường xuyên, cung cấp cơ hội để:
Mỗi token chỉ nên mang các phạm vi cần thiết cho hoạt động cụ thể đang được thực hiện. Đừng cấp token với phạm vi read:files write:files delete:files khi lệnh gọi công cụ hiện tại chỉ cần read:files. Điều này hạn chế thiệt hại nếu token bị chặn hoặc mô hình bị thao túng thành các lệnh gọi công cụ không mong muốn.
def get_tool_token(user_id: str, tool_name: str) -> str:
# Ánh xạ công cụ đến các phạm vi tối thiểu cần thiết
required_scopes = TOOL_SCOPE_MAP[tool_name]
return oauth_client.get_token(
subject=user_id,
scopes=required_scopes,
lifetime_seconds=300 # Thời hạn 5 phút
)
Nhận các mẹo, xu hướng và ưu đãi mới nhất miễn phí.
Một sai lầm phổ biến là sử dụng ID phiên làm proxy phân quyền: nếu một yêu cầu mang ID phiên hợp lệ, máy chủ cho rằng nó được phép. Điều này nhầm lẫn quản lý trạng thái với xác minh danh tính.
Mô hình đúng: ID phiên quản lý trạng thái hội thoại. Phân quyền được xác minh độc lập trên mỗi yêu cầu bằng cách xác thực các claims của token OAuth. Ngay cả một yêu cầu mang ID phiên hợp lệ cũng phải trình bày một token OAuth hợp lệ, chưa hết hạn, có phạm vi phù hợp trước khi bất kỳ lệnh gọi công cụ nào được cho phép.
Điều này quan trọng vì ID phiên có thể bị đánh cắp, đoán hoặc phát lại theo những cách mà token OAuth — mang đảm bảo toàn vẹn mật mã — không thể.
Thay vì triển khai các kiểm tra phân quyền rải rác trong các trình xử lý công cụ riêng lẻ, hướng dẫn OWASP GenAI khuyến nghị một cổng chính sách tập trung mà:
Tập trung hóa đảm bảo các chính sách được áp dụng nhất quán trên tất cả các công cụ và tác nhân. Một kiểm tra phân quyền cụ thể của công cụ có thể bị quên hoặc bỏ qua trong quá trình phát triển; một kiểm tra cổng thì không thể.
Đối với các máy chủ MCP từ xa, thanh bảo mật xác thực tối thiểu là:
Arshia là Kỹ sư Quy trình AI tại FlowHunt. Với nền tảng về khoa học máy tính và niềm đam mê AI, anh chuyên tạo ra các quy trình hiệu quả tích hợp công cụ AI vào các nhiệm vụ hàng ngày, nâng cao năng suất và sự sáng tạo.
Đội ngũ bảo mật của chúng tôi đánh giá cấu hình xác thực MCP, xử lý token và luồng phân quyền theo tiêu chuẩn OWASP GenAI. Xác định các lỗ hổng trước khi kẻ tấn công phát hiện.
Dự án Bảo mật GenAI OWASP định nghĩa tiêu chuẩn tối thiểu gồm năm danh mục cho triển khai máy chủ MCP an toàn. Sử dụng danh sách kiểm tra này để đánh giá tình t...
MCP server tạo ra bề mặt tấn công độc đáo kết hợp rủi ro API truyền thống với các mối đe dọa đặc thù của AI. Tìm hiểu 6 lỗ hổng nghiêm trọng được xác định bởi O...
Attestable MCP Server mang lại xác thực từ xa và điện toán bảo mật cho quy trình FlowHunt, cho phép các tác nhân AI và khách hàng xác minh tính toàn vẹn của máy...
Đồng Ý Cookie
Chúng tôi sử dụng cookie để cải thiện trải nghiệm duyệt web của bạn và phân tích lưu lượng truy cập của mình. See our privacy policy.