OAuth 2'nin OAuth 1'den farkı nedir?

Çok basit bir ifadeyle, birisi OAuth 2 ve OAuth 1 arasındaki farkı açıklayabilir mi?

OAuth 1 artık kullanılmıyor mu? OAuth 2'yi uygulamalı mıyız? OAuth 2'nin pek çok uygulamasını görmüyorum; çoğu hala OAuth 1 kullanıyor, bu da OAuth 2'nin kullanıma hazır olduğundan şüphe ediyor. Bu mu?

Eran Hammer-Lahav, OAuth 2.0 tanıtımı makalesindeki farklılıkların çoğunu açıklamak için mükemmel bir iş çıkardı . Özetlemek gerekirse, temel farklar şunlardır:

Tarayıcı tabanlı olmayan uygulamalar için daha iyi destek sağlayan daha fazla OAuth Akışı. Bu, tarayıcı tabanlı olmayan istemci uygulamalarından OAuth'a karşı ana eleştiridir. Örneğin, OAuth 1.0'da, masaüstü uygulamaları veya cep telefonu uygulamaları kullanıcıyı tarayıcılarını istenen hizmete açmaya, hizmetle kimlik doğrulamasına ve jetonu hizmetten uygulamaya geri yönlendirmeye yönlendirmek zorunda kaldı. Buradaki ana eleştiri kullanıcı deneyimine aykırıdır. OAuth 2.0 ile artık bir uygulamanın kullanıcı için yetkilendirilmesi için yeni yollar var.

OAuth 2.0 artık istemci uygulamalarının şifreleme gerektirmiyor. Bu, HMAC karma jetonlarına ve istek dizelerine uygulama gerektirmeyen eski Twitter Kimlik Doğrulama API'sine geri dönüyor. OAuth 2.0 ile uygulama yalnızca HTTPS üzerinden verilen jetonu kullanarak istekte bulunabilir.

OAuth 2.0 imzaları çok daha az karmaşıktır. Artık özel ayrıştırma, sıralama veya kodlama yok.

OAuth 2.0 Erişim belirteçleri "kısa ömürlüdür". Genellikle, OAuth 1.0 Erişim belirteçleri bir yıl veya daha uzun süre saklanabilir (Twitter hiçbir zaman sona ermesine izin vermez). OAuth 2.0'da yenileme simgeleri fikri vardır. Bunların ne olduğundan tam olarak emin olmasam da, tahminim erişim simgelerinizin kısa ömürlü olabileceği (yani oturuma dayalı), yenileme simgelerinizin "yaşam süresi" olabileceğidir. Kullanıcının uygulamanızı yeniden yetkilendirmesi yerine yeni bir erişim belirteci edinmek için yenileme belirteci kullanırsınız.

Son olarak, OAuth 2.0'ın, OAuth isteklerini işlemekten sorumlu sunucu ile sunucu yetkilendirme kullanıcısı arasında temiz bir rol ayrımı olması amaçlanmıştır. Bununla ilgili daha fazla bilgi yukarıda belirtilen makalede detaylandırılmıştır.

Burada harika cevaplar görüyorum ama özlediğim bazı diyagramlardı ve Spring Framework ile çalışmak zorunda olduğumdan beri açıklamalarına rastladım .

Aşağıdaki diyagramları çok yararlı buluyorum. OAuth2 ve OAuth1 olan taraflar arasındaki iletişim farkını gösterirler.

OAuth 2

OAuth 1

Önceki açıklamaların hepsi aşırı detaylı ve karmaşık IMO'dur. Basitçe söylemek gerekirse, OAuth 2 güvenliği HTTPS protokolüne devreder. OAuth 1 bunu gerektirmedi ve sonuç olarak çeşitli saldırılarla başa çıkmak için alternatif yöntemler vardı. Bu yöntemler, uygulamanın karmaşık ve uygulanması zor olabilecek bazı güvenlik protokollerine katılmasını gerektiriyordu. Bu nedenle, güvenlik için HTTPS'ye güvenmek daha kolaydır, böylece uygulama geliştiricilerinin endişelenmesine gerek kalmaz.

