OAuth 2.0'da birden çok iş akışı vardır. İkisiyle ilgili birkaç sorum var.

1. Yetkilendirme kodu akışı - Kullanıcı istemci uygulamasından oturum açar, yetkilendirme sunucusu uygulamaya bir yetkilendirme kodu döndürür. Uygulama daha sonra yetkilendirme kodunu erişim belirteci ile değiştirir.
2. Örtülü hibe akışı - Kullanıcı istemci uygulamasından oturum açar, yetkilendirme sunucusu doğrudan istemci uygulamasına erişim belirteci verir.

Güvenlik açısından iki yaklaşım arasındaki fark nedir? Hangisi daha güvenli ve neden?

Sunucu doğrudan bir Access belirteci verebilir zaman bir iş akışında fazladan bir adım (belirteç için yetkilendirme kodu) eklendi neden görmüyorum.

Farklı web siteleri, istemci uygulaması kimlik bilgilerini güvenli tutabildiğinde Yetkilendirme kodu akışının kullanıldığını söylüyor. Neden?

access_tokenBir korumalı kaynak (API) aramak için ihtiyaç vardır. Yetkilendirme Kodu akışında bunu elde etmek için 2 adım vardır:

1. Kullanıcının kimlik doğrulaması codeyapması ve bir API tüketicisine ("İstemci" adı verilir) geri göndermesi gerekir.
2. API'nın "istemcisi" (genellikle web sunucunuz) code, # 1'de elde access_tokenedileni bir client_idveclient_secret
3. Daha sonra API ile access_token.

Dolayısıyla, bir çift kontrol vardır: bir API üzerinden ortaya çıkan kaynaklara sahip olan kullanıcı ve API'yı kullanarak istemci (örn. Bir web uygulaması). Her ikisi de erişim için onaylanmıştır. Burada OAuth'un "yetkilendirme" niteliğine dikkat edin: kullanıcı kaynağına ( codekimlik doğrulamasından sonra döndürülen yoluyla ) bir uygulamaya erişim izni verir , uygulama bir olur access_tokenve kullanıcının adına çağrı yapar.

Örtük akışta, 2. adım atlanmıştır. Böylece, kullanıcı kimlik doğrulamasından sonra access_token, kaynağa erişmek için kullanabileceğiniz bir doğrudan döndürülür. API, bu API'yı kimin aradığını bilmiyor. access_tokenÖnceki örnekte sadece web uygulaması (herkesin normalde erişemeyeceği) olurken, kutuya sahip olan herkes olabilir.

Örtük akış genellikle depolamanın client idve client secretönerilmediği senaryolarda kullanılır (örneğin, birçoğu yine de bir cihaz olsa da). Feragatnamenin anlamı budur. İnsanlar istemci koduna erişebilir ve bu nedenle kimlik bilgilerini alabilir ve kaynak istemcisi gibi davranabilir. Örtük akışta tüm veriler oynaktır ve uygulamada depolanan hiçbir şey yoktur.

Buraya yukarıdaki cevaplarda netleştirilmediğini düşünmediğim bir şey ekleyeceğim:

• Yetkilendirme-Kod-Akışı, son erişim belirtecinin tarayıcıya / uygulamayla makineye asla ulaşmamasına ve asla saklanmamasına olanak tanır . Geçici yetkilendirme kodu tarayıcıya / uygulamayla makineye verilir ve daha sonra bir sunucuya gönderilir. Sunucu daha sonra tam erişim belirteciyle değiş tokuş yapabilir ve API'lere vb. Erişebilir. Tarayıcıya sahip kullanıcı API'ya yalnızca belirteçli sunucu üzerinden erişebilir.
• Örtük akış yalnızca iki tarafı içerebilir ve son erişim belirteci istemcide tarayıcı / uygulama ile depolanır. Bu tarayıcı / uygulama tehlikeye girerse tehlikeli olabilecek kimlik doğrulama simgeleri de öyle.

tl; dr tutulmakta jeton kullanıcıların makineyi güvenmiyorsan örtülü akışını kullanmayın ama bunu kendi sunucularını güven.

Her ikisi arasındaki fark şudur:

1. Örtük akışta, jeton doğrudan "#" işaretli yönlendirme URL'si aracılığıyla döndürülür ve bu çoğunlukla javascript istemcilerinde veya kendi başına sunucu tarafı olmayan mobil uygulamalarda kullanılır ve istemcinin bazı uygulamalarda sırrını sağlaması gerekmez .

