OAuth 2.0: Yararları ve kullanım örnekleri - neden?

Herkes OAuth2 ile ilgili neyin iyi olduğunu ve bunu neden uygulamamız gerektiğini açıklayabilir mi? Soruyorum çünkü biraz kafam karıştı - işte şu anki düşüncelerim:

OAuth1 (daha kesin olarak HMAC) istekleri mantıklı, anlaşılması kolay, geliştirilmesi kolay ve gerçekten, gerçekten güvenli görünüyor.

OAuth2, bunun yerine, yetkilendirme istekleri, erişim belirteçleri ve yenileme belirteçleri getirir ve oturumun en başında takip ettiğiniz verileri almak için 3 istekte bulunmanız gerekir. Ve o zaman bile, isteklerinizden biri, token sona erdiğinde sonunda başarısız olur.

Başka bir erişim belirteci almak için, erişim belirteciyle aynı anda geçirilen bir yenileme belirteci kullanırsınız. Bu, erişim belirtecini güvenlik açısından boşuna mı yapıyor?

Ayrıca, / r / netsec'in yakın zamanda gösterdiği gibi, SSL tamamen güvenli değildir, bu nedenle her şeyi güvenli bir HMAC yerine TLS / SSL'ye alma çabası beni şaşırtıyor.

OAuth, bunun yaklaşık% 100 güvenlik olmadığını, ancak yayınlanmasını ve bitirilmesini savunuyor. Bu, bir sağlayıcının bakış açısından umut verici gelmiyor. 6 farklı akıştan bahsederken taslağın neyi başarmaya çalıştığını görebiliyorum, ama bu sadece kafama uymuyor.

Bence faydalarını ve akıl yürütmesini anlamaktan hoşlanmamaktan daha fazla olabilir, bu yüzden bu biraz haksız bir saldırı olabilir ve bu bir rant gibi görünebilirse özür dilerim.

Arka plan: OAuth 1.0a ve 2.0 için istemci ve sunucu yığınları yazdım.

Hem OAuth 1.0a hem de 2.0 , bir sunucunun kullanıcı kimliğinden emin olduğu iki aşamalı kimlik doğrulamayı ve bir sunucunun kullanıcı kimliğinin içerik sağlayıcısı tarafından sağlandığı üç aşamalı kimlik doğrulamayı destekler . Üç aşamalı kimlik doğrulama, yetkilendirme isteklerinin ve erişim belirteçlerinin devreye girdiği yerdir ve OAuth 1'in de bunlara sahip olduğunu belirtmek önemlidir.

Karmaşık olan: üç aşamalı kimlik doğrulama

OAuth teknik özelliklerinin ana noktası, bir içerik sağlayıcısının (örn. Facebook, Twitter vb.) Bir sunucunun (örneğin, istemci adına içerik sağlayıcıyla konuşmak isteyen bir Web uygulaması) istemcinin kimliğine sahip olmasını sağlamaktır . Üç aşamalı kimlik doğrulamanın sunduğu şey, istemci veya sunucu bu kimliğin ayrıntılarını (ör. Kullanıcı adı ve şifre) bilmek zorunda kalmadan bunu yapabilmektir .

OAuth'un ayrıntılarına çok fazla girmeden:

1. İstemci, istemcinin hizmetinin meşru bir istemcisi olduğunu doğrulayan sunucuya bir yetkilendirme isteği gönderir.
2. Sunucu, kaynaklarına erişim istemek için istemciyi içerik sağlayıcıya yönlendirir.
3. İçerik sağlayıcısı kullanıcının kimliğini doğrular ve genellikle kaynaklara erişmek için izin ister.
4. İçerik sağlayıcı istemciyi sunucuya yönlendirir ve başarılı veya başarısız olduğunu bildirir. Bu istek, başarı ile ilgili bir yetkilendirme kodu içerir.
5. Sunucu, içerik sağlayıcısına bant dışı bir istekte bulunur ve yetkilendirme kodunu bir erişim belirteciyle değiştirir.

Sunucu artık erişim belirtecini ileterek kullanıcı adına içerik sağlayıcısına istekte bulunabilir.

Her exchange (istemci-> sunucu, sunucu-> içerik sağlayıcısı) paylaşılan bir sırrın doğrulanmasını içerir, ancak OAuth 1 şifrelenmemiş bir bağlantı üzerinden çalışabildiğinden, her doğrulama sırrı kablo üzerinden geçiremez.

