Mô hình ứng dụng web client-server luôn được áp dụng rộng rãi. Việc kiểm soát truy cập là chỉ cho phép các máy khách được ủy quyền truy cập vào tài nguyên của máy chủ phụ trợ bằng cách xác thực máy khách và cung cấp quyền truy cập cấp chi tiết dựa trên việc khách hàng là ai.

Bài đăng này tập trung vào ba mẫu kiến trúc giải pháp ngăn chặn các máy khách trái phép truy cập vào các máy chủ phụ trợ ứng dụng web. Có nhiều dịch vụ AWS được áp dụng trong các mẫu kiến trúc này để đáp ứng các yêu cầu của các trường hợp sử dụng khác nhau.

Luồng mã xác thực OAuth 2.0

Hình 1 thể hiện các nguyên tắc cơ bản cho tất cả các mẫu kiến trúc được thảo luận trong bài đăng này. Blog Tìm hiểu các khoản cấp OAuth 2.0 của nhóm người dùng Amazon Cognito mô tả chi tiết về các khoản tài trợ OAuth 2.0 khác nhau, có thể thay đổi quy trình ở một mức độ nào đó.

Hình 1. Luồng mã xác thực OAuth 2.0 điển hình

Các mẫu kiến trúc được nêu chi tiết trong bài đăng này sử dụng Amazon Cognito làm máy chủ ủy quyền và các instance Amazon Elastic Compute Cloud làm máy chủ tài nguyên. Máy khách có thể là bất kỳ ứng dụng front-end nào, chẳng hạn như ứng dụng di động, gửi yêu cầu đến máy chủ tài nguyên để truy cập tài nguyên được bảo vệ.

Pattern 1

Hình 2 là một mẫu kiến trúc giảm tải công việc xác thực máy khách sang  Application Load Balancer (ALB).

Hình 2. Tích hợp Application Load Balancer với Amazon Cognito

ALB có thể được sử dụng để xác thực khách hàng thông qua nhóm người dùng của Amazon Cognito:

1. Máy khách gửi yêu cầu HTTP đến endpoint ALB mà không có cookie phiên xác thực.
2. ALB chuyển hướng yêu cầu đến endpoint xác thực Amazon Cognito. Khách hàng được xác thực bởi Amazon Cognito.
3. Máy khách được chuyển hướng trở lại ALB với mã xác thực.-
4. ALB sử dụng mã xác thực để lấy mã thông báo truy cập từ endpoint mã thông báo Amazon Cognito và cũng sử dụng mã truy cập để nhận xác nhận quyền sở hữu của khách hàng từ endpoint Amazon Cognito UserInfo.
5. ALB chuẩn bị cookie phiên xác thực chứa dữ liệu được mã hóa và chuyển hướng yêu cầu của khách hàng bằng cookie phiên. Khách hàng sử dụng cookie phiên cho tất cả các yêu cầu khác. ALB xác thực cookie phiên và quyết định xem liệu yêu cầu có thể được chuyển đến các mục tiêu của nó hay không.
6. Yêu cầu đã xác thực được chuyển tiếp đến các cá thể phụ trợ với ALB thêm tiêu đề HTTP chứa dữ liệu từ mã thông báo truy cập và thông tin xác nhận quyền sở hữu của người dùng.
7. Máy chủ phụ trợ có thể sử dụng thông tin trong các tiêu đề được thêm vào ALB để kiểm soát quyền cấp chi tiết.

Điểm mấu chốt của mẫu này là ALB duy trì toàn bộ bối cảnh xác thực bằng cách kích hoạt xác thực máy khách với Amazon Cognito và chuẩn bị cookie phiên xác thực cho máy khách. URL gọi lại đăng nhập của Amazon Cognito trỏ tới ALB, cho phép ALB truy cập vào mã xác thực.

Bạn có thể tìm thấy thêm chi tiết về mẫu này trong tài liệu Xác thực người dùng bằng Application Load Balancer.

Pattern 2

Mô hình được minh họa trong Hình 3 giảm tải công việc xác thực máy khách tới Amazon API Gateway.

Hình 3. Tích hợp Amazon API Gateway với Amazon Cognito

API Gateway có thể hỗ trợ cả REST và HTTP API. API Gateway có tích hợp với Amazon Cognito, trong khi nó cũng có thể kiểm soát quyền truy cập vào các API HTTP bằng trình cấp quyền JSON Web Token (JWT), tương tác với Amazon Cognito. ALB có thể được tích hợp với API Gateway. Khách hàng có trách nhiệm xác thực với Amazon Cognito để lấy mã thông báo truy cập.

1. Máy khách bắt đầu xác thực với Amazon Cognito để lấy mã thông báo truy cập.
2. Máy khách gửi yêu cầu API REST hoặc API HTTP với tiêu đề chứa mã thông báo truy cập.
3. API Gateway được định cấu hình để có:
   • Nhóm người dùng Amazon Cognito với tư cách là người ủy quyền xác thực mã thông báo truy cập trong yêu cầu API REST hoặc
   • Người ủy quyền JWT, tương tác với nhóm người dùng Amazon Cognito để xác thực mã thông báo truy cập trong yêu cầu API HTTP.
