“Örtük” akış çok iyi çalıştığında neden OAuth2'de bir “Yetkilendirme Kodu” akışı var?


264

"Örtük" akışla, istemci (muhtemelen bir tarayıcı) Kaynak Sahibi (yani kullanıcı) erişim verdikten sonra bir erişim belirteci alır.

Ancak "Yetkilendirme Kodu" akışıyla, istemci (genellikle bir web sunucusu) yetkilendirme kodunu yalnızca Kaynak Sahibi (yani kullanıcı) erişim verdikten sonra alır. Bu yetkilendirme koduyla istemci, erişim belirtecini almak için client_id ve client_secret öğelerini yetkilendirme koduyla birlikte geçen API'ye başka bir çağrı yapar. Burada iyi tanımlanmış .

Her iki akış da aynı sonuca sahiptir: bir erişim belirteci. Ancak, "Örtük" akış çok daha basittir.

Soru: "Örtük" akış dikişleri iyi olduğunda neden "Yetkilendirme Kodu" akışı ile uğraşasınız? Neden web sunucusu için "Örtük" kullanmıyorsunuz?

Hem sağlayıcı hem de müşteri için daha fazla iş.



1
Teşekkürler, zaten okuyun. Yine de soruyu cevaplamıyor.
Aron Woost

1
İyi soru aslında ve nadiren cevaplandı :) Aşağıya bakın.
Nicolas Garnier

1
@AronWoost Sunucu web uygulamasını ve tarayıcı uygulamasını yanlış anladığınızı düşünüyorum
onmyway133

@entropy Benim sorum buydu; neden sunucu için tarayıcı akışını kullanmıyorsunuz?
Aron Woost

Yanıtlar:


293

tl; dr: Bunların hepsi güvenlik nedeniyle.

OAuth 2.0 bu iki kriteri karşılamak istedi:

  1. Geliştiricilerin HTTPS olmayan yönlendirme URI'sini kullanmalarına izin vermek istersiniz, çünkü tüm geliştiricilerin SSL etkin bir sunucusu yoktur ve eğer her zaman düzgün yapılandırılmazlar (kendinden imzalı olmayan, güvenilir SSL sertifikaları, senkronize sunucu saati ...).
  2. Bilgisayar korsanlarının istekleri keserek erişim / yenileme jetonlarını çalmasını istemezsiniz.

Detaylar aşağıda:

Örtük akış, güvenlik nedeniyle yalnızca tarayıcı ortamında mümkündür:

Olarak kapalı akış karma fragmanı (değil gibi bir URL parametresi) doğrudan geçirilir belirteç erişim. Karma parçasıyla ilgili önemli bir şey, karma parçası içeren bir bağlantıyı izlediğinizde, yalnızca tarayıcının karma parçasının farkında olmasıdır. Tarayıcılar karma parçasını doğrudan hedef web sayfasına (yönlendirme URI'sı / istemcinin web sayfası) iletir. Karma parçası aşağıdaki özelliklere sahiptir:

  • HTTP isteğinin bir parçası değildir, bu nedenle sunucular tarafından okunamazlar ve bu nedenle aracı sunucular / yönlendiriciler tarafından yakalanamazlar (bu önemlidir).
  • Yalnızca tarayıcıda (istemci tarafında) bulunurlar, bu nedenle karma parçasını okumanın tek yolu sayfada çalışan JavaScript kullanmaktır.

Bu, bir Erişim Sunucusu'nun aracı sunucu tarafından yakalanma riski olmadan doğrudan istemciye iletilmesini mümkün kılar. Bu, yalnızca olası istemci tarafı olma uyarısına sahiptir ve erişim belirtecini kullanmak için istemci tarafında çalışan javascript gerekir.

Örtük akış ayrıca geçici çözüm / kaçınmak için daha fazla mantık gerektiren güvenlik sorunlarına da sahiptir:

  • Saldırgan, farklı bir web sitesindeki / uygulamadaki bir kullanıcıdan erişim jetonu alabilir (diyelim diğer web sitesinin / uygulamanın sahibi olup olmadığını), jetonu web sitelerine kaydedebilir ve ardından web sitenize bir URL parametresi olarak iletebilir bu nedenle kullanıcıyı web sitenizde taklit eder. Bundan kaçınmak için, jetonun kendi müşteri kimliğinizle (yani kendi uygulamanız tarafından) verildiğinden emin olmak için erişim belirteciyle ilişkili Müşteri Kimliğini (örneğin, Google için tokeninfo uç noktasını kullanabilirsiniz) kontrol etmeniz veya imzayı kontrol etmeniz gerekir. bir IDToken kullanıyorsanız (ancak bu istemcinizin sırrını gerektirir).
  • Yetkilendirme isteği kendi mülkünüzden gelmediyse (Oturum Sabitleme saldırıları olarak adlandırılır), bundan kaçınmak için web sitenizden rastgele bir karma oluşturmak, bunu bir çereze kaydetmek ve aynı karma değerini durum URL parametresine aktarmak istersiniz. auth isteği, kullanıcı geri geldiğinde durum parametresini çerezle kontrol edersiniz ve eşleşmesi gerekir.

In yetki kodu akış o URL parametreleri, bu nedenle herhangi bir aracı sunucu / isteğiniz geçerdi hangi yönlendiriciler (yüzlerce olabilir) mümkün olabilir HTTP isteği parçası olduğundan bir URL parametresinde doğrudan jetonun bir erişim geçmek mümkün değildir Ortadaki Man saldırıları olarak bilinenlere izin veren şifrelenmiş bağlantı (HTTPS) kullanmıyorsanız erişim belirtecini okuyun.

Erişim belirtecini doğrudan bir URL parametresine geçirmek teorik olarak mümkün olabilir, ancak yetkilendirme sunucusu yeniden yönlendirme URI'sının TLT şifrelemeli HTTPS ve 'güvenilir' bir SSL sertifikası (genellikle ücretsiz olmayan bir Sertifika Yetkilisi'nden) kullandığından emin olmalıdır. Hedef sunucunun yasal olduğundan ve HTTP isteğinin tamamen şifreli olduğundan emin olmak için. Tüm geliştiricilerin bir SSL sertifikası satın almaları ve alan adlarında SSL'yi düzgün bir şekilde yapılandırmaları büyük bir acı olur ve benimsenmeyi çok yavaşlatır. Bu nedenle, bir kerelik bir kullanımlık "yetkilendirme kodu", yalnızca meşru alıcının değiş tokuş edebilmesi (istemci sırrına ihtiyacınız olduğu için) ve kodun şifrelenmemiş işlemler üzerinden istekleri kesen potansiyel bilgisayar korsanları için işe yaramayacağı şekilde sağlanır. (çünkü onlar

Örtülü akışın daha az güvenli olduğunu, yeniden yönlendirme üzerine alan adının taklit edilmesi gibi potansiyel saldırı vektörleri olduğunu da iddia edebilirsiniz - örneğin, müşterinin web sitesinin IP adresini ele geçirerek. Bu, örtük akışın yalnızca (sınırlı bir zaman kullanımı olması beklenen) erişim belirteçleri vermesinin ve asla (zaman içinde sınırsız olan) belirteçleri yenilememesinin nedenlerinden biridir. Bu sorunu çözmek için, web sayfalarınızı mümkün olduğunda HTTPS etkin bir sunucuda barındırmanızı öneririz.


