OAuth 2'deki örtük hibe yetkilendirme türünün amacı nedir?

Sadece bir tür kör noktam ya da neyim var bilmiyorum, ama OAuth 2 spec'i defalarca okudum ve posta listesi arşivlerini inceledim ve neden Örtülü Hibe'nin iyi bir açıklamasını henüz bulamadım erişim belirteçleri elde etmek için akış geliştirilmiştir. Yetkilendirme Kodu Yardımı ile karşılaştırıldığında, çok zorlayıcı bir sebep olmadan istemci kimlik doğrulamasından vazgeçtiği görülüyor. Bu "bir betik dili kullanarak bir tarayıcıda uygulanmış istemciler için nasıl optimize edilir" (belirtimi belirtmek için)?

Her iki akış da aynı şekilde başlar (kaynak: http://tools.ietf.org/html/draft-ietf-oauth-v2-22 ):

1. İstemci akışı, kaynak sahibinin kullanıcı aracısını yetkilendirme bitiş noktasına yönlendirerek başlatır.
2. Yetkilendirme sunucusu kaynak sahibinin kimliğini doğrular (kullanıcı aracısı aracılığıyla) ve kaynak sahibinin istemcinin erişim isteğini kabul edip etmediğini belirler.
3. Kaynak sahibinin erişim izni verdiği varsayılarak, yetkilendirme sunucusu daha önce (yeniden istekte veya istemci kaydı sırasında) verilen yeniden yönlendirme URI'sini kullanarak kullanıcı aracısını istemciye yeniden yönlendirir.
   • Yönlendirme URI'sı bir yetkilendirme kodu içerir (Yetkilendirme kodu akışı)
   • Yeniden yönlendirme URI'si, URI parçasındaki erişim belirtecini içerir (Örtülü akış)

Akımlar burada ayrılıyor. Her iki durumda da, bu noktada yeniden yönlendirme URI'sı, istemci tarafından barındırılan bazı uç noktalara yöneliktir:

• Yetkilendirme kodu akışında, kullanıcı aracısı URI'deki Yetkilendirme koduyla bu bitiş noktasına isabet ettiğinde, bu bitiş noktasındaki kod, daha sonra gerektiğinde kullanabileceği bir erişim belirteci için yetkilendirme kodunu istemci kimlik bilgileriyle değiştirir. Örneğin, bunu sayfadaki bir komut dosyasının erişebileceği bir web sayfasına yazabilir.
• Örtük akışı, bu istemci kimlik doğrulama adımını tamamen atlar ve yalnızca bir web sayfasını istemci komut dosyasıyla yükler. Burada, erişim belirtecinin çok fazla iletilmesini engelleyen URL parçasına sahip şirin bir hile var, ancak sonuçta esas olarak aynı: istemci tarafından barındırılan site, erişim belirtecini alabilen bir komut dosyası içeren bir sayfa sunuyor .
  

Dolayısıyla sorum: burada istemci kimlik doğrulama adımını atlayarak ne kazanıldı?

İşte düşüncelerim:

Yetkilendirme kodu akışındaki kimlik doğrulama kodu + belirtecinin amacı, sunucudan sunucuya seyahat ettikleri için belirteç ve istemci sırrının hiçbir zaman kaynak sahibine maruz kalmamasıdır.

Öte yandan, örtük hibe akışı tamamen javascript kullanılarak uygulanan ve kaynak sahibinin tarayıcısında çalışan istemciler içindir. Bu akışı kullanmak için herhangi bir sunucu tarafı koduna ihtiyacınız yoktur. Daha sonra, kaynak sahibinin tarayıcısında her şey olursa, artık kimlik doğrulama kodu ve istemci sırrı yayınlamak mantıklı değildir, çünkü jeton ve istemci sırrı hala kaynak sahibiyle paylaşılacaktır. Kimlik doğrulama kodu ve istemci sırrı eklemek, gerçek güvenlik eklemeden akışı daha karmaşık hale getirir.

Yani "ne elde edildi?" "basitlik" tir.

Güvenlik nedeniyle orada, basitlik için değil.

Kullanıcı aracısı ile istemci arasındaki farkı göz önünde bulundurmalısınız :

Kullanıcı aracısı, kullanıcının ("kaynak sahibi") sistemin diğer bölümleriyle (kimlik doğrulama sunucusu ve kaynak sunucusu) iletişim kurduğu yazılımdır.

İstemci, kaynak sunucudaki kullanıcının kaynaklarına erişmek isteyen yazılımdır.

Ayrılmış kullanıcı aracısı ve istemci durumunda Yetkilendirme Kodu Verilmesi mantıklıdır. Örneğin kullanıcı, Kickstarter'daki Facebook hesabıyla giriş yapmak için bir web tarayıcısı (kullanıcı aracısı) kullanır. Bu durumda istemci, kullanıcı oturumlarını işleyen Kickstarter'ın sunucularından biridir. Bu sunucu erişim kodunu ve yenileme kodunu Facebook'tan alır. Böylece, bu tür istemci "güvenli" olarak kabul edilir, kısıtlı erişim nedeniyle belirteçler kaydedilebilir ve Kickstarter kullanıcı kaynaklarına erişebilir ve hatta kullanıcı etkileşimi olmadan erişim belirteçlerini yenileyebilir.

Kullanıcı aracısı ve istemci birleştirilirse (örn. Yerel mobil uygulama, javascript uygulaması), Örtük Yetkilendirme İş Akışı uygulanabilir. Kaynak sahibinin varlığına (kimlik bilgilerini girmek için) dayanır ve yenileme jetonlarını desteklemez. Bu istemci erişim belirtecini daha sonra kullanmak üzere saklarsa, güvenlik sorunu olacaktır, çünkü belirteç istemcinin diğer uygulamaları veya kullanıcıları tarafından kolayca çıkarılabilir. Yenileme belirtecinin bulunmaması ek bir ipucudur, bu yöntemin kullanıcı yokluğunda kullanıcı kaynaklarına erişmek için tasarlanmamıştır.

Genel açıklama, bir JavaScript istemcisi kullanırken Örtülü hibenin uygulanmasının daha kolay olduğudur. Ama bence bu ona bakmak için yanlış bir yol. Doğrudan XMLHttpRequest aracılığıyla korunan kaynaklar isteyen bir JavaScript istemcisi kullanıyorsanız, daha az güvenli olmasına rağmen Örtülü bağış tek seçeneğinizdir. *

Yetkilendirme Kodu hibesi ek güvenlik sağlar, ancak yalnızca korunan kaynakları isteyen bir web sunucunuz olduğunda çalışır. Web sunucusu erişim belirtecini saklayabildiğinden, erişim belirtecinin Internet'e maruz kalma riski daha azdır ve uzun süren bir belirteç verebilirsiniz. Web sunucusuna güvendiğinden, bir "yenileme belirteci" verilebilir, böylece eskisinin süresi dolduğunda yeni bir erişim belirteci alabilir.

Ancak - ve bu kaçırılması kolay bir noktadır - Yetkilendirme kodu akışının güvenliği yalnızca web sunucusu kullanıcı kimlik doğrulaması (oturum açma) ile oluşturulan bir oturumla korunuyorsa çalışır. Oturum olmadan, güvenilmeyen bir kullanıcı, client_id öğesini kullanarak web sunucusuna istekte bulunabilir ve kullanıcının erişim belirtecine sahip olmasıyla aynı olur. Oturum eklemek, yalnızca kimliği doğrulanmış bir kullanıcının korumalı kaynaklara erişebileceği anlamına gelir. Client_id, söz konusu webapp'ın kimlik doğrulaması değil, yalnızca JS webapp'ın "kimliği" dir.

Ayrıca, OAuth jetonunun süresi dolmadan oturumu sonlandırabileceğiniz anlamına da gelir. Bir erişim belirtecini geçersiz kılmanın standart bir yolu yoktur. Ancak oturumunuzun süresi dolarsa, erişim belirteci işe yaramaz, çünkü web sunucusundan başka kimse bilmiyor. Güvenilmeyen bir kullanıcı oturum anahtarınıza erişirse, korunan kaynaklara yalnızca oturum geçerli olduğu sürece erişebilir.

Web sunucusu yoksa Örtülü hibeyi kullanmanız gerekir. Ancak bu, erişim belirtecinin Internet'e maruz kaldığı anlamına gelir. Güvenilmeyen bir kullanıcı ona erişirse, süresi dolana kadar kullanabilir. Bu, Yetkilendirme Kodu hibesinden daha uzun süre erişebilecekleri anlamına gelir. Bu nedenle, belirtecin daha erken sona ermesini ve daha hassas kaynaklara erişim vermekten kaçınmak isteyebilirsiniz.

* DÜZENLEME: Daha yakın zamanda, insanlar, sunucusuz web uygulamalarında bile Örtülü hibeyi kullanmamanızı tavsiye etmektedir. Bunun yerine, PKCE ile birlikte boş bir sır ile yapılandırılmış Yetkilendirme Kodu hibesini kullanabilirsiniz. Auth-code hibe, erişim belirtecini tarayıcı geçmişinizde saklamaktan kaçınır ve PKCE, biri authcode kodunu çalmak için yönlendirme URL'sini ele geçirirse ifşa etmekten kaçınır. Bu durumda, istemciniz muhtemelen güvenli bir şekilde depolayamayacağından, bir yenileme belirteci döndürmekten kaçınmak için sunucuya ihtiyacınız olacaktır. Ve yukarıda belirtilen sınırlamalara sahip bir erişim belirteci vermelidir.

Bir kullanıcı, sunucu tarafı bileşeni olmayan bir tarayıcı tabanlı veya "herkese açık" (JavaScript) web uygulaması çalıştırıyorsa, kullanıcı uygulamaya (ve çalıştığı tarayıcıya) potansiyel olarak diğer tarayıcılarla güvenir tabanlı uygulamalar ...).

