Twitter API'sini kullanırken, temel olarak karma (istek gövdesi + istek parametreleri + nonces/timestamps + a consumer_secret) karmaşası olan oauth_signature ile karşılaştım. consumer_secret sadece isteği gönderen uygulama tarafından bilinir. Twitter'ın durumdaSSL tekerleğini yeniden icat etmiyor mu?
:
- tüm iletişim SSL üzerinden gerçekleşmesi GEREKİR.
- twitter, her yetkili uygulamaya
consumer_secretnumaralı sorunu bildirir.oauth_signaturebirincil kullanımı (yani hiçbir memeler (transit kurcalama) :) MITMs önlemek olduğundan
, belirli bir kullanım durumu Karşılıklı SSL aracılığıyla çözülebilir geliyor bana
- Twitter,
consumer_secret'u vermek yerine, her uygulama için SSL sertifikaları verebilir.
İstemci ssl-sertifikalarının bu fikri 1990'ların Internet arcana'sı gibi görünebilirken, büyük ölçüde istemci sertifikaları için güven zincirinin doğrulanmasındaki sorun nedeniyle başarılı olmadı. Bu sorun burada ortaya çıkmaz çünkü twitter, sertifikaların tek ihraçcısı VE doğrulayıcısı olur. Bunun dezavantajı, ilk başvuru/müşteri ssl sertifikalarını üretmek adına Twitter adına çok daha fazla çaba sarfedecektir, ancak ödeme, müşterinin söylediği kişi olduğu garantisine dayanan REST API'sinin basitliğinde olacaktır.
Bu durumda twitter'in sadece bir örnek olduğunu unutmayın. AFAIK, diğer birçok oauth uygulayıcısı da benzer bir strateji kullanır ve buradaki noktalar zaten SSL'yi yöneten büyük ölçekli bir OAuth uygulayıcısı için geçerlidir.
Burada nelerin eksik? İnternet Ataleti?
Sorunu kaçırıyorsunuz. Karşılıklı SSL-sertifikalarının OAuth'un çözdüğü problemi çözeceğini söylemiyorum. “Oauth_signature” mekanizmasının temel olarak karşılıklı SSL-certs'lerinin sağladığı iki yönlü kimlik doğrulamasını yeniden icat ettiğini söylüyorum. – Manav
Ancak, karşılıklı SSL Sertifikaları yalnızca sorunun yarısını (uygulama belirteci tarafı) çözüyor ve tüketici belirteci tarafı için hiçbir şey yapmıyor. Ve eğer OAuth 2.0'a bakarsanız, o yönde hareket ettiler. –