12
@AndyDufresne Bu iki istek HTTPS (zorunlu) üzerinden yapılmalıdır, çünkü bunlar yalnızca HTTPS'yi desteklemek zorunda olan OAuth sunucusuna yapılan isteklerdir . HTTPS'yi desteklemesi gerekmeyen yalnızca istemci / istekte bulunan sunucu olduğundan Auth Code, HTTP üzerinden yalnızca potansiyel olarak net bir şekilde gönderilir. Ancak Auth Codeistemci kimliği / sırrı olmadan işe yaramaz. Temel olarak OAuth Kodu akışının amacı, SSL etkin bir sunucuya sahip olmanın yükünün API'ların (siz, ben) kullanıcıları değil OAuth Sağlayıcısı (Google / Facebook vb ...) üzerinde olmasıdır.
Nicolas Garnier

5
Tamam, şimdi kimlik doğrulama kodunun düz HTTP üzerinden geçirilebileceğini ve koklama riski taşıdığını takip ediyorum. Kodu bir kez kullanmanız ve istemciyi bir erişim belirteciyle değiştirmesi için gizli kabul etmesi, yetkilendirme sunucusu ortadaki Adam saldırısını önleyebilir. Ancak bu, erişim belirteci için de geçerli değil mi? API'lerin kullanıcısı düz HTTP'de olabileceğinden, erişim belirtecinin bilgisayar korsanı tarafından koklanması riski olmayacak mı? Not - Bu konu aktif olduğu için bir süre geçtikten sonra bile kavramı açıklama çabalarınızı takdir ediyorum. Teşekkürler !
Andy Dufresne

8
no pb :) API'ye yapılan istekler - erişim belirteci kablo üzerinden gönderildiğinde (isteği yetkilendirmek için) - HTTPS üzerinden zorunlu olarak yapılır. Teoride, müşteri hiçbir zaman erişim kodunu hiçbir zaman telsiz HTTP üzerinden göndermemelidir.
Nicolas Garnier

5
Bu adımdaki Erişim Simgesi, İstemciden kaynak sunucuya HTTPS isteğinin yanıtının bir parçasıdır. Bu yanıt hala şifreli.
Nicolas Garnier

13
Temel olarak istemciden kaynak sunucuya başlatılan istekler HTTPS aracılığıyla yapılır (çünkü kaynak sahibi sunucunun HTTPS'yi desteklemesi gerekir). Yalnızca HTTP üzerinden yapılabilecek başka bir yerden istemciye başlatılan istekler (istemci sunucu HTTPS'yi desteklemeyebileceğinden). Örneğin, kullanıcı gant sayfasında yetki verdikten sonra yetkilendirme akışı sırasında gerçekleşen yönlendirme, tarayıcıdan istemci sunucusuna başlatılan bir yönlendirmedir ve HTTP'de yapılabilir.
Nicolas Garnier

8

Örtülü Akış oldukça kolay tüm akışı yapar, ama aynı zamanda daha az güvenli .
Genellikle bir Tarayıcı içinde çalışan JavaScript olan istemci uygulaması daha az güvenilir olduğundan, uzun ömürlü erişim için yenileme jetonları döndürülmez.
Bu akışı, kullanıcının verilerine geçici erişime (birkaç saat) ihtiyaç duyan uygulamalar için kullanmalısınız.
JavaScript istemcilerine erişim belirteci döndürmek, tarayıcı tabanlı uygulamanızın özel dikkat göstermesi gerektiği anlamına gelir - erişim belirtecini diğer sistemlere sızdırabilecek XSS Saldırılarını düşünün.

https://labs.hybris.com/2012/06/05/oauth2-the-implicit-flow-aka-as-the-client-side-flow


Bir XSS güvenlik açığı olduğunda, yetkilendirme kodu akışının bile çok yardımcı olmadığını umuyorum. Ancak, erişim belirtecinin Örtük akıştaki javascript'e nasıl aktarıldığının (karma parçası olarak) standartlaştırıldığından ve web sitesinde XSS güvenlik açığı varsa, URL karma işleminden erişim belirtecini okuyan bir saldırı oluşturduğunu kabul ediyorum. parçası oldukça kolaydır. Yetkilendirme kodu akışı ile, siteler arası talep sahteciliği mümkün olabilir.
Marcel