2. Yetkilendirme kodu akışında, kod "?" sunucu tarafı tarafından okunabilir olması için sunucu tarafı, bu kez yetkilendirme sunucusundan json nesnesi olarak jeton almak için URL'yi belirtmek için istemci sırrı sağlamak zorundadır. Bunu yapabilen ve kullanıcı belirteci ile birlikte kendi belirteçini kendi sisteminde saklayabilen ve çoğunlukla yaygın mobil uygulamalar için kullanılabilecek uygulama sunucunuz olması durumunda kullanılır.

bu yüzden istemci uygulamanızın doğasına bağlıdır, bir daha güvenli "Yetkilendirme kodu" istemcide sır istemektedir ve belirteç, çok güvenli bir bağlantıda yetkilendirme sunucusu ile istemci uygulaması arasında gönderilebilir ve yetkilendirme sağlayıcısı bazı istemcileri yalnızca "Yetkilendirme kodu" kullanacak şekilde kısıtla ve Örtük'e izin verme

Örtük hibe, iki farklı farkla yetki kodu hibe ödenmesine benzer.

Tüm uygulama kodu ve depolamaya kolayca erişilebildiğinden, istemciyi gizli tutamayan kullanıcı aracısı tabanlı istemciler (örn. Tek sayfa web uygulamaları) için tasarlanmıştır.

İkinci olarak, erişim belirteci ile değiştirilen bir yetkilendirme kodu döndüren yetkilendirme sunucusu yerine, yetkilendirme sunucusu bir erişim belirteci döndürür.

Lütfen ayrıntıları burada bulabilirsiniz http://oauth2.thephpleague.com/authorization-server/which-grant/

Örtük akış

Avantajları

• Uygulanması en kolay

Dezavantajları

• Tarayıcıya görünen erişim belirteçleri
• Erişim belirteçlerinin kaynağı belirlenemiyor
• Erişim belirteçlerinin süresi doldurulamıyor (Google politikasıyla)

Yetkilendirme kodu akışı

Avantajları

• En güvenli
• Erişim belirteçleri ve yenileme belirteçleri yalnızca paylaşılan bir sır biliniyorsa oluşturulabilir
• Kullanılabilir olduklarında yeni güvenlik ve UX özellikleri ile geliştirilebilir

Dezavantajları

• Birden fazla kimlik doğrulaması uç noktası uygulanmalıdır

Alıntı: https://developers.google.com/actions/develop/identity/oauth2-overview#supported_oauth_20_flows

Yukarıdaki cevaplardan öğrendiğim noktaları özetleyeyim ve kendi anlayışlarımdan bazılarını ekleyeyim.

Yetkilendirme Kodu Akışı !!!

• OAuth istemcisi gibi davranan bir web uygulama sunucunuz varsa
• Uzun süreli erişim sağlamak istiyorsanız
• Verilere çevrimdışı erişime sahip olmak istiyorsanız
• uygulamanızın yaptığı API çağrılarından sorumlu olduğunuzda
• OAuth jetonunuzu sızdırmak istemiyorsanız
• Uygulamanızın verilere her erişmesi gerektiğinde yetkilendirme akışından geçmesini istemiyorsanız. NOT: Örtülü Hibe akışı, yenileme belirtecini eğlendirmez; bu nedenle, yetkilendirme sunucusunun erişim belirteçlerini düzenli olarak süresi dolarsa, uygulamanızın erişmesi gerektiğinde yetkilendirme akışından geçmesi gerekir.

Örtülü Hibe Akışı !!!

• OAuth İstemcisi olarak hareket edecek Web Uygulama Sunucunuz olmadığında
• Uzun süreli erişime ihtiyacınız yoksa, yalnızca verilere geçici erişim gerekir.
• Uygulamanızın çalıştığı tarayıcıya güveniyorsanız ve erişim belirtecinin güvenilmeyen kullanıcılara sızacağından endişe duyuyorsanız.

Hangisi daha güvenli ve neden?

Her ikisi de güvenlidir, kullandığınız ortama bağlıdır.

Sunucu doğrudan bir Access belirteci verebilir zaman bir iş akışında fazladan bir adım (belirteç için yetkilendirme kodu) eklendi neden görmüyorum.

Basit. Müşteriniz güvenli değil. Ayrıntılara bakalım.

Karşı bir uygulama geliştirdiğinizi düşünün Instagram API, böylece APP ile kayıt Instagramve API'sihtiyacınız olanı tanımlayın . Instagramsana sağlayacak client_idveclient_secrect

Web sitenizde yazan bir bağlantı oluşturursunuz. "Gel ve Uygulamamı Kullan". Buna tıklayarak web uygulamanız iki arama yapmalıdır Instagram API.

FirstInstagram Authentication ServerAşağıdaki parametrelerle bir istek gönderin .