4. Sau khi mã thông báo truy cập được xác thực, yêu cầu API REST hoặc HTTP được chuyển tiếp đến ALB và:
   • API Gateway có thể định tuyến API HTTP đến ALB riêng thông qua endpoint VPC.
   • Nếu ALB công khai được sử dụng, API Gateway có thể định tuyến cả API REST và API HTTP tới ALB.VPC endpoint
5. API Gateway không thể định tuyến trực tiếp API REST tới một ALB riêng. Nó có thể định tuyến đến Network Load Balancer (NLB) thông qua VPC endpoint. ALB riêng có thể được định cấu hình làm mục tiêu của NLB.

Những điểm chính của mô hình này là:

• API Gateway có các tính năng tích hợp để tích hợp nhóm người dùng Amazon Cognito để cho phép yêu cầu REST và / hoặc HTTP API.
• Một ALB có thể được định cấu hình để chỉ chấp nhận các yêu cầu API HTTP từ endpoint VPC do API Gateway đặt.

Pattern 3

Amazon CloudFront có thể kích hoạt các chức năng AWS Lambda được triển khai tại các vị trí cạnh AWS. Mẫu này (Hình 4) sử dụng một tính năng của Lambda@Edge, nơi nó có thể hoạt động như một người ủy quyền để xác thực các yêu cầu của khách hàng sử dụng mã thông báo truy cập, thường được bao gồm trong tiêu đề Ủy quyền HTTP.

Hình 4. Sử dụng Amazon CloudFront và AWS Lambda @ Edge với Amazon Cognito

Khách hàng có thể có quy trình xác thực cá nhân với Amazon Cognito để lấy mã thông báo truy cập trước khi gửi yêu cầu HTTP.

1. Máy khách bắt đầu xác thực với Amazon Cognito để lấy mã thông báo truy cập.
2. Máy khách gửi một yêu cầu HTTP với tiêu đề Ủy quyền, chứa mã thông báo truy cập, đến URL phân phối CloudFront.
3. CloudFront viewer request event kích hoạt khởi chạy chức năng tại Lambda @ Edge.
4. Hàm Lambda trích xuất mã thông báo truy cập từ tiêu đề Ủy quyền và xác thực mã thông báo truy cập với Amazon Cognito. Nếu mã thông báo truy cập không hợp lệ, yêu cầu sẽ bị từ chối.
5. Nếu mã thông báo truy cập được xác thực, yêu cầu sẽ được CloudFront ủy quyền và chuyển tiếp tới ALB. CloudFront được định cấu hình để thêm tiêu đề tùy chỉnh với giá trị chỉ có thể được chia sẻ với ALB.
6. ALB đặt quy tắc lắng nghe để kiểm tra xem yêu cầu đến có tiêu đề tùy chỉnh với giá trị được chia sẻ hay không. Điều này đảm bảo ALB hướng tới internet chỉ chấp nhận các yêu cầu được chuyển tiếp bởi CloudFront.
7. Để tăng cường bảo mật, giá trị được chia sẻ của tiêu đề tùy chỉnh có thể được lưu trữ trong  AWS Secrets Manager. Trình quản lý bí mật có thể kích hoạt một hàm Lambda được liên kết để thay đổi giá trị quan trọng theo định kỳ.
8. Hàm Lambda cũng cập nhật CloudFront cho tiêu đề tùy chỉnh được bổ sung và ALB cho giá trị được chia sẻ trong quy tắc trình nghe.

Những điểm chính của mô hình này là:

• Theo mặc định, CloudFront sẽ xóa tiêu đề ủy quyền trước khi chuyển tiếp yêu cầu HTTP đến nguồn gốc của nó. CloudFront cần được định cấu hình để chuyển tiếp Authorization header đến nguồn gốc của ALB. Máy chủ phụ trợ sử dụng mã thông báo truy cập để áp dụng các cấp độ chi tiết của quyền truy cập tài nguyên.
• Việc sử dụng Lambda @ Edge yêu cầu chức năng phải ở trong khu vực đông-1 chúng tôi.
• Giá trị của tiêu đề tùy chỉnh do CloudFront thêm vào được giữ như một bí mật mà chỉ có thể được chia sẻ với ALB.

Kết luận

Các mẫu kiến trúc được thảo luận trong bài đăng này là các phương pháp kiểm soát truy cập web dựa trên mã thông báo được các dịch vụ AWS hỗ trợ đầy đủ. Phương pháp này giảm tải luồng xác thực OAuth 2.0 từ máy chủ phụ trợ sang các dịch vụ AWS. Các dịch vụ do AWS quản lý có thể cung cấp khả năng phục hồi, khả năng mở rộng và khả năng hoạt động tự động để áp dụng kiểm soát truy cập cho ứng dụng web.

---

Bài được dịch từ bài viết trên AWS Blogs, bạn có thể xem bài viết gốc tại đây.