Bu, HMAC ile belirttiğiniz gibi yapılır. İstemci, yetkilendirme isteği için bağımsız değişkenleri imzalamak üzere sunucu ile paylaştığı sırrı kullanır. Sunucu, bağımsız değişkenleri alır, istemcinin anahtarıyla imzalar ve meşru bir istemci olup olmadığını görebilir (yukarıdaki 1. adımda).

Bu imza, hem istemcinin hem de sunucunun bağımsız değişkenlerin sırası üzerinde anlaşmasını gerektirir (bu nedenle tam olarak aynı dizeyi imzalarlar) ve OAuth 1 ile ilgili ana şikayetlerden biri hem sunucunun hem de istemcilerin sıralama ve aynı şekilde imzalayın. Bu fiddly kodu ve ya doğru ya 401 Unauthorizedda az yardım ile olsun . Bu, istemci yazma engeli artar.

OAuth 2.0, yetkilendirme isteğinin SSL üzerinden çalışmasını gerektirerek, bağımsız değişken sıralama ve imzalama gereksinimini tamamen ortadan kaldırır. İstemci sırrını doğrudan doğrulayan sunucuya iletir.

Aynı gereksinimler sunucu-> içerik sağlayıcısı bağlantısında da mevcuttur ve OAuth hizmetlerine erişen bir sunucu yazma önündeki bir engeli kaldıran SSL olduğu için.

Bu yukarıdaki 1, 2 ve 5. adımlarda işleri çok daha kolay hale getirir.

Bu noktada sunucumuz, kullanıcı için bir kullanıcı adı / parola eşdeğeri olan kalıcı bir erişim belirtecine sahiptir. Bu erişim belirtecini isteğin bir parçası olarak (sorgu bağımsız değişkeni, HTTP üstbilgisi veya POST form verileri olarak) geçirerek kullanıcı adına içerik sağlayıcısına istekte bulunabilir.

İçerik hizmetine yalnızca SSL üzerinden erişilirse işimiz bitti. Düz HTTP üzerinden kullanılabiliyorsa, bu kalıcı erişim belirtecini bir şekilde korumak istiyoruz. Bağlantıyı koklayan herkes, kullanıcının içeriğine sonsuza kadar erişebilir.

OAuth 2'de çözülen yol bir yenileme jetonudur . Yenileme belirteci kalıcı şifre eşdeğeri olur ve yalnızca SSL üzerinden iletilir . Sunucunun içerik hizmetine erişmesi gerektiğinde, yenileme belirtecini kısa ömürlü bir erişim belirteciyle değiştirir. Bu şekilde tüm koklanabilir HTTP erişimleri, süresi dolacak bir belirteçle yapılır. Google, OAuth 2 API'larında 5 dakikalık bir sona erme süresi kullanıyor.

Yenileme simgelerinin yanı sıra, OAuth 2 istemci, sunucu ve içerik sağlayıcısı arasındaki tüm iletişimi basitleştirir. Yenileme simgeleri yalnızca içeriğe şifrelenmeden erişildiğinde güvenlik sağlamak için bulunur.

İki aşamalı kimlik doğrulama

Ancak bazen bir sunucunun yalnızca kendi içeriğine erişimi denetlemesi gerekir. İki aşamalı kimlik doğrulama, istemcinin kullanıcıyı doğrudan sunucu ile doğrulamasını sağlar.

OAuth 2, yaygın olarak kullanılan bazı uzantıları OAuth 1'e standart hale getirir. En iyi bildiğim Twitter tarafından xAuth olarak tanıtıldı . OAuth 2'de Kaynak Sahibi Parolası Kimlik Bilgileri olarak görebilirsiniz .

Temel olarak, istemciye kullanıcının kimlik bilgileriyle (kullanıcı adı ve parola) güvenebilirseniz, bunları doğrudan bir erişim belirteci için içerik sağlayıcıyla değiştirebilirler. Bu, OAuth'u mobil uygulamalarda çok daha kullanışlı hale getirir - üç aşamalı kimlik doğrulamayla, içerik sunucusuyla yetkilendirme sürecini işlemek için bir HTTP görünümü yerleştirmeniz gerekir.

OAuth 1 ile bu, resmi standardın bir parçası değildi ve diğer tüm taleplerle aynı imzalama prosedürünü gerektiriyordu.