1. `response_type` with the value `code`
2. `client_id` you have get from `Instagram`
3. `redirect_uri` this is a url on your server which do the second call
4. `scope` a space delimited list of scopes
5. `state` with a CSRF token. 

Göndermezsinizclient_secret , istemciye güvenemezsiniz (Uygulamayı kullanmaya çalışan kullanıcı veya tarayıcısı). İstemci url veya java betiğini görebilir ve client_secrectkolayca bulabilir . Bu yüzden başka bir adıma ihtiyacın var.

Bir codeve alırsınız state. codeBurada temporaryherhangi bir yerde kaydedilmez.

O zaman bir hale secondçağrısına Instagram API(sunucunuzdan)

 1. `grant_type` with the value of `authorization_code`
 2. `client_id` with the client identifier
 3. `client_secret` with the client secret
 4. `redirect_uri` with the same redirect URI the user was redirect back to
 5. `code` which we have already received.

Arama sunucumuzdan yapıldığından , kullanıcının kaynağı kullanmak için verdiği izni güvenli bir şekilde kullanabiliriz client_secret(bu nasıl olduğumuzu gösterir) .codeclient_id

Yanıt olarak sahip olacağız access_token

Pratik bakış açısından (Anladım), Authz kod akışına sahip olmanın ana nedeni:

1. Yenileme jetonları için destek (Kullanıcı adına uygulamalar tarafından uzun süreli erişim), örtük olarak desteklenmez: bakın: https://tools.ietf.org/html/rfc6749#section-4.2
2. Kaynak Sahibinin hangi erişimi sağlayacağını denetleyebildiği onay sayfası desteği (Google'da gördüğünüz izinler / yetkilendirme sayfası). Aynı şey örtük olarak yok. Bkz. Bölüm: https://tools.ietf.org/html/rfc6749#section-4.1 , nokta (B)

"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"

Bunun yanı sıra, Yenileme belirteçlerini kullanarak Uygulamalar kullanıcı verilerine uzun süreli erişim sağlayabilir.

Şu ana kadar tartışılmayan, Yetkilendirme Kodu Hibe Türü'nün yol açmasının neden güvenlik eklediğini açıklayan iki kilit nokta var gibi görünüyor.

Kısa öykü : Yetkilendirme Kodu Verme Türü, tarayıcı geçmişinden hassas bilgileri tutar ve belirtecin iletilmesi, yalnızca yetkilendirme sunucusunun HTTPS korumasına bağlıdır.

Daha uzun versiyon:

Aşağıda, RFC'de tanımlanmış OAuth 2 terminolojisine sadık kalacağım (hızlı bir okuma): kaynak sunucu , istemci , yetkilendirme sunucusu , kaynak sahibi .

Bazı üçüncü taraf uygulamalarının (= istemci) Google hesabınızın (= kaynak sunucusu) belirli verilerine erişmesini istediğinizi düşünün. Google'ın OAuth 2 kullandığını varsayalım. Google hesabının kaynak sahibisiniz, ancak şu anda üçüncü taraf uygulamasını çalıştırıyorsunuz.

İlk olarak, istemci sizi Google yetkilendirme sunucusunun güvenli URL'sine göndermek için bir tarayıcı açar. Daha sonra erişim isteğini onaylarsınız ve yetkilendirme sunucusu sizi istemcinin önceden verilen yönlendirme URL'sine, sorgu dizesinde yetkilendirme kodu ile geri gönderir. Şimdi iki önemli nokta için:

1. Bu yönlendirmenin URL'si tarayıcı geçmişinde bulunur . Bu yüzden burada uzun ömürlü, doğrudan kullanılabilir bir erişim jetonu istemiyoruz. Kısa ömürlü yetki kodu tarihte daha az tehlikelidir. Örtülü Grant tipin Not gelmez tarihinin simge koydu.
2. Bu yönlendirmenin güvenliği , Google'ın sertifikasına değil istemcinin HTTPS sertifikasına bağlıdır . Bu nedenle, istemcinin iletim güvenliğini ekstra bir saldırı vektörü olarak alıyoruz (Bunun kaçınılmaz olması için, istemcinin JavaScript olmaması gerekir. Aksi takdirde, yetkilendirme kodunu, kodun ağ üzerinden geçmeyeceği parça URL'si aracılığıyla iletebiliriz. Bu nedeni olabilir neden Örtülü Grant Tipi, yapar , böylece artık olsa bile, JavaScript müşterileri için tavsiye edilebilir için kullanılan bir parçası URL'sini kullanın.)

Yetkilendirme Kodu Verme Türü ile, belirteç nihayet istemciden yetkilendirme sunucusuna yapılan bir çağrı ile elde edilir; burada iletim güvenliği istemciye değil, yalnızca yetkilendirme sunucusuna bağlıdır .