OAuth 2, Güvenlik Simgesini kullanarak tekrar saldırıları gibi şeylere karşı nasıl koruma sağlar?

Anladığım kadarıyla, OAuth 2'de Kullanıcının bilgilerine Site-Aerişmek için aşağıdaki olaylar zinciri oluşur .Site-B

1. Site-Akaydolur Site-Bve bir Sır ve Kimlik alır.
2. Ne zaman Kullanıcı söyler Site-Aerişmek için Site-B, Kullanıcı gönderilir Site-Bonlar anlatmak nereye Site-Bonlar olur gerçekten gibi vermek için bu Site-Aözel bilgiler için izinleri.
3. Site-Byönlendirmelerin Kullanıcı geri Site-Abir Yetkilendirme Kanunu ile birlikte.
4. Site-Adaha sonra Site-BGüvenlik Kodu için Sırrı ile birlikte Yetkilendirme Kodunu geçirir .
5. Site-Adaha sonra Güvenlik Simgesini isteklerle birlikte paketleyerek KullanıcıSite-B adına istekte bulunur.

Tüm bunlar güvenlik ve şifreleme açısından üst düzeyde nasıl çalışır? OAuth 2, Güvenlik Simgesini kullanarak tekrar saldırıları gibi şeylere karşı nasıl koruma sağlar?

OAuth 2.0 gerçek hayatta nasıl çalışır:

Olaf'ın pastanesi tarafından pencerenin en lezzetli çörekini gördüğümde işe giderken sürüyordum - yani, şey çikolata iyiliği damlıyordu. Bu yüzden içeri girdim ve "O çörek olmalı!" Diye sordum. "Bunun 30 dolar olacağından emin" dedi.

Evet biliyorum, bir poğaça için 30 dolar! Lezzetli olmalı! Aniden şef "HAYIR! Sizin için hiçbir çörek" diye bağırdığını duyunca cüzdanım için ulaştım. Diye sordum: neden? Sadece banka havalelerini kabul ettiğini söyledi.

Ciddi anlamda? Evet, ciddiydi. Neredeyse orada yürüdüm, ama sonra çörek bana seslendi: "Ye beni, lezizim ...". Ben kim bir halka çörek emir itaat etmeyeceğim? Tamam dedim.

Bana üzerinde adı olan bir not verdi (şef değil, çörek): "Olaf'ın sana gönderdiğini söyle". Adı zaten nottaydı, bu yüzden bunun ne anlama geldiğini bilmiyorum, ama tamam.

Bankama bir buçuk saat sürdüm. Notu anlatan kişiye verdim; Ona Olaf'ın beni gönderdiğini söyledim. Bana "Ben okuyabiliyorum" diyen bu bakışlardan birini verdi.

Notumu aldı, kimliğimi istedi, bana ne kadar para verebileceğini sordu. Ona 30 dolar söyledim. Biraz karalama yaptı ve bana bir not daha verdi. Bunun üzerinde bir sürü rakam vardı, sanırım notları bu şekilde takip ediyorlar.

O noktada açlıktan ölüyorum. Oradan koştum, bir buçuk saat sonra geri döndüm, notum uzatılmış olarak Olaf'ın önünde durdum. Onu aldı, baktı ve "Geri döneceğim" dedi.

Donutumu aldığını sanıyordum, ama 30 dakika sonra şüphelenmeye başladım. Ben de tezgahın arkasındaki adama "Olaf nerede?" Diye sordum. "Para almaya gitti" dedi. "Ne demek istiyorsun?". "Bankaya not alıyor".

Hah ... Yani Olaf, bankanın bana verdiğini ve hesabımdan para almak için bankaya geri döndüğünü not etti. Bankanın bana verdiği notu aldığı için, banka onun bahsettiğim kişi olduğunu biliyordu ve banka ile konuştuğum için ona sadece 30 dolar vereceğini biliyorlardı.

Bunu anlamak uzun zaman almalıydı çünkü baktığımda Olaf nihayet bana donutumu teslim ederek önümde duruyordu . Ayrılmadan önce, "Olaf, hep bu şekilde çörek sattın mı?" Diye sormak zorunda kaldım. "Hayır, eskiden farklı yapardım."

Huh. Arabama geri dönerken telefonum çaldı. Cevap vermekten rahatsız olmadım, muhtemelen beni kovmak için işim buydu, patronum çok lanet olası. Ayrýca, az önce geçtiđim süreç hakkýnda düţünmüţtüm.

Demek istediğim: Olaf'ın hesap bilgilerimi vermek zorunda kalmadan Olaf'ın banka hesabımdan 30 dolar almasına izin verdim. Ve çok fazla para alacağından endişelenmem gerekmedi çünkü bankaya sadece 30 dolar almasına izin verildiğini söyledim. Ve banka onun doğru adam olduğunu biliyordu çünkü Olaf'a vermem için bana verdikleri notu almıştı.

