Làm thế nào để xử lý xác thực trong kiến trúc RESTful Client-Server là một vấn đề tranh luận.
Thông thường, nó có thể đạt được, trong thế giới SOA qua HTTP thông qua:
- Xác thực cơ bản HTTP qua HTTPS;
- Quản lý cookie và phiên;
- Mã thông báo trong các tiêu đề HTTP (ví dụ: OAuth 2.0 + JWT);
- Xác thực truy vấn với các tham số chữ ký bổ sung.
Bạn sẽ phải điều chỉnh, hoặc thậm chí kết hợp tốt hơn các kỹ thuật đó, để phù hợp nhất với kiến trúc phần mềm của bạn.
Mỗi sơ đồ xác thực có các PRO và CON riêng, tùy thuộc vào mục đích của chính sách bảo mật và kiến trúc phần mềm của bạn.
Xác thực cơ bản HTTP qua HTTPS
Giải pháp đầu tiên này, dựa trên giao thức HTTPS tiêu chuẩn, được hầu hết các dịch vụ web sử dụng.
GET /spec.html HTTP/1.1
Host: www.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Thật dễ dàng để thực hiện, có sẵn theo mặc định trên tất cả các trình duyệt, nhưng có một số nhược điểm đã biết, như cửa sổ xác thực khủng khiếp được hiển thị trên Trình duyệt, sẽ vẫn tồn tại (không có tính năng giống LogOut ở đây), một số mức tiêu thụ CPU bổ sung phía máy chủ, và thực tế là tên người dùng và mật khẩu được truyền (qua HTTPS) vào Máy chủ (sẽ an toàn hơn khi chỉ để mật khẩu ở phía máy khách, trong khi nhập bàn phím và được lưu dưới dạng băm an toàn trên Máy chủ) .
Chúng tôi có thể sử dụng Xác thực Digest , nhưng nó cũng yêu cầu HTTPS, vì nó dễ bị tấn công MiM hoặc Phát lại , và đặc trưng cho HTTP.
Phiên thông qua Cookies
Thành thật mà nói, một phiên được quản lý trên Máy chủ không thực sự không trạng thái.
Một khả năng có thể là duy trì tất cả dữ liệu trong nội dung cookie. Và, theo thiết kế, cookie được xử lý ở phía Máy chủ (Trên thực tế, Máy khách thậm chí không cố gắng diễn giải dữ liệu cookie này: nó chỉ đưa nó trở lại máy chủ theo từng yêu cầu liên tiếp). Nhưng dữ liệu cookie này là dữ liệu trạng thái ứng dụng, vì vậy khách hàng nên quản lý nó, chứ không phải máy chủ, trong một thế giới Không quốc tịch thuần túy.
GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123
Bản thân kỹ thuật cookie được liên kết với HTTP, vì vậy nó không thực sự RESTful, nên độc lập với giao thức, IMHO. Nó dễ bị tấn công MiM hoặc Phát lại .
Cấp qua mã thông báo (OAuth2)
Một cách khác là đặt mã thông báo trong các tiêu đề HTTP để yêu cầu được xác thực. Đây là những gì OAuth 2.0 làm, ví dụ. Xem RFC 6749 :
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer mF_9.B5f-4.1JqM
Nói tóm lại, điều này rất giống với cookie và chịu cùng một vấn đề: không trạng thái, dựa vào chi tiết truyền HTTP và chịu nhiều điểm yếu về bảo mật - bao gồm MiM và Phát lại - vì vậy chỉ được sử dụng trên HTTPS. Thông thường, JWT được sử dụng làm mã thông báo.
Xác thực truy vấn
Xác thực truy vấn bao gồm việc ký từng yêu cầu RESTful thông qua một số tham số bổ sung trên URI. Xem bài viết tham khảo này .
Nó được định nghĩa như vậy trong bài viết này:
Tất cả các truy vấn REST phải được xác thực bằng cách ký các tham số truy vấn được sắp xếp theo thứ tự chữ thường, chữ thường bằng cách sử dụng thông tin xác thực làm mã thông báo ký. Việc ký kết phải xảy ra trước khi URL mã hóa chuỗi truy vấn.
Kỹ thuật này có lẽ tương thích hơn với kiến trúc Statless và cũng có thể được thực hiện với quản lý phiên nhẹ (sử dụng các phiên trong bộ nhớ thay vì kiên trì DB).
Chẳng hạn, đây là một mẫu URI chung từ liên kết trên:
GET /object?apiKey=Qwerty2010
nên được truyền đi như vậy:
GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789
Chuỗi được ký là /object?apikey=Qwerty2010×tamp=1261496500và chữ ký là hàm băm SHA256 của chuỗi đó bằng cách sử dụng thành phần riêng của khóa API.
Bộ nhớ đệm dữ liệu phía máy chủ có thể luôn luôn có sẵn. Chẳng hạn, trong khung của chúng tôi, chúng tôi lưu trữ các phản hồi ở cấp SQL, không phải ở cấp URI. Vì vậy, việc thêm tham số bổ sung này không phá vỡ cơ chế bộ đệm.
Xem bài viết này để biết một số chi tiết về xác thực RESTful trong khung ORM / SOA / MVC của máy chủ-máy chủ của chúng tôi, dựa trên JSON và REST. Vì chúng tôi cho phép giao tiếp không chỉ qua HTTP / 1.1 mà còn được đặt tên là đường ống hoặc tin nhắn GDI (cục bộ), chúng tôi đã cố gắng thực hiện một mẫu xác thực RESTful thực sự và không dựa vào tính đặc hiệu của HTTP (như tiêu đề hoặc cookie).
Lưu ý sau : thêm chữ ký trong URI có thể được coi là thông lệ xấu (ví dụ: nó sẽ xuất hiện trong nhật ký máy chủ http) vì vậy nó phải được giảm nhẹ, ví dụ như bằng một TTL thích hợp để tránh phát lại. Nhưng nếu nhật ký http của bạn bị xâm phạm, bạn chắc chắn sẽ gặp vấn đề bảo mật lớn hơn.
Trong thực tế, Xác thực mã thông báo MAC sắp tới cho OAuth 2.0 có thể là một cải tiến lớn đối với chương trình hiện tại "Được cấp bởi mã thông báo". Nhưng đây vẫn là một công việc đang tiến triển và gắn liền với truyền HTTP.
Phần kết luận
Thật đáng để kết luận rằng REST không chỉ dựa trên HTTP, ngay cả trong thực tế, nó cũng được triển khai chủ yếu qua HTTP. REST có thể sử dụng các lớp giao tiếp khác. Vì vậy, xác thực RESTful không chỉ là từ đồng nghĩa của xác thực HTTP, bất kể câu trả lời nào của Google. Nó thậm chí không nên sử dụng cơ chế HTTP mà phải được trừu tượng hóa từ lớp giao tiếp. Và nếu bạn sử dụng giao tiếp HTTP, nhờ vào sáng kiến Let Encrypt , không có lý do gì để không sử dụng HTTPS phù hợp, được yêu cầu ngoài bất kỳ sơ đồ xác thực nào.