Tổng quan về OAuth 2.0 hoặc JWT Authentication

OAuth 2.0 và JSON Web Token (JWT) đều được sử dụng rộng rãi trong ngữ cảnh xác thực và ủy quyền API. Chúng phục vụ các mục đích khác nhau, và trong một số trường hợp, chúng được sử dụng cùng nhau. Hãy cùng thảo luận về từng cái và cách chúng góp phần đảm bảo truy cập an toàn đến các tài nguyên trong một khung API. Hình bên dưới mô tả xác thực API.

OAuth 2.0

Open Authorization 2.0 (OAuth 2.0) là một khung tiêu chuẩn mở cho phép ủy quyền truy cập, thường được sử dụng để bảo mật các ứng dụng Web và APIs. Nó cung cấp một cách để người dùng cho phép các ứng dụng bên thứ ba truy cập hạn chế vào tài nguyên của họ mà không cần chia sẻ thông tin đăng nhập của mình. OAuth 2.0 được áp dụng rộng rãi cho xác thực và ủy quyền trong nhiều trường hợp, bao gồm đăng nhập xã hội, truy cập di động và bảo mật API.

Các thành phần chính của OAuth 2.0:

• Resource Owner (Người sở hữu tài nguyên): Thực thể có thể cấp quyền truy cập vào tài nguyên được bảo vệ. Thông thường là người dùng cuối.
• Client (Khách hàng): Ứng dụng yêu cầu quyền truy cập vào tài nguyên của người dùng. Có thể là ứng dụng Web hoặc di động.
• Authorization Server (Máy chủ ủy quyền): Máy chủ chịu trách nhiệm xác thực người dùng và nhận sự đồng ý của họ để cấp quyền truy cập cho khách hàng. Nó phát hành các token truy cập.
• Resource Server (Máy chủ tài nguyên): Máy chủ lưu trữ các tài nguyên được bảo vệ mà khách hàng muốn truy cập. Nó xác nhận các token truy cập và phục vụ các tài nguyên được yêu cầu.

Các loại ủy quyền của OAuth 2.0:

• Authorization Code Grant: Được sử dụng cho các ứng dụng Web nơi mà khách hàng có thể lưu trữ an toàn một client secret. Bao gồm quá trình hai bước: nhận mã ủy quyền và đổi mã đó lấy token truy cập.
• Implicit Grant: Thiết kế cho các ứng dụng di động hoặc ứng dụng một trang, nơi mà việc lưu trữ client secret không khả thi. Token truy cập được nhận trực tiếp mà không cần đổi mã ủy quyền.
• Resource Owner Password Credentials Grant: Cho phép khách hàng nhận trực tiếp thông tin đăng nhập của người dùng và đổi chúng lấy token truy cập. Thường không được khuyến khích do các vấn đề bảo mật, trừ khi khách hàng rất đáng tin cậy.
• Client Credentials Grant: Được sử dụng khi khách hàng hành động thay mặt cho chính nó và không thay mặt cho người dùng. Đổi trực tiếp thông tin đăng nhập của khách hàng lấy token truy cập.

Quy trình hoạt động của OAuth 2.0:

1. Authorization Request (Yêu cầu ủy quyền): Khách hàng yêu cầu ủy quyền từ người dùng bằng cách chuyển hướng họ đến máy chủ ủy quyền.
2. User Authorization (Ủy quyền người dùng): Người dùng xác thực và cấp quyền cho khách hàng.
3. Token Request (Yêu cầu token): Khách hàng đổi ủy quyền nhận được để lấy token truy cập.
4. Accessing Protected Resource (Truy cập tài nguyên được bảo vệ): Khách hàng sử dụng token truy cập để truy cập tài nguyên được bảo vệ trên máy chủ tài nguyên.

OAuth 2.0 Tokens

Access Token:

• Đại diện cho quyền truy cập đã được cấp cho khách hàng.
• Cung cấp quyền truy cập vào các tài nguyên cụ thể trong một khoảng thời gian nhất định.

Refresh Token:

• Được sử dụng để lấy token truy cập mới mà không cần người dùng xác thực lại.
• Thường có thời gian tồn tại dài hơn token truy cập.

Bảo mật

