2016-08-18 22 views
6

sự khác biệt giữa X-Auth-Token: dadas123sad12 vs Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ == tiêu đề. Được ưu tiênSự khác biệt giữa tiêu đề X-Auth-Token vs Authorization.Which được ưu tiên là

+0

Xin chào Deepak và chào mừng bạn đến với Stack Overflow. Đó là một câu hỏi khá rộng - bạn có thể giải thích những gì bạn biết về hai tiêu đề ủy quyền khác nhau đã có không và cách thức/tại sao bạn cần phải lựa chọn giữa chúng? –

+0

Tôi chỉ muốn biết sự khác biệt giữa hai. Để đính kèm nó với mã thông báo JWT từ phần còn lại của dịch vụ đầy đủ. Vì vậy, bối rối để sử dụng loại tiêu đề. @VinceBowdren – Deepak

+0

Về cơ bản, Ủy quyền: Cơ bản được sử dụng để đăng nhập và sau đó bạn trả về một mã thông báo được tạo, được trả về các yêu cầu tiếp theo để chứng minh bạn là ai. –

Trả lời

1

'Ủy quyền: Cơ bản' nghĩa là xác thực cơ bản, trình duyệt/khách hàng phải cung cấp tên người dùng/mật khẩu với mỗi yêu cầu.

Trong trường hợp người dùng 'x-auth-token' phải cung cấp tên người dùng/mật khẩu lần đầu tiên và máy chủ trả về mã thông báo truy cập trong trường tiêu đề 'x-auth-token'. Đối với các phiên tiếp theo, mã thông báo này được trao đổi, không phải tên người dùng/mật khẩu.

+0

"n trường hợp của 'x-auth-token' ..." Làm thế nào bạn có thể biết điều đó? Đó là một chương trình xác thực không chuẩn bên ngoài [khung công tác chính thức] (https://tools.ietf.org/html/rfc7235). – DaSourcerer

+0

@DaSourcerer Nó được một lúc tôi nhìn vào vấn đề này, nhưng đã xác minh việc thực hiện trong khung Spring (cho cả hai xác thực cơ bản và x-auth-token) và nó là chính xác. – user18853

+0

Ah, tệ lắm. Tôi đã không nhận ra câu hỏi này đã được cụ thể cho mùa xuân; Tôi chỉ đơn giản là giả định trường hợp chung. – DaSourcerer

9

Authorization là tiêu đề chính được khách hàng sử dụng để xác thực với các đồng nghiệp trong HTTP như dự kiến ​​trong RFC 7235. Nó thường được liên kết với sơ đồ xác thực Basic theo RFC 7617, nhưng đó không phải là một giao thức nhất định.

Đề án Basic cho phép khách hàng cung cấp cặp tên người dùng-mật khẩu được phân tách bằng dấu hai chấm (:) được mã hóa trong Base64. Không thể nhấn mạnh rằng đây là mã hóa vận chuyển không cung cấp các lợi ích bảo mật thực sự. Ví dụ. ví dụ được bạn đưa ra có thể tầm thường được 'giải mã' thành Aladdin:open sesame.

Thông qua IANA HTTP Authentication Scheme Registry (xem thêm: RFC 7235, sec. 5.1), bạn sẽ tìm thấy sơ đồ Bearer (được xác định trong RFC 6750), được liên kết chặt chẽ với OAuth 2.0. X-Auth-Token là khá nhiều cung cấp một phím tắt ở đây vì nó (có lẽ) không dựa vào OAuth hoặc khung xác thực HTTP.

Xin lưu ý rằng với X-Auth-Tokenunregistered header, không phụ thuộc vào đặc điểm chính thức và sự hiện diện và nội dung của nó luôn gắn với một ứng dụng tương ứng. Không có giả định chung nào có thể được đưa ra.

Các vấn đề liên quan