Ayrıca, yalnızca siteler arası komut dosyası oluşturma ile ilgili değildir. Web sitenizde çalışan herhangi bir JavaScript kitaplığı erişim belirtecini çalmaya çalışabilir (örneğin, üçüncü taraf CDN kitaplıkları veya javascript çerçevenizin kullandığı açık kaynak kitaplıkları).
Marcel

2
XSS artık İçerik Güvenliği İlkesi başlıkları ve Alt Kaynak Bütünlüğü (SRI) karmaları olduğunda büyük bir sorun değil.
Sergey Ponomarev

4

Gönderen OAuth spec :

4.2. Örtülü Hibe

Örtük hibe türü erişim belirteçleri elde etmek için kullanılır (yenileme belirteçleri verilmesini desteklemez) ve belirli bir yeniden yönlendirme URI'sini çalıştırdığı bilinen genel istemciler için en iyi duruma getirilmiştir. Bu istemciler genellikle bir tarayıcıda JavaScript gibi bir komut dosyası dili kullanılarak uygulanır.

Bu yeniden yönlendirmeye dayalı bir akış olduğundan, istemci kaynak sahibinin kullanıcı aracısıyla (genellikle bir web tarayıcısı) etkileşimde bulunabilmeli ve yetkilendirme sunucusundan gelen (yeniden yönlendirme yoluyla) istekleri alabilmelidir.

İstemcinin yetkilendirme ve erişim belirteci için ayrı istekte bulunduğu yetkilendirme kodu hibe türünden farklı olarak, yetkilendirme isteğinin sonucu olarak erişim belirtecini alır.

Örtük hibe türü, istemci kimlik doğrulamasını içermez ve kaynak sahibinin varlığına ve yeniden yönlendirme URI'sının kaydına dayanır. Erişim belirteci yeniden yönlendirme URI'sine kodlandığından, kaynak sahibine ve aynı cihazda bulunan diğer uygulamalara maruz kalabilir.

Peki ne düşünebiliriz:

  1. Bu, genel OAuth içindir, yani müşterinin kaydedilmesi gerekmediğinde ve kendi müşteri sırları olmadığında. Ancak ne auth sunucusu yönlendirme URL'sini kontrol eder ve bu aslında güvenlik için yeterlidir.

  2. Erişim belirteci tarayıcının adres çubuğunda oluşur, böylece kullanıcı url'yi kopyalayıp başka birine gönderebilir ve kullanıcı olarak günlüğe kaydedilir, yani Oturum sabitleme gibi bir şeydir. Ancak tarayıcı, URL'den karma parçasını kaldırmak için geçmişi değiştirerek ek bir yönlendirme yapar. Bir hacker'ın bir HTTP trafiğini koklayarak erişim belirtecini çalması da mümkündür, ancak bu HTTPS tarafından kolayca korunabilir. Bazı kötü amaçlı tarayıcı uzantılarının adres çubuğundan URL'lere erişimi olabilir, ancak bu sonuçta bozuk HTTPS sertifikası gibi kötü bir durumdur. Ve Auth kod akışı bile burada yardımcı olamaz. Gördüğüm şey, erişim belirtecini URL'nin karma parçası üzerinden geçirmenin kesinlikle güvenli olduğu.

  3. Bir HTTPS kullanılırken geçici erişim belirteci ve yenileme belirtecinin ayrılması işe yaramaz ve ham HTTP'de bile çok kullanışlı değildir. Ancak örtük akış yoluyla istemcinin yenileme jetonunu alamaması da saçmalıktır.

Bu yüzden, kesinlikle https üzerinde çalışan, yenileme jetonuna izin veren (veya onlardan hiç kurtulmamalıyız) ve Auth Cose hibe akışından daha tercih edilen yeni bir hibe akışı “güvenli örtük” getirmeliyiz.