• Sử dụng HTTPS: Tất cả giao tiếp nên được thực hiện qua HTTPS để bảo mật việc truyền dữ liệu.
• Xác thực Token: Các máy chủ tài nguyên nên xác thực token trước khi xử lý yêu cầu.
• Yêu cầu Token: Khách hàng đổi quyền ủy quyền để lấy token truy cập.
• Hết hạn và Làm mới Token: Token truy cập nên có thời gian tồn tại ngắn, và token làm mới nên được sử dụng để lấy token truy cập mới.

JWT Authentication

JSON Web Token (JWT) là một phương pháp bảo mật API bằng cách sử dụng các token mã hóa JSON để đại diện cho việc xác thực và ủy quyền của người dùng. JWT được sử dụng rộng rãi nhờ tính đơn giản, gọn nhẹ và khả năng mang thông tin tự chứa. Nó thường được sử dụng trong các kịch bản xác thực không trạng thái, nơi máy chủ không lưu trữ dữ liệu phiên.

Các thành phần chính của JWT:

• Header (Tiêu đề): Thường bao gồm hai phần: loại token (JWT) và thuật toán ký, như HMAC SHA256 hoặc RSA.
  • Ví dụ Header:

{
  "alg": "HS256",
  "typ": "JWT"
}

• Payload (Nội dung): Chứa các tuyên bố (claims). Các tuyên bố là những phát biểu về một thực thể (thường là người dùng) và các dữ liệu bổ sung.
  • Ví dụ Payload:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

• Common Claims:
  • sub (subject): Xác định chủ thể chính của token.
  • iss (issuer): Xác định nơi phát hành token.
  • exp (expiration time): Chỉ định thời gian hết hạn sau đó token không được chấp nhận.
  • aud (audience): Xác định người nhận token.
  • iat (issued at): Chỉ định thời điểm token được phát hành.
• Ví dụ chữ ký:

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

Quy trình hoạt động của JWT Authentication:

1. Xác thực người dùng: Khi người dùng đăng nhập, máy chủ tạo một JWT chứa thông tin người dùng liên quan.
2. Phát hành token: Máy chủ ký JWT với khóa bí mật hoặc khóa riêng (trong trường hợp RSA), tạo ra JWT cuối cùng.
3. Phản hồi token: JWT được gửi đến khách hàng như một phần của phản hồi xác thực.
4. Xác thực máy chủ: Máy chủ xác minh tính toàn vẹn của JWT bằng khóa bí mật hoặc khóa công khai đã lưu trữ.
5. Ủy quyền người dùng: Máy chủ trích xuất và giải mã các tuyên bố trong payload để xác định danh tính và quyền hạn của người dùng.

Bảo mật:

• Thời hạn Token: Sử dụng token có thời gian ngắn và làm mới chúng thường xuyên bằng cách sử dụng token làm mới hoặc xác thực lại.
• Truyền tải bảo mật: Luôn sử dụng HTTPS để đảm bảo truyền tải bảo mật JWT giữa khách hàng và máy chủ.
• Bảo mật khóa: Bảo vệ khóa bí mật sử dụng để ký JWT. Nếu sử dụng mã hóa khóa công khai, bảo mật khóa riêng.
• Phạm vi và xác thực token: Xác thực các tuyên bố trong JWT, như thời gian hết hạn và nơi phát hành, để đảm bảo tính toàn vẹn của token.

Thiết lập kiểm soát truy cập dựa trên vai trò (RBAC)

Thiết lập kiểm soát truy cập dựa trên vai trò (RBAC) bao gồm xác định vai trò, gán quyền cho các vai trò đó, liên kết vai trò với người dùng và thực hiện kiểm soát truy cập dựa trên các vai trò này.

Hướng dẫn từng bước để thiết lập RBAC:

Bước 1: Xác định vai trò và quyền hạn:

Xác định các vai trò khác nhau tồn tại trong tổ chức hoặc hệ thống của bạn. Vai trò có thể dựa trên chức năng công việc, trách nhiệm hoặc bất kỳ tiêu chí nào khác liên quan đến tổ chức của bạn.

Bước 2: Định nghĩa quyền hạn:

Đối với mỗi vai trò, xác định các quyền hoặc hành động cụ thể mà người dùng được gán cho vai trò đó nên được phép thực hiện. Những quyền này nên chi tiết và được xác định rõ ràng để đảm bảo rằng người dùng chỉ có quyền truy cập vào các tài nguyên cần thiết cho vai trò của họ.

Bước 3: Gán quyền cho vai trò:

Khi parmions được xác định, hãy gán chúng cho các vai trò thích hợp. Bước này chủ yếu tạo ra một ánh xạ giữa các vai trò và các quyền tương ứng với từng vai trò. Tham khảo Hình bên dưới.

Ví dụ về ánh xạ:

Vai trò	Quyền hạn
Quản lý	CRUD trên tất cả các tài nguyên
Nhân viên	Đọc và cập nhật dữ liệu nhân viên
Khách hàng	Đọc chính sách công ty
Quản trị viên	Tạo và cập nhật hồ sơ của riêng mình

Bước 4. Gán người dùng vào các vai trò

Gán người dùng vào các vai trò tương ứng tốt nhất với trách nhiệm công việc hoặc chức năng của họ trong tổ chức. Mỗi người dùng có thể được gán cho một hoặc nhiều vai trò, tùy thuộc vào yêu cầu truy cập của họ. Xem Hình bên dưới.

Ví dụ về gán vai trò:

Người dùng	Vai trò được gán
John Doe	Quản trị viên
Jane Smith	Quản lý, Nhân viên
Alice Brown	Nhân viên, Khách hàng

Bước 5: Triển khai RBAC trong hệ thống

Triển khai RBAC trong hệ thống hoặc ứng dụng của bạn bằng cách sử dụng các vai trò, quyền hạn, và gán vai trò người dùng đã được xác định trước đó. Điều này thường bao gồm việc cấu hình các kiểm soát truy cập, chẳng hạn như cơ chế xác thực và ủy quyền người dùng, dựa trên mô hình RBAC.

Bước 6: Đánh giá và cập nhật thường xuyên

RBAC không phải là một thiết lập một lần duy nhất. Nó yêu cầu bảo trì liên tục để đảm bảo rằng các vai trò, quyền hạn và gán vai trò người dùng luôn được cập nhật và phù hợp với yêu cầu của tổ chức. Thường xuyên đánh giá và cập nhật các cấu hình RBAC khi cần thiết.

Bước 7: Kiểm tra và giám sát

Triển khai các cơ chế kiểm tra và giám sát để theo dõi quyền truy cập và các hoạt động của người dùng trong hệ thống. Điều này giúp phát hiện bất kỳ nỗ lực truy cập trái phép hoặc các hoạt động đáng ngờ và đảm bảo tuân thủ các chính sách bảo mật và quy định.

Bước 8: Thực thi nguyên tắc quyền tối thiểu

Tuân theo nguyên tắc quyền tối thiểu, nghĩa là chỉ cấp cho người dùng mức độ truy cập tối thiểu cần thiết để thực hiện các chức năng công việc của họ. Điều này giúp giảm thiểu tác động tiềm tàng của các vi phạm bảo mật hoặc mối đe dọa từ bên trong.

Bước 9: Cung cấp công cụ quản trị

Cung cấp các công cụ hoặc giao diện quản trị để quản lý vai trò, quyền hạn và gán vai trò người dùng. Điều này cho phép các quản trị viên dễ dàng thêm, sửa đổi hoặc thu hồi quyền truy cập khi cần thiết.

Phương pháp kiểm soát quyền truy cập vào tài nguyên bằng Azure RBAC là gán các vai trò Azure. Đây là một khái niệm quan trọng để hiểu cách quyền hạn được thực thi. Một gán vai trò bao gồm ba thành phần: đối tượng bảo mật, định nghĩa vai trò, và phạm vi.

• Đối tượng bảo mật: Là một đối tượng đại diện cho người dùng, nhóm, dịch vụ chính, hoặc danh tính quản lý yêu cầu quyền truy cập vào tài nguyên Azure. Bạn có thể gán một vai trò cho bất kỳ đối tượng bảo mật nào.
• Định nghĩa vai trò: Là một tập hợp các quyền hạn. Nó thường được gọi đơn giản là vai trò. Định nghĩa vai trò liệt kê các hành động có thể được thực hiện, chẳng hạn như đọc, viết, và xóa. Các vai trò có thể là cấp cao, chẳng hạn như chủ sở hữu, hoặc cụ thể, chẳng hạn như người đọc máy ảo.
• Phạm vi: Là tập hợp các tài nguyên mà quyền truy cập áp dụng. Khi bạn gán một vai trò, bạn có thể giới hạn thêm các hành động được phép bằng cách xác định một phạm vi. Điều này hữu ích nếu bạn muốn làm ai đó trở thành Người đóng góp trang web, nhưng chỉ cho một nhóm tài nguyên cụ thể.
• Gán vai trò: Là quá trình gắn một định nghĩa vai trò vào một người dùng, nhóm, dịch vụ chính, hoặc danh tính quản lý ở một phạm vi cụ thể nhằm mục đích cấp quyền truy cập. Quyền truy cập được cấp bằng cách tạo một gán vai trò, và quyền truy cập được thu hồi bằng cách xóa một gán vai trò.

