Tôi nên sử dụng mã HTTP nào cho lỗi xác thực của bên thứ ba?

Tôi đang tạo một ứng dụng tích hợp với các ứng dụng của bên thứ ba.

Để thực hiện việc này, người dùng đã đăng nhập sẽ gửi khóa API để tích hợp bên thứ ba.

Trong trường hợp khóa API mà họ đã gửi không hợp lệ - (và trả về 401 từ bên thứ ba), tôi nên trả lại phản hồi HTTP nào?

Trả lại một 401 từ ứng dụng của tôi nghe có vẻ khó hiểu bởi vì theo quan điểm của frontend, không rõ liệu chúng không được xác thực bởi ứng dụng của tôi hay ứng dụng của bên thứ ba.

Tôi mong muốn chỉ cung cấp cho nó 400 - như thể họ đã gửi một biểu mẫu có địa chỉ email không hợp lệ, v.v.

Nếu tôi phải chọn một mã, có lẽ tôi sẽ chọn trả về 403 Bị cấm.

RFC 7231 §6.5.3 mô tả mã 403 như sau:

Mã trạng thái 403 (Bị cấm) chỉ ra rằng máy chủ hiểu yêu cầu nhưng từ chối ủy quyền. Một máy chủ muốn công khai lý do tại sao yêu cầu bị cấm có thể mô tả lý do đó trong tải trọng phản hồi (nếu có).

Nếu thông tin xác thực được cung cấp trong yêu cầu, máy chủ cho rằng chúng không đủ để cấp quyền truy cập. Khách hàng KHÔNG NÊN tự động lặp lại yêu cầu với cùng thông tin đăng nhập. Khách hàng CÓ THỂ lặp lại yêu cầu với thông tin mới hoặc khác. Tuy nhiên, một yêu cầu có thể bị cấm vì những lý do không liên quan đến thông tin đăng nhập.

Thay vào đó, một máy chủ gốc muốn "ẩn" sự tồn tại của tài nguyên đích bị cấm CÓ THỂ trả lời bằng mã trạng thái 404 (Không tìm thấy).

Mã trạng thái này thường được sử dụng làm phản hồi 'xác thực thất bại' chung chung và không có khả năng kích hoạt bất kỳ cơ chế xác thực cụ thể nào, như 401 có thể buộc trình duyệt hiển thị lời nhắc tên người dùng / mật khẩu. Lý do cụ thể tại sao xác thực thất bại có thể được mô tả trong phần phản hồi, ở dạng có thể đọc được bằng máy (ví dụ JSON hoặc XML) hoặc dưới dạng tài liệu có thể đọc được của con người (ví dụ HTML).

Mã 400 không phải là lựa chọn tồi tệ nhất có thể ở đây, nhưng nó khá chung chung.

Bạn có thể sử dụng mã trạng thái Mã trạng thái HTTP - 407 (Yêu cầu xác thực proxy). Từ tài liệu tham khảo dành cho nhà phát triển Mozilla :

Mã xác thực trạng thái lỗi máy khách HTTP 407 Yêu cầu mã phản hồi trạng thái lỗi máy khách yêu cầu cho biết rằng yêu cầu chưa được áp dụng vì nó thiếu thông tin xác thực hợp lệ cho máy chủ proxy nằm giữa trình duyệt và máy chủ có thể truy cập tài nguyên được yêu cầu.

Ứng dụng phụ trợ của bạn hoạt động như một proxy cho API của bên thứ 3, vì vậy có thể sử dụng 407 trong trường hợp này.

407không đúng Trong trường hợp này, mã của bạn là proxy và nó được xác thực. Đó là một hệ thống nước ngoài không được xác thực.

401là hợp lý nhưng nó gây hiểu lầm về những gì không được xác thực do máy khách được xác thực với hệ thống của bạn. Điều này cũng không hoạt động nếu xác thực nước ngoài của bạn bị hoãn lại cho đến sau 100Continue.

400 không đúng vì yêu cầu có giá trị ở định dạng nhưng auth không thành công tại đại lý nước ngoài.

Tất cả các 4xxphản ứng khác dễ dàng bị loại bỏ vì không áp dụng ở đây.

Vì vậy, điều đó khiến 403Tử Cấm mà theo tôi là lựa chọn thực sự duy nhất của bạn trong trường hợp này:

403Cấm Khách hàng không có quyền truy cập vào nội dung; đó là trái phép, vì vậy máy chủ từ chối cung cấp tài nguyên được yêu cầu. Không giống như 401, danh tính của máy khách được biết đến máy chủ. Trả lời cũng với một thông báo trạng thái cho biết "nguyên nhân gốc" của sự thất bại cũng có thể phù hợp trong trường hợp này. Nó thực sự phụ thuộc vào bố trí bảo mật của ứng dụng của bạn.

$ 0,02 của tôi

Tôi sẽ đi với 400, nó đáp ứng yêu cầu ngữ nghĩa. Người dùng cung cấp một số dữ liệu xấu. Như bạn nói, 401/ 403 có nghĩa là một vấn đề giữa người dùng và trang web của bạn, không phải trang web của bạn và một số ứng dụng khác.