Üçüncü taraf uzak sunucu yok, yalnızca kaynak sunucu var. Yetkilendirme kodunun bir yararı yoktur, çünkü tarayıcının yanı sıra kullanıcı adına hareket eden başka bir aracı yoktur . Aynı nedenden dolayı müşteri kimlik bilgilerinin hiçbir faydası yoktur. ( Herhangi bir müşteri bu akışı kullanmaya çalışabilir.)

Ancak güvenlik sonuçları önemlidir. Gönderen http://tools.ietf.org/html/rfc6749#section-10.3 :

Örtülü hibe türünü kullanırken, erişim belirteci URI parçasında iletilir ve bu da yetkisiz taraflara gösterilebilir.

Http://tools.ietf.org/html/rfc6749#section-10.16 adresinden :

Bir kaynak sahibi, bir saldırganın kötü amaçlı istemcisine erişim belirteci vererek bir kaynağa isteyerek erişim yetkisi verebilir. Bunun nedeni kimlik avı veya başka bir bahane olabilir ...

Cevabı ve Dan'ın yorumunu doğru anladığımdan emin değilim. Bana öyle geliyor ki cevap bazı gerçekleri doğru ifade etti, ancak OP'nin tam olarak ne istediğini gösteriyor. Doğru anlarsam, örtük hibe akışının en büyük avantajı JS uygulaması (örneğin Chrome uzantısı) gibi bir istemcinin istemci sırrını açığa vurması gerekmemesidir.