Chiến lược phiên bản

Chiến lược phiên bản là rất quan trọng trong thiết kế và bảo trì API, vì chúng xác định cách các thay đổi và cập nhật được quản lý trong khi đảm bảo tương thích ngược và trải nghiệm người dùng tích cực.

URI Versioning

Mô tả: Trong chiến lược này, phiên bản được bao gồm như một phần của đường dẫn URI. Ví dụ: https://api.example.com/v1/resource Tác động:

• Ưu điểm: Phiên bản rõ ràng và tường minh, dễ triển khai, cho phép nhiều phiên bản cùng tồn tại.
• Nhược điểm: Có thể làm rối URI, dẫn đến các URL dài hơn và khó đọc hơn. Yêu cầu khách hàng cập nhật URL khi chuyển đổi phiên bản.

Query Parameter Versioning

Mô tả: Phiên bản được chỉ định như một tham số truy vấn trong URL. Ví dụ: https://api.example.com/resource?version=v1 Tác động:

• Ưu điểm: Giữ cho URI gốc sạch sẽ, và cho phép dễ dàng chuyển đổi phiên bản mà không cần thay đổi URL gốc.
• Nhược điểm: Có thể không rõ ràng như phiên bản URI. Các cơ chế caching có thể không phân biệt được giữa các phiên bản khác nhau.

Header Versioning

Mô tả: Thông tin phiên bản được bao gồm trong header của yêu cầu. Ví dụ:

GET /resource HTTP/1.1
Host: api.example.com
Accept: application/json
X-API-Version: v1

Tác động:

• Ưu điểm: Giữ cho URI sạch sẽ, cung cấp một cách quản lý thông tin phiên bản tập trung.
• Nhược điểm: Yêu cầu khách hàng phải rõ ràng chỉ định phiên bản trong header yêu cầu, điều này có thể ít trực quan hơn.

Media Type Versioning

Mô tả: Các phiên bản khác nhau của API được đại diện bằng các loại media khác nhau. Ví dụ: Accept: application/vnd.example.v1+json Tác động:

• Ưu điểm: Cho phép khách hàng yêu cầu các phiên bản API cụ thể bằng cách sử dụng đàm phán nội dung, và giữ cho URIs sạch sẽ.
• Nhược điểm: Yêu cầu khách hàng hiểu và chỉ định chính xác các loại media, và có thể ít trực quan hơn cho các nhà phát triển.

Semantic Versioning

Mô tả: Các phiên bản được biểu diễn bằng định dạng ba phần MAJOR.MINOR.PATCH. Ví dụ: 1.0.0 Tác động:

• Ưu điểm: Cung cấp hướng dẫn rõ ràng cho việc tăng phiên bản dựa trên bản chất của các thay đổi (lớn, nhỏ và sửa lỗi).
• Nhược điểm: Không tự bản thân chỉ rõ cách thông tin phiên bản nên được truyền trong các yêu cầu, và nên được kết hợp với các chiến lược phiên bản khác.

Date Versioning

Mô tả: Các phiên bản được biểu diễn bằng ngày phát hành. Ví dụ: 2024-01-01 Tác động:

• Ưu điểm: Cung cấp cách theo dõi các thay đổi API theo trình tự thời gian, và dễ hiểu.
• Nhược điểm: Có thể không chỉ ra bản chất của các thay đổi trong một phiên bản (ví dụ, thay đổi gây phá vỡ so với các cập nhật nhỏ).

Tác động đến Bảo trì API và Trải nghiệm Người dùng:

• Bảo trì: Các chiến lược phiên bản khác nhau có các tác động khác nhau đối với bảo trì API. Phiên bản URI có thể yêu cầu nhiều nỗ lực hơn để quản lý khi các API phát triển. Trong khi đó, phiên bản header hoặc media type có thể cung cấp nhiều sự linh hoạt hơn trong việc giới thiệu các thay đổi mà không ảnh hưởng đến cấu trúc URI.
• Trải nghiệm Người dùng: Một chiến lược phiên bản rõ ràng góp phần vào trải nghiệm người dùng tích cực. Các chiến lược như phiên bản URI hoặc tham số truy vấn làm cho phiên bản trở nên rõ ràng nhưng có thể dẫn đến các URL dài hơn. Ngược lại, các chiến lược như phiên bản header hoặc media type giữ cho các URL sạch sẽ nhưng có thể yêu cầu người dùng hiểu và sử dụng chính xác các header yêu cầu hoặc các loại media. Phiên bản semant giúp người dùng hiểu được bản chất của các thay đổi nhưng yêu cầu chúng phải được kết hợp với các chiến lược phiên bản khác để triển khai.

Cuối cùng, chiến lược được chọn nên cân bằng giữa sự rõ ràng, tính linh hoạt, và dễ sử dụng cho người tiêu dùng API.

HATEOAS và vai trò của nó trong việc tạo APIs

Hypermedia as the Engine of Application State (HATEOAS) là một ràng buộc trong phong cách kiến trúc REST nhấn mạnh việc sử dụng các liên kết hypermedia để điều hướng API một cách động. Nói một cách đơn giản, HATEOAS cho phép khách hàng tương tác với một API bằng cách theo dõi các liên kết do máy chủ cung cấp, thay vì phải biết trước các điểm cuối API.

Cách hoạt động và vai trò của HATEOAS trong việc tạo API tự khám phá và động

Tự khám phá

Với HATEOAS, APIs được thiết kế để tự mô tả. Mỗi phản hồi từ máy chủ bao gồm các liên kết hypermedia hướng dẫn khách hàng về các hành động tiếp theo mà họ có thể thực hiện. Khách hàng không cần phải dựa vào thông tin ngoài băng (chẳng hạn như tài liệu API) để hiểu cách tương tác với API. Thay vào đó, họ có thể khám phá động các tài nguyên và hành động có sẵn bằng cách theo dõi các liên kết được nhúng trong phản hồi API.

Tương tác Động

HATEOAS cho phép tương tác động với API. Khách hàng có thể điều hướng qua các tài nguyên khác nhau và thực hiện các hành động dựa trên các liên kết được cung cấp trong phản hồi API. Điều này cho phép tương tác giữa máy khách và máy chủ linh hoạt và thích ứng hơn, vì khách hàng có thể phản hồi các thay đổi trong cấu trúc hoặc hành vi của API mà không cần thay đổi mã.

Giảm Sự Phụ Thuộc

HATEOAS thúc đẩy sự tách rời giữa máy khách và máy chủ. Khách hàng tương tác với API dựa trên các liên kết do máy chủ cung cấp, thay vì mã hóa cứng các điểm cuối cụ thể hoặc giả định một cấu trúc API cố định. Điều này làm cho API chịu được các thay đổi tốt hơn, cho phép sự phát triển và phiên bản hóa dễ dàng hơn, vì máy chủ có thể thay đổi URL tài nguyên hoặc giới thiệu chức năng mới mà không làm hỏng các khách hàng hiện có.

Cải Thiện Khả Năng Sử Dụng API

Bằng cách cung cấp các liên kết hypermedia trong các phản hồi API, HATEOAS nâng cao khả năng sử dụng của APIs. Khách hàng có thể điều hướng qua các tài nguyên khác nhau và thực hiện các hành động một cách trực quan và dễ hiểu. Điều này có thể đơn giản hóa việc phát triển và tích hợp của khách hàng, cũng như cải thiện trải nghiệm người dùng tổng thể khi tương tác với API.

Tăng Cường Tính Linh Hoạt

HATEOAS cho phép API tiến hóa theo thời gian mà không làm gián đoạn các triển khai của khách hàng. Máy chủ có thể thêm, gỡ bỏ hoặc thay đổi các tài nguyên và hành động, và khách hàng có thể thích nghi với các thay đổi này một cách động bằng cách theo dõi các liên kết được cung cấp trong phản hồi API. Tính linh hoạt này hỗ trợ các thực hành phát triển linh hoạt và hỗ trợ sự phát triển của các hệ thống phân tán phức tạp.