Phần 1 của các trạng thái HTTP 1.1 RFC :

Giới thiệu

Mỗi thông báo Giao thức truyền siêu văn bản (HTTP) là một yêu cầu hoặc phản hồi. Một máy chủ lắng nghe kết nối cho một yêu cầu, phân tích từng tin nhắn nhận được, diễn giải ngữ nghĩa của tin nhắn liên quan đến mục tiêu yêu cầu đã xác định và trả lời yêu cầu đó bằng một hoặc nhiều tin nhắn phản hồi. Một khách hàng xây dựng các thông điệp yêu cầu để truyền đạt ý định cụ thể, kiểm tra các phản hồi nhận được để xem liệu ý định đó có được thực hiện hay không và xác định cách diễn giải kết quả. Tài liệu này xác định ngữ nghĩa yêu cầu và đáp ứng HTTP / 1.1 theo kiến ​​trúc được xác định trong [RFC7230].

Xóa định nghĩa về mã trạng thái là giữa máy khách và máy chủ. Đối với tôi điều đó có nghĩa là chọn một ý nghĩa tốt nhất cho các tương tác khác (máy chủ đến máy chủ, phụ trợ, v.v.).

Tất cả các ngoại lệ khác được cung cấp ở đây sẽ chỉ gây nhầm lẫn cho người tiêu dùng dịch vụ.

Nó luôn luôn tốt để gửi 403

nhưng nếu cần bạn có thể thêm thông tin json-

[Serializable]
[DataContract]
class Response
{
    [DataMember]
    public bool IsSuccess { get; set; }
    [DataMember]
    public string Message { get; set; }
    [DataMember]
    public object ResponseData { get; set; }

    public Response(bool status, string message, object data)
    {
        IsSuccess = status;
        Message = message;
        ResponseData = data;
    }
}

Và sau đó trong phản hồi thêm thông tin sau đây

 return Json(new Response(false, "Login Failed, The user name or password provided is incorrect.", null));

khi yêu cầu được thực hiện, bạn có thể tắt nút đăng nhập - và chỉ khi thực hiện cập nhật, nút mới có thể được bật - logic phía máy khách.

Các 424 - Failed Dependencybộ đồ khá tốt trong trường hợp này.

Mã trạng thái 424 (Không phụ thuộc) có nghĩa là phương thức không thể được thực hiện trên tài nguyên vì hành động được yêu cầu phụ thuộc vào hành động khác và hành động đó đã thất bại.

Tôi sẽ nghiêng về phía 407. 407 Yêu cầu xác thực proxy Mã này tương tự như 401 (Không được phép), nhưng chỉ ra rằng máy khách trước tiên phải tự xác thực bằng proxy. Proxy PHẢI trả về trường tiêu đề Xác thực proxy (phần 14.33) có chứa một thách thức áp dụng cho proxy cho tài nguyên được yêu cầu. Máy khách CÓ THỂ lặp lại yêu cầu với trường tiêu đề Ủy quyền ủy quyền phù hợp (phần 14.34). Xác thực truy cập HTTP được giải thích trong "Xác thực HTTP: Xác thực truy cập cơ bản và tiêu hóa". như Iskander đã đề cập.

Nó gợi ý tốt nhất cho người dùng về vấn đề có thể xảy ra. Ngoài ra, bạn có thể chuyển tiếp và triển khai tiêu đề ủy quyền proxy để hoàn toàn phù hợp với thông số kỹ thuật.

Sử dụng 400 sẽ khiến khách hàng của bạn gãi đầu tìm kiếm những gì anh ta đang làm sai khi xây dựng yêu cầu.

Sử dụng 401 hoặc 403 có ý nghĩa hơn để giữ chúng cho xác thực và ủy quyền API của riêng bạn.

502 gợi ý cho người dùng rằng vấn đề là ngược dòng, do đó anh ta có thể bị treo cho đến khi bạn khắc phục nó.

Tôi sẽ đứng với 401. Lỗi trái phép 401 là mã trạng thái HTTP, có nghĩa là trang mà người dùng đang cố truy cập không thể được tải cho đến khi người dùng đăng nhập lần đầu bằng ID và mật khẩu người dùng hợp lệ. Nếu người dùng vừa đăng nhập và nhận được lỗi Không được phép 401, điều đó có nghĩa là thông tin đăng nhập mà người dùng đã nhập không hợp lệ vì một số lý do. Trong trường hợp của chúng tôi, khóa API họ đã gửi không hợp lệ. Có một sơ đồ hoạt động mà tôi đã sử dụng khi tôi nhầm lẫn với các mã lỗi.

Dưới đây là liên kết cho cùng:

https://i.stack.imgur.com/ppsbq.jpg

Trong trường hợp này, máy chủ trung gian đã được đăng nhập thành công và máy chủ ngược dòng từ chối thực hiện xác thực nhờ khóa không hợp lệ. Có vẻ như mã 502 (Bad Gateway) phù hợp với tình huống này, vì mã này là viết tắt của một máy chủ hoạt động như một cổng (Yours) và đang nhận được phản hồi không hợp lệ từ máy chủ ngược dòng (bên thứ ba).