Diğer sorularınıza gelince, cevap değişir. Bazı hizmetler HTTPS kullanımını gerektirmek istemez, OAuth 2'den önce geliştirilmiştir veya OAuth 2'yi kullanmalarını engelleyebilecek başka bir gereksinime sahiptir. Ayrıca, OAuth 2 protokolünün kendisi hakkında çok fazla tartışma olmuştur. Gördüğünüz gibi, Facebook, Google ve diğer birkaç tanesinin protokollerin biraz farklı sürümleri var. Bu yüzden bazı insanlar OAuth 1'e sadık kalıyor çünkü farklı platformlarda daha üniform. Son zamanlarda, OAuth 2 protokolü kesinleştirildi, ancak henüz benimsenmesinin nasıl olacağını görmedik.

Oauth 2 kullanımına karşı ciddi güvenlik argümanları olduğuna dikkat edin:

bir kasvetli makale

ve daha teknik olanı

Bunların Oauth 2 baş yazarından geldiğine dikkat edin.

Anahtar noktaları:

• Oauth 2, SSL üzerinde güvenlik sunmazken Oauth 1, aktarımdan bağımsızdır.

• bir anlamda SSL, sunucunun bağlantıyı doğrulamaması ve ortak istemci kitaplıklarının hataları görmezden gelmeyi kolaylaştırması açısından güvenli değildir.

  SSL / TLS ile ilgili sorun, istemcinin sertifikasını doğrulayamadığınızda bağlantının hala devam etmesidir. Bir hatayı göz ardı etmek her zaman başarıya yol açar, geliştiriciler tam da bunu yapar. Sunucunun sertifika doğrulamasını zorunlu kılma yolu yoktur ve mümkün olsa bile bir saldırgan kesinlikle yapmaz.

• OAuth 1.0'da yapmak çok daha zor olan tüm güvenliğinizi yağdan uzaklaştırabilirsiniz:

  İkinci yaygın potansiyel sorun yazım hatalarıdır. Bir karakteri ('https' içindeki 's') atlarken jetonun güvenliğini geçersiz kılar mı? Ya da isteği (geçerli ve doğrulanmış bir SSL / TLS bağlantısı üzerinden) yanlış hedefe göndermek (' http://gacebook.com ' deyin ?). Unutmayın, komut satırından OAuth taşıyıcı belirteçlerini kullanabilmek açıkça tanıtılan bir kullanım durumu taşıyıcı belirteçleri savunucularıdır.

OAuth 1.0 protokolünün ( RFC 5849 ) güvenliği, bir istemci uygulamasına yerleştirilmiş gizli bir anahtarın gizli tutulabileceği varsayımına dayanır. Ancak, varsayım saftır.

OAuth 2.0'da ( RFC 6749 ), böyle naif bir istemci uygulaması gizli istemci olarak adlandırılır . Öte yandan, gizli anahtarı gizli tutmanın zor olduğu bir ortamda bir müşteri uygulamasına genel istemci denir . Bkz. 2.1. Ayrıntılar için İstemci Türleri .

Bu anlamda, OAuth 1.0 yalnızca gizli istemciler için bir belirtimdir.

" OAuth 2.0 ve Cehenneme Giden Yol ", OAuth 2.0'ın daha az güvenli olduğunu söylüyor, ancak OAuth 1.0 istemcileri ile OAuth 2.0 gizli istemcileri arasında güvenlik düzeyinde pratik bir fark yok. OAuth 1.0 imzanın hesaplanmasını gerektirir, ancak istemci tarafındaki gizli bir anahtarın gizli tutulabileceğinden emin olduğu takdirde güvenliği artırmaz. İmza hesaplaması, herhangi bir pratik güvenlik geliştirmesi olmadan sadece hantal bir hesaplamadır. Bir TLS üzerinden sunucu ve sadece hediyelere bir OAuth 2.0 istemci bağlandığı o sadelik nazaran yani client_idve client_secrethantal hesaplama güvenlik açısından daha iyi olduğu söylenemez.

Buna ek olarak, RFC 5849 (OAuth 1.0) açık yönlendiriciler hakkında hiçbir şeyden bahsetmezken RFC 6749 (OAuth 2.0) bahsetmez . Yani, oauth_callbackOAuth 1.0'ın parametresi bir güvenlik deliği olabilir.

