Tôi hiện đang làm việc trên thư viện REST cho .net và tôi muốn nghe một số ý kiến về điểm mở mà tôi có: REST và xác thực.Biến thể REST và xác thực
Dưới đây là một ví dụ về một giao diện RESTful sử dụng với thư viện:
[RestRoot("/user")]
public interface IUserInterface
{
[RestPut("/")]
void Add(User user);
[RestGet("/")]
int[] List();
[RestGet("/get/{id}")]
User Get(int id);
[RestDelete("/delete/{id}")]
void Delete(int id);
}
Mã máy chủ sau đó chỉ cần thực hiện giao diện và các khách hàng có thể có được cùng một giao diện thông qua một nhà máy. Hoặc nếu khách hàng không sử dụng thư viện, yêu cầu HTTP tiêu chuẩn cũng hoạt động.
Tôi biết rằng có nhiều cách chính để sử dụng Xác thực cơ bản HTTP hoặc gửi mã thông báo cho các yêu cầu yêu cầu người dùng được xác thực.
Phương pháp đầu tiên (HTTP Basic Auth), có các vấn đề sau (một phần trình duyệt web cụ thể):
- Mật khẩu được truyền đi với mọi yêu cầu - ngay cả với SSL này có một số loại "linh cảm xấu" .
- Vì mật khẩu được truyền đi với tiêu đề yêu cầu, sẽ dễ dàng cho kẻ tấn công địa phương xem xét các tiêu đề được truyền để nhận mật khẩu.
- Mật khẩu có sẵn trong bộ nhớ trình duyệt.
- Không có cách tiêu chuẩn để hết hạn "phiên" của người dùng.
- Đăng nhập bằng trình duyệt sẽ làm gián đoạn giao diện của trang.
Những vấn đề đối với phương pháp thứ hai là tập trung hơn vào việc thực hiện và thư viện sử dụng:
- Mỗi yêu cầu URI mà cần chứng thực phải có một tham số cho được dấu hiệu, mà chỉ là rất lặp đi lặp lại.
- Có nhiều mã hơn để viết nếu mỗi phương thức triển khai cần kiểm tra xem mã thông báo có hợp lệ hay không.
- Giao diện sẽ trở nên ít cụ thể hơn, ví dụ:
[RestGet("/get/{id}")]và[RestGet("/get/{id}/{token}")]. - Nơi đặt mã thông báo: ở cuối URI? sau gốc? ở đâu khác?
Ý tưởng của tôi là để vượt qua các dấu hiệu như tham số vào URL như http:/server/user/get/1234?token=token_id.
Một khả năng khác là gửi tham số dưới dạng tiêu đề HTTP, nhưng điều này sẽ làm phức tạp việc sử dụng với các máy khách HTTP thuần túy mà tôi đoán.
Mã thông báo sẽ được chuyển lại cho khách hàng dưới dạng tiêu đề HTTP tùy chỉnh ("X-Session-Id") trên mỗi yêu cầu.
Điều này sau đó có thể được tóm tắt hoàn toàn từ giao diện và mọi xác thực cần thực hiện chỉ có thể hỏi người dùng mã thông báo (nếu được) thuộc về.
Bạn có nghĩ điều này sẽ vi phạm REST quá nhiều hoặc bạn có ý tưởng nào tốt hơn không?
Cảm ơn bạn đã liên kết S3. – Fionn
Trong ví dụ S3, chúng chia sẻ khóa mã hóa với các máy khách - điều này là xấu, phải không? –
Giống như bất kỳ loại mật mã bí mật được chia sẻ nào, điều quan trọng là cả hai bên duy trì bí mật của khóa. Về vấn đề đó, không còn tệ hơn là mật mã đối xứng. – laz