3

Bizim için, müşterilerimiz telefonlarında bir kez uygulamamızla kimlik doğrulaması yapmak istiyorlardı ve bir kerede haftalarca tekrar giriş yapmak zorunda kalmıyorlardı. Kod akışı ile erişim belirtecinizle birlikte bir yenileme belirteci alırsınız. Örtülü akış size yenileme jetonu vermez. Erişim belirtecinin süresi oldukça kısadır, ancak yenileme simgelerinin süresi 90 güne kadar çıkabilir. Erişim belirtecinin süresi dolduğunda, istemci ve sunucu kodu, herhangi bir kullanıcı müdahalesi olmadan, perde arkasında, yeni bir erişim belirteci artı yenileme belirteci almak için bu yenileme belirtecini kullanabilir. Yenileme belirteci yalnızca bir kez kullanılabilir. Bunu Örtülü Akış ile yapamazsınız. Örtülü Akış kullanıyorsanız ve kullanıcınız bir saatten fazla bir süredir uygulamanızla etkileşimde bulunmuyorsa geri döndüklerinde tekrar giriş yapmaları gerekir. Bu bizim kullanım durumumuzda kabul edilemezdi,

Bu çalışır ve güvenlidir, çünkü yenileme jetonları iptal edilebilir. Bir müşteri telefonunu kaybettiğini veya dizüstü bilgisayarlarını veya bir bilgisayar korsanının masaüstüne girdiğini söylerse, o kullanıcı için tüm yenileme jetonlarını iptal edebiliriz. Tüm süreç boyunca hiçbir Kişisel Kimlik Bilgisi (PII) kodumuza, yani kullanıcının şifresine dokunmaz.

Kod akışı harika, ancak daha fazla iş gerektiriyor. MS şu anda işlemek için bir Açısal kütüphane yok, bu yüzden bir tane yazmak zorunda kaldı. Eğer ilgileniyorsanız size yardımcı olabilirim.


2

Cevabım şudur: Örtülü akışı web uygulaması sunucusuyla güvenli ve basit bir şekilde uygulayamazsınız.

Web uygulaması yetkilendirme işlemi kullanıcı etkileşimini içerir, bu nedenle Authentication Server, kullanıcı kimlik doğrulaması ve onayından sonra kullanıcının tarayıcısını web uygulamasının hedef sayfasına yönlendirmelidir (Bazı etkileşimlerden sonra kullanıcıyı web uygulamasına geri aktarmanın başka bir yolunu göremiyorum Kimlik Doğrulama Sunucusu).

Dolayısıyla simge, yönlendirme URL'si kullanılarak web uygulamasına aktarılmalıdır, değil mi?

@NicolasGarnier'in cevabında ve yorumlarında açıkladığı gibi, jetonu bir URL parçası olarak iletmenin bir yolu yoktur - web uygulaması sunucusuna ulaşmaz.

Yönlendirme URL'sinin bir URL parametresi olarak belirteci HTTPS altında bile güvenli olmaz: hedef sayfa ("karşılama sayfası" olsun) kaynaklar içeriyorsa (resimler, komut dosyaları, vb.) Bu kaynaklar seri aracılığıyla tarayıcı tarafından edinilir HTTP (S) istekleri (her biri RefererURL parametreleri dahil "karşılama sayfası" nın tam URL'sini içeren HTTP üstbilgisine sahip ). Belirteci sızıntı yapabilir.

Bu nedenle, yönlendirme URL'sinde jeton geçirmenin bir yolu yok gibi görünüyor. Bu nedenle ikinci aramaya ihtiyacınız var (Kimlik Doğrulama Sunucusundan İstemciye (ancak hangi URL'ye?) Veya İstemciden Kimlik Doğrulama Sunucusuna (Yetkilendirme Kodu akışındaki ikinci arama)

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.