Bu nedenle, OAuth 1.0'ın OAuth 2.0'dan daha güvenli olduğunu düşünmüyorum.

OAuth 1.0 güvenliği imza hesaplamasına dayanır. İmza, gizli anahtarın HMAC-SHA1 ( RFC 5849, 3.4.2 ) için paylaşılan bir anahtar veya RSA-SHA1 ( RFC 5849, 3.4.3 ) için özel bir anahtar olduğu gizli bir anahtar kullanılarak hesaplanır . Gizli anahtarı bilen herkes imzayı hesaplayabilir. Eğer gizli anahtar tehlikeye düşerse, imza hesaplamasının karmaşıklığı ne kadar karmaşık olsa da anlamsızdır.

Bu, OAuth 1.0 güvenliğinin imza hesaplama karmaşıklığına ve mantığına değil, yalnızca gizli bir anahtarın gizliliğine bağlı olduğu anlamına gelir. Başka bir deyişle, OAuth 1.0 güvenliği için gereken yalnızca gizli anahtarın gizli tutulması koşuludur. Bu kulağa aşırı gelebilir, ancak koşul zaten yerine getirilmişse imza hesaplaması hiçbir güvenlik geliştirmesi yapmaz.

Aynı şekilde, OAuth 2.0 gizli müşterileri de aynı şarta bağlıdır. Durum zaten tatmin olmuşsa, güvenli bağlantı TLS kullanarak ve gönderme oluştururken herhangi bir sorun client_idve client_secretgüvenli bir bağlantı üzerinden bir yetkilendirme sunucusuna? Her ikisi de aynı koşula bağlıysa, OAuth 1.0 ve OAuth 2.0 gizli istemcileri arasında güvenlik düzeyinde büyük bir fark var mı?

OAuth 1.0'ın OAuth 2.0'ı suçlaması için iyi bir neden bulamıyorum. Gerçek şu ki, (1) OAuth 1.0 yalnızca gizli müşteriler için bir spesifikasyon ve (2) OAuth 2.0, gizli müşteriler ve desteklenen genel müşteriler için de protokolü basitleştirdi . İyi bilinip bilinmediğine bakılmaksızın, akıllı telefon uygulamaları OAuth 2.0'dan yararlanan genel istemciler ( RFC 6749, 9 ) olarak sınıflandırılır .

Belirteç oluşturulduktan sonra gerçek API çağrıları için OAuth 2.0 imzalarına gerek yoktur. Yalnızca bir güvenlik belirteci vardır.

OAuth 1.0, istemcinin her API çağrısı için iki güvenlik belirteci göndermesini ve her ikisini de imza oluşturmak için kullanmasını gerektirir. Korumalı kaynaklar uç noktalarının isteği doğrulamak için istemci kimlik bilgilerine erişmesini gerektirir.

Burada OAuth 1.0 ve 2.0 arasındaki fark ve her ikisinin nasıl çalıştığı açıklanmaktadır.

OAuth 2 görünüşe göre zaman kaybıdır (yoğun bir şekilde dahil olan birinin ağzından):

https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529

Diyor ki (kısalık için düzenlenmiş ve vurgu için cesur):

... artık OAuth 2.0 standardıyla ilişkilendirilemiyorum. Başyazar ve editör olarak görevimden istifa ettim, ismimi şartnameden çıkardım ve çalışma grubundan ayrıldım. İsmimi üç yıldır titizlikle çalıştığım bir belgeden çıkarmak ve iki düzineden fazla taslak kolay değildi. Beş yılı aşkın süredir yürüttüğüm bir çabadan yola çıkmaya karar vermek acı vericiydi.

... Sonunda, OAuth 2.0'ın kötü bir protokol olduğu sonucuna vardım. WS- * kötü. Artık onunla ilişkilendirilmek istemediğim kadar kötü. ... OAuth 1.0 ile karşılaştırıldığında, 2.0 spesifikasyonu daha karmaşık, daha az birlikte çalışabilir, daha az kullanışlı, daha eksik ve en önemlisi daha az güvenlidir.

Açıkça anlaşılacağı gibi, OAuth 2.0, web güvenliğini derinlemesine anlayan bir geliştiricinin elde edilmesi muhtemelen güvenli bir uygulamadır. Bununla birlikte, çoğu geliştiricinin elinde - son iki yılın deneyimi gibi - 2.0 muhtemelen güvensiz uygulamalar üretecektir.

Bazı gelişmiş açıklamalara ihtiyacınız varsa her iki özelliği de okumalısınız:

https://oauth.net/core/1.0a/

https://oauth.net/2/

Akış farklılıklarının net bir açıklamasına ihtiyacınız varsa, bu size yardımcı olabilir:

OAuth 1.0 Akışı

1. İstemci uygulaması Twitter gibi sağlayıcıya kaydolur.
2. Twitter, istemciye bu uygulamaya özgü bir “tüketici sırrı” sağlar.
3. Müşteri uygulaması , benzersiz "tüketici sırrı" ile Twitter'a gönderilen tüm OAuth isteklerini imzalar .
4. OAuth isteğinden herhangi biri hatalı biçimlendirilirse, veriler eksikse veya yanlış imzalanırsa, istek reddedilir.

OAuth 2.0 Akışı

1. İstemci uygulaması Twitter gibi sağlayıcıya kaydolur.
2. Twitter, istemciye o uygulamaya özgü bir “istemci sırrı” sağlar.
3. İstemci uygulaması , genel olarak http başlığı olarak her istekle birlikte "istemci sırrı" nı içerir .
4. OAuth isteğinden herhangi biri hatalı biçimlendirilmiş, eksik veriler veya yanlış sır içeriyorsa, istek reddedilir.

Kaynak: https://codiscope.com/oauth-2-0-vs-oauth-1-0/

OAuth 2.0, işleri aşağıdaki yollarla basitleştirmeyi vaat ediyor:

1. Belirteci oluşturmak için gereken tüm iletişim için SSL gereklidir. Bu karmaşıklıkta büyük bir azalmadır, çünkü bu karmaşık imzalara artık gerek yoktur.
2. Jeton oluşturulduktan sonra gerçek API çağrıları için imza gerekmez - SSL burada da şiddetle önerilir.
3. Belirteç oluşturulduktan sonra OAuth 1.0, istemcinin her API çağrısında iki güvenlik belirteci göndermesini ve her ikisini de imza oluşturmak için kullanmasını gerektiriyordu. OAuth 2.0'da yalnızca bir güvenlik belirteci vardır ve imza gerekmez.
4. Protokolün hangi bölümlerinin API'yi uygulayan asıl sunucu olan "kaynak sahibi" tarafından uygulandığı ve hangi bölümlerin ayrı bir "yetkilendirme sunucusu" tarafından uygulanabileceği açıkça belirtilmiştir. Bu, Apigee gibi ürünlerin mevcut API'lara OAuth 2.0 desteği sunmasını kolaylaştıracaktır.

Kaynak: http://blog.apigee.com/detail/oauth_differences

Güvenlik açısından, OAuth 1'i seçerdim. Bkz. OAuth 2.0 ve cehenneme giden yol

Bu bağlantıdan alıntı: "Şu anda 1.0'ı başarılı bir şekilde kullanıyorsanız 2.0'ı görmezden gelin. 1.0'ın üzerinde gerçek bir değer sunmuyor (müşteri geliştiricilerinizin şimdiye kadar 1.0 imza bulduğunu tahmin ediyorum).

Bu alanda yeniyseniz ve kendinizi bir güvenlik uzmanı olarak görüyorsanız, özelliklerini dikkatlice inceledikten sonra 2.0 kullanın. Uzman değilseniz, 1.0'ı kullanın veya doğru olması için güvendiğiniz bir sağlayıcının 2.0 uygulamasını kopyalayın (Facebook'un API belgeleri başlamak için iyi bir yerdir). 2.0, büyük ölçekli için daha iyidir, ancak büyük bir işlem yapıyorsanız, muhtemelen sizin için hepsini çözmek için sitede bazı güvenlik uzmanlarınız vardır. "