Tamam, eminim ona cebimden 30 dolar vermeyi tercih ederim. Ama şimdi o bankaya her hafta 30 dolar almasına izin vermesini söyleyebildiğime göre, o zaman fırında görünebilirdim ve artık bankaya gitmek zorunda kalmadım. Hatta istersem telefonla çörek bile sipariş verebilirim.

Tabii ki bunu asla yapmam - o çörek iğrençti.

Bu yaklaşımın daha geniş uygulamalara sahip olup olmadığını merak ediyorum. Bunun ikinci yaklaşımı olduğunu söyledi, buna Olaf 2.0 diyebilirim. Her neyse eve dönsem iyi bir iş aramaya başlamalıyım. Ama bu çilek sarsıntılarından birini şehirdeki yeni yerden almadan önce, o çöreklerin tadını çıkarmak için bir şeye ihtiyacım yok.

Okuduğum şeye dayanarak, hepsi bu şekilde çalışır:

Soruda belirtilen genel akış doğrudur. 2. adımda, Kullanıcı X'in kimliği doğrulanır ve ayrıca Site A'nın Kullanıcı X'un Site B'deki bilgilerine erişimine izin verir. 4. adımda site, Kendisinin kimliğini ve Yetkilendirme Kodunu belirterek Site B'ye geri döner. (Kullanıcı X'in erişim belirteci) istiyor.

Genel olarak, OAuth 2 aslında çok basit bir güvenlik modelidir ve şifreleme asla doğrudan devreye girmez. Bunun yerine, hem Gizli hem de Güvenlik Simgesi esasen şifrelerdir ve her şey sadece https bağlantısının güvenliği ile güvence altına alınmıştır.

OAuth 2, Güvenlik Simgesinin veya Sırrının tekrar saldırılarına karşı hiçbir korumaya sahip değildir. Bunun yerine, tamamen Site B'nin bu öğelerden sorumlu olmasına ve bunların dışarı çıkmasına izin vermemesine ve geçiş sırasında https üzerinden gönderilmesine dayanır (https, URL parametrelerini koruyacaktır).

Yetkilendirme Kodu adımının amacı yalnızca kolaylık sağlamaktır ve Yetkilendirme Kodu kendi başına özellikle hassas değildir. Kullanıcı B'den Kullanıcı X'in erişim belirtecini sorarken, Kullanıcı X'un Site A için erişim belirteci için ortak bir tanımlayıcı sağlar. Yalnızca Kullanıcı X'un Site B'deki kullanıcı kimliği işe yaramazdı, çünkü aynı anda farklı sitelere dağıtılmayı bekleyen birçok olağanüstü erişim jetonu olabilir.

OAuth, 3 taraflı bir uygulamanın, hesabınız ve şifreniz olmadan başka bir web sitesinde depolanan verilerinize erişebileceği bir protokoldür. Daha resmi bir tanım için Wiki'ye veya spesifikasyona bakın.

İşte bir kullanım örneği demosu:

1. LinkedIn'e giriş yapıyorum ve Gmail kişilerimdeki bazı arkadaşlarımı bağlamak istiyorum. LinkedIn bunu destekliyor. Gmail'den güvenli bir kaynak (gmail kişi listem) isteyecektir. Bu düğmeyi tıklıyorum:
   

2. Bir web sayfası açılır ve hesabımı ve şifremi girdiğimde Gmail giriş sayfasını gösterir:
   

3. Gmail daha sonra "Kabul Et" i tıkladığım bir onay sayfası gösterir:

4. Artık LinkedIn Gmail'deki kişilerime erişebilir:

Aşağıda, yukarıdaki örneğin bir akış şeması bulunmaktadır:

1. Adım: LinkedIn, Gmail'in Yetkilendirme Sunucusundan bir simge ister.

2. Adım: Gmail yetkilendirme sunucusu kaynak sahibinin kimliğini doğrular ve kullanıcıya onay sayfasını gösterir. (kullanıcının henüz giriş yapmadıysa Gmail’e giriş yapması gerekir)

3. Adım: Kullanıcı LinkedIn'in Gmail verilerine erişmesi için istekte bulunur.

4. Adım: Gmail yetkilendirme sunucusu bir erişim belirteciyle yanıt verir.

5. Adım: LinkedIn, bu erişim belirteciyle Gmail API'sını çağırır.

6. Adım: Erişim belirteci geçerliyse Gmail kaynak sunucusu kişilerinizi döndürür. (Simge Gmail kaynak sunucusu tarafından doğrulanacaktır)

OAuth hakkında daha fazla bilgiyi buradan edinebilirsiniz .

Şekil 1, RFC6750'den kaldırılmıştır :

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

Bu makalede iyi anlatılan Oauth 2.0 böyle çalışır

Bu bir mücevher:

https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

Çok kısa özet:

OAuth dört rol tanımlar:

1. Kaynak Sahibi
2. müşteri
3. Kaynak Sunucu
4. Yetkilendirme Sunucusu

Sizin (Kaynak Sahibi) cep telefonunuz var. Birkaç farklı e-posta hesabınız var, ancak tüm e-posta hesaplarınızı tek bir uygulamada istiyorsunuz, bu nedenle geçiş yapmaya devam etmenize gerek yok. Böylece GMail'iniz (İstemci) Yahoo e-postalarınıza (Kaynak Sunucusu) erişmek (Yahoo'nun Yetkilendirme Sunucusu aracılığıyla) ister, böylece GMail uygulamanızdaki her iki e-postayı da okuyabilirsiniz.

OAuth'un var olmasının nedeni, GMail'in Yahoo kullanıcı adınızı ve şifrenizi saklamasının güvenli olmamasıdır.

Diğer cevap çok ayrıntılı ve OP tarafından sorulan soruların çoğunu ele alıyor.

Ayrıntılı olarak ve özellikle OP'nin "OAuth 2, Güvenlik Simgesini kullanarak tekrar saldırıları gibi şeylere karşı nasıl koruyor?" Sorusunu ele almak için, OAuth 2'yi uygulamak için resmi önerilerde iki ek koruma vardır :

1) Jetonların genellikle kısa bir sona erme süresi olacaktır ( http://tools.ietf.org/html/rfc6819#section-5.1.5.3 ):

Jetonlar için kısa bir sona erme süresi, aşağıdaki tehditlere karşı korunmanın bir yoludur:

• tekrar ...

2) Simge A Sitesi tarafından kullanıldığında, öneri URL parametreleri olarak değil, Yetkilendirme isteği başlığı alanında ( http://tools.ietf.org/html/rfc6750 ) sunulması önerisidir :

İstemciler, "Yetkilendirme" istek üstbilgisi alanını "Taşıyıcı" HTTP yetkilendirme şemasına sahip bir taşıyıcı simgesiyle kimlik doğrulamalı istekler YAPMALIDIR. ...

"Application / x-www-form-urlencoded" yöntemi, katılımcı tarayıcıların "Yetkilendirme" istek üstbilgisi alanına erişemediği uygulama bağlamları dışında KULLANILMAMALIDIR. ...

Mevcut kullanımı belgelemek için URI Sorgu Parametresi ... dahil edilmiştir; güvenlik eksiklikleri nedeniyle kullanılması önerilmez

Belki de OAuth2'nin 4 hibe türü için nasıl çalıştığının en basit açıklaması, yani uygulamanın erişim belirtecini alabileceği 4 farklı akış.

Benzerlik

Tüm hibe türü akışların 2 bölümü vardır:

• Erişim izni almak
• Erişim belirtecini kullan

2. bölüm 'erişim belirtecini kullan' tüm akışlar için aynıdır

fark

Akışın birinci kısmı, her bir hibe türü için 'erişim belirteci al' değişir.

Bununla birlikte, genel olarak 'erişim belirteci al' kısmı 5 adımdan oluşan olarak özetlenebilir:

1. İstemci kimliği / sırrı almak için uygulamanızı (istemcinizi) OAuth sağlayıcısına (ör. Twitter vb.) Önceden kaydedin.
2. Tıklanan kullanıcı kimlik doğrulaması için OAuth sağlayıcısına yönlendirildiğinde müşteri kimliğini ve sayfanızda gerekli kapsamları / izinleri içeren bir sosyal giriş düğmesi oluşturun
3. OAuth sağlayıcısı kullanıcıdan uygulamanıza (istemci) izin vermesini ister
4. OAuth sağlayıcı sorunları kodu
5. Uygulama (istemci) erişim belirteci aldı

Burada, her bir hibe türü akışının 5 adıma göre nasıl farklı olduğunu karşılaştıran yan yana bir diyagram verilmiştir.

Bu diyagram https://blog.oauth.io/introduction-oauth2-flow-diagrams/ adresinden alınmıştır.

Her biri farklı uygulama zorlukları, güvenlik ve kullanım durumlarına sahiptir. İhtiyaçlarınıza ve durumunuza bağlı olarak, bunlardan birini kullanmanız gerekecektir. Hangisi kullanılır?

Müşteri Kimlik Bilgileri : Uygulamanız yalnızca tek bir kullanıcıya hizmet veriyorsa

Kaynak Sahibi Parolası Kimlik Bilgisi : Bu, kullanıcının kimlik bilgilerini uygulamaya vermek zorunda olduğu için yalnızca son çare olarak kullanılmalıdır; bu, uygulamanın kullanıcının yapabileceği her şeyi yapabileceği anlamına gelir

Yetkilendirme Kodu : Kullanıcı yetkisi almanın en iyi yolu

Örtük : Uygulamanız mobil veya tek sayfalı bir uygulama ise

Burada daha fazla açıklama var: https://blog.oauth.io/choose-oauth2-flow-grant-types-for-app/