Dan Taflin şunları söyledi:

... yetkilendirme kodu akışında kaynak sahibinin hiçbir zaman erişim belirtecini görmesi gerekmez, ancak javascript istemcilerinde bu kaçınılmazdır. Bununla birlikte, yetkilendirme kodu akışı kullanılarak javascript istemcilerinden istemci sırrı saklanabilir.

Belki sizi yanlış anladım, ancak istemci (bu durumda JS uygulaması) istemci kimlik bilgilerini (istemci anahtarı ve gizli) yetkilendirme kodu akışındaki kaynak sunucuya iletmelidir, değil mi? İstemci sırrı "JS'den saklanamaz".

Örtük Grant , istemci tarafı JavaScript uygulamaları da dahil olmak üzere bir istemci sırrını koruyamayan uygulamaları desteklemek için tasarlanmış olsa da , bazı sağlayıcılar bunun yerine bir İstemci Sırrı olmadan Yetkilendirme Kodunu kullanarak bir alternatif uyguluyorlar. OAuth 2.0 IETF RFC-6749 2012'de yayınlandı ve güncel önerilerden bazıları 2017'den geliyor.

IETF OAuth posta listesiyle ilgili 2017 tartışması şu uygulayıcılardan edinilebilir:

• Redhat: https://www.ietf.org/.../oauth/current/msg16966.html
• Deutsche Telekom: https://www.ietf.org/.../oauth/current/msg16968.html
• Akıllı Sağlık BT: https://www.ietf.org/.../oauth/current/msg16967.html

Daha fazlasını buradan okuyun:

• https://aaronparecki.com/oauth-2-simplified/
• https://aaronparecki.com/oauth-2-simplified/#single-page-apps

Örtük , daha önce bir sırrı olmayan müşteriler için önerilmişti, ancak hiçbir sır olmadan Yetkilendirme Kodu hibesi kullanılarak geçersiz kılındı.

...

Önceden, tarayıcı tabanlı uygulamaların hemen bir erişim belirteci döndüren ve bir belirteç değiştirme adımı olmayan "Örtülü" akışı kullanması öneriliyordu. Spesifikasyonun ilk yazıldığı günden bu yana, sektördeki en iyi uygulama, yetkilendirme kodu akışının müşteri sırrı olmadan kullanılmasını önermek için değişti. Bu, state parametresini kullanmak gibi güvenli bir akış oluşturmak için daha fazla fırsat sağlar. Kaynaklar: Redhat , Deutsche Telekom , Smart Health IT .

Örtülü Grant'in İstemci Sırrı olmadan Kimlik Doğrulama Koduna geçiş burada mobil uygulamalar için de belirtilmiştir:

• https://aaronparecki.com/oauth-2-simplified/#mobile-apps

diğer cevaplara ek olarak, Örtük profilinin yalnızca Yetkilendirme Sunucusuna geri çağrı gerektiren Yetkilendirme Kodu akışının aksine bir ön kanal akışına izin verdiğini fark etmek de önemlidir; bu, Kapalı akışın oldukça popüler SAML POST bağlayıcısına benzediği ve Yetkilendirme Kodu akışının daha az yaygınlaştırılmış SAML Yapı bağlayıcısına benzediği Auth 2.0'ın üzerine kurulmuş bir SSO protokolü olan OpenID Connect'te belirginleşir.

Örtük akışta, kullanıcının tarayıcısı bozuksa (kötü uzantı / virüs), yolsuzluk kullanıcının kaynaklarına erişir ve kötü şeyler yapabilir.

Yetkilendirme akışında yolsuzluk olamaz çünkü istemci sırrını bilmez.

https://tools.ietf.org/html/rfc6749#page-8

üstü kapalı

Örtük hibe, JavaScript gibi bir komut dosyası dili kullanarak tarayıcıda uygulanan istemciler için optimize edilmiş basitleştirilmiş bir yetkilendirme kodu akışıdır. Örtük akışta, istemciye bir yetkilendirme kodu vermek yerine, doğrudan bir erişim belirteci verilir (kaynak sahibi yetkilendirmesinin sonucu olarak). Hibe türü örtüktür, çünkü hiçbir ara kimlik bilgisi (bir yetkilendirme kodu gibi) yayınlanmaz (ve daha sonra bir erişim belirteci elde etmek için kullanılır).

Örtülü hibe akışı sırasında bir erişim belirteci verilirken,
yetkilendirme sunucusu istemcinin kimliğini doğrulamaz. Bazı
durumlarda, istemci kimliği
, erişim belirtecini istemciye iletmek için kullanılan yeniden yönlendirme URI'si aracılığıyla doğrulanabilir . Erişim belirteci, kaynak sahibine veya kaynak sahibinin kullanıcı aracısına erişimi olan diğer uygulamalara maruz kalabilir.

Örtülü bağışlar
,
bir
erişim belirteci elde etmek için gereken gidiş-dönüşlerin sayısını azalttığından, bazı istemcilerin (tarayıcı içi uygulama olarak uygulanan bir istemci gibi) yanıt verebilirliğini ve verimliliğini artırır .

Bence Will Cain "Aynı nedenden dolayı müşteri kimlik bilgileri için hiçbir faydası yoktur. (Herhangi bir müşteri bu akışı kullanmaya çalışabilir.)" Ayrıca örtük akış için redirect_uri belki "localhost" - geri arama yok örtük akış için Yetkilendirme Sunucusundan yapılır. İstemciye önceden güvenmenin bir yolu olmadığından, kullanıcının kullanıcı hak taleplerinin açıklanmasını onaylaması gerekir.

Örtülü Hibe, Yetkilendirme Bitiş Noktasından a GET. Bu, yetkilendirme sunucusunun CORS'yi desteklemesi gerekmediği anlamına gelir.

Bu bir endişe kaynağı değilse ve yetkilendirme sunucusuyla ilgili başka sorunların olmaması durumunda (örn. Yenileme jetonları bir nedenden dolayı isteğe bağlı değildir), son sektör trendlerine göre, yetkilendirme kodu akışı, genel müşteriler için bile tercih edilir. ve en azından resmi taslağın bu (şimdiki) örneğine .

Tarihsel olarak, örtülü akışı uygulamak için başka nedenler vardı, ancak şu anda yetkilendirme kodu hibesinin sağladığı güvenlik avantajlarından daha ağır basmış görünüyorlar:

• gizli istemciler için simgeleri bir arka kanal üzerinden gönderme ve kullanma seçeneği
• genel istemciler için tarayıcı geçmişinde belirteçleri göstermeme
• "her türlü OAuth istemcisi" için PKCE ile jetonlar verilmeden önce yetkisiz bir akışı kesintiye uğratma

Az önce OAuth 2.0 hakkında bazı makalelerle karşılaştım. Yazar, Örtülü akışın arkasındaki nedenin JS uygulamalarının orada taleplerde çok kısıtlı olduğunu belirtmektedir:

örtük türün neden OAuth 2.0'a eklendiğini merak ediyorsanız, açıklama basittir: Aynı Köken Politikası. O zamanlar, ön uç uygulamalarının, kod kullanarak erişim belirtecini almak için farklı ana bilgisayarlara istek göndermesine izin verilmedi. Bugün CORS (Kaynaklar Arası Kaynak Paylaşımı) var.

https://medium.com/securing/what-is-going-on-with-oauth-2-0-and-why-you-should-not-use-it-for-authentication-5f47597b2611