Không phải là oauth_signature phát minh lại bánh xe SSL?

Question

Trong khi sử dụng API twitter, tôi đã xem qua số oauth_signature về cơ bản là một băm (yêu cầu body + yêu cầu tham số + nonces/dấu thời gian + một consumer_secret). consumer_secret chỉ được biết đến với ứng dụng đang gửi yêu cầu.

Trong trường hợp của Twitter:

• tất cả các thông tin liên lạc PHẢI xảy ra qua SSL.
• twitter phát hành consumer_secret cho từng ứng dụng được ủy quyền.

Kể từ khi việc sử dụng chính của oauth_signature là để ngăn chặn MITMs (tức là không có ngực (giả mạo trên đường vận chuyển) :), có vẻ như với tôi rằng trường hợp sử dụng cụ này có thể được giải quyết thông qua SSL Mutual

• Twitter, thay vì phát hành consumer_secret, có thể phát hành chứng chỉ SSL cho từng ứng dụng.

Mặc dù ý tưởng này về chứng chỉ ssl của khách hàng có thể giống như arcana internet 1990, nó không thành công chủ yếu do sự cố trong việc xác minh chuỗi tin cậy cho chứng chỉ ứng dụng khách. Vấn đề đó không phát sinh ở đây vì twitter sẽ là tổ chức phát hành duy nhất VÀ người xác minh chứng chỉ. Mặt hạn chế sẽ có nhiều nỗ lực hơn trên Twitter để tạo ra các chứng chỉ ssl ứng dụng/khách hàng ban đầu, nhưng phần thưởng sẽ là sự đơn giản của API REST, có thể yên tâm về sự bảo đảm rằng khách hàng là người mà anh ta nói.

Lưu ý rằng twitter chỉ là một ví dụ trong trường hợp này. AFAIK, hầu hết các nhà triển khai oauth khác đều sử dụng một chiến lược tương tự và các điểm ở đây áp dụng cho bất kỳ người triển khai OAuth quy mô lớn nào đã ủy quyền SSL.

Tôi thiếu gì ở đây? Quán tính Internet?

Answer 1

Chứng chỉ SSL lẫn nhau, trong khi ý tưởng hay, không giải quyết chính xác vấn đề mà OAuth đang cố giải quyết. OAuth có hai bộ mã thông báo. Một cho ứng dụng (có thể được thay thế bằng các chứng chỉ SSL), nhưng cũng cho người dùng cụ thể. Chứng chỉ SSL không giúp bạn khi bạn đang cố gắng xác định xem ứng dụng được ủy quyền này có được phép truy cập vào người dùng cụ thể này hay không.