Kaynak Sahibi Parola Kimlik Bilgileri ile OAuth 2'nin sunucu tarafını yeni uyguladım ve bir müşterinin bakış açısından, erişim belirtecini almak basitleşti: sunucudan bir erişim belirteci isteyin, istemci kimliğini / sırrını bir HTTP Yetkilendirme başlığı ve form verisi olarak kullanıcının oturum açma adı / şifresi.

Avantajı: Sadelik

Dolayısıyla, uygulayıcının bakış açısından, OAuth 2'de gördüğüm temel avantajlar karmaşıklığın azalmasıdır. Tam olarak zor olmayan ama kesinlikle işe yarayan istek imzalama prosedürünü gerektirmez. Bir hizmetin müşterisi olarak hareket etmek için gereken işi büyük ölçüde azaltır (bu, modern, mobil dünyada) ağrıyı en aza indirmek istediğiniz yerdir. Sunucu-> içerik sağlayıcı sonundaki karmaşıklığın azalması veri merkezinde daha ölçeklenebilir olmasını sağlar.

Ve standart olarak şu anda geniş kullanımda olan OAuth 1.0a'nın bazı uzantılarını (xAuth gibi) kodlar.

İlk olarak, OAuth kimlik doğrulamasında açıkça belirtildiği gibi

OAuth 2.0 bir kimlik doğrulama protokolü değildir.

Bir uygulamaya erişen bir kullanıcı bağlamındaki kimlik doğrulama, bir uygulamaya geçerli kullanıcının kim olduğunu ve var olup olmadığını söyler. Tam bir kimlik doğrulama protokolü muhtemelen bu kullanıcı hakkında benzersiz bir tanımlayıcı, bir e-posta adresi ve uygulama "Günaydın" dediğinde ne arayacağınız gibi bir dizi özellik de söyleyecektir.

Ancak, OAuth uygulamaya bunların hiçbirini söylemez. OAuth, kullanıcı hakkında kesinlikle hiçbir şey söylemez ve kullanıcının varlığını nasıl kanıtladığını veya hala orada olsa bile söylemez. Bir OAuth istemcisi söz konusu olduğunda, bir jeton istedi, bir jeton aldı ve sonunda bu jetonu bazı API'lara erişmek için kullandı. Uygulamayı kimin yetkilendirdiği veya orada bir kullanıcı olup olmadığı hakkında hiçbir şey bilmiyor.

OAuth kullanarak kullanıcı kimlik doğrulaması için bir standart vardır: OAuth2 ile uyumlu OpenID Connect.

OpenID Bağlantı Kimliği Simgesi, istemci uygulamasına normal OAuth erişim belirtecinin yanı sıra verilen imzalı bir JSON Web Simgesidir (JWT). Kimlik Jetonu, kimlik doğrulama oturumu hakkında kullanıcı (alt) için bir tanımlayıcı, jetonu / sertifikaları yayınlayan kimlik sağlayıcısının tanımlayıcısı ve bu belirtecin oluşturulduğu istemcinin tanımlayıcısı ( AKB).

Go'da coreos / dex, OpenID Bağlantı Kimliği (OIDC) ve Takılabilir Konektörlü OAuth 2.0 Sağlayıcısı'na bakabilirsiniz.

Bu yazının yanıtı: vonc

Bu soruya biraz farklı bir şekilde cevap vereceğim ve çok kesin ve kısa olacağım, çünkü esas olarak @Peter T hepsini yanıtladı.

Bu standarttan gördüğüm ana kazanç iki ilkeye saygı duymaktır:

1. Endişelerin ayrılması.
2. Kimlik doğrulaması, genellikle iş yapan web uygulamasından ayrılır.

Böyle yaparak,

1. Tek Oturum Açma için bir alternatif uygulayabilirsiniz: Bir STS'ye güvenen birden fazla uygulamanız varsa. Demek istediğim, tüm uygulamalar için bir kullanıcı adı.
2. Web uygulamanızın (istemci) kullanıcıya ait olan ve web uygulamasına ait olmayan (İstemci) kaynaklara erişmesini sağlayabilirsiniz.
3. Kimlik doğrulama işlemini, güvendiğiniz bir üçüncü tarafa zorunlu kılabilir ve kullanıcı kimlik doğrulama doğrulaması konusunda asla endişelenemezsiniz.