Bir mobil uygulama için doğru OAuth 2.0 akışı nedir

OAuth 2.0 kullanan mobil uygulamalar için bir Web API'sinde temsilci yetkilendirme uygulamaya çalışıyorum. Spesifikasyona göre, örtük izin akışı yenileme belirteçlerini desteklemez; bu, belirli bir süre için bir erişim belirteci verildiğinde, kullanıcının, jetonun süresi dolduğunda veya jeton iptal edildiğinde uygulamaya tekrar izinler vermesi gerektiği anlamına gelir.

Sanırım bu, şartnamede belirtildiği gibi bir tarayıcıda çalışan bazı javascript kodları için iyi bir senaryo. Kullanıcının bir belirteç almak için uygulamaya izin vermesi gereken süreleri en aza indirmeye çalışıyorum, bu nedenle Yetkilendirme Kodu akışı, yenileme belirteçlerini desteklediği için iyi bir seçenek gibi görünüyor.

Bununla birlikte, bu akış, yönlendirmeleri gerçekleştirmek için büyük ölçüde bir web tarayıcısına bağlı görünmektedir. Gömülü bir web tarayıcısı kullanılıyorsa, bu akışın bir mobil uygulama için hala iyi bir seçenek olup olmadığını merak ediyorum. Yoksa örtük akışla mı gitmeliyim?

Açıklama: Mobil Uygulama = Yerel Uygulama

Diğer yorumlarda ve çevrimiçi birkaç kaynakta belirtildiği gibi, örtük, mobil uygulamalar için doğal bir uygunluk gibi görünmektedir, ancak en iyi çözüm her zaman kesin değildir (ve aslında aşağıda tartışılan nedenlerden dolayı dolaylı olarak önerilmemektedir).

Yerel Uygulama OAuth2 En İyi Uygulamaları

Hangi yaklaşımı seçerseniz seçin (dikkate alınması gereken birkaç değiş tokuş vardır), OAuth2 kullanan Yerel Uygulamalar için burada özetlenen en iyi uygulamalara dikkat etmelisiniz: https://tools.ietf.org/html/rfc8252

Aşağıdaki seçenekleri düşünün

Örtük

Örtük kullanmalı mıyım?

Bölüm 8.2'den alıntı yapmak için https://tools.ietf.org/html/rfc8252#section-8.2

OAuth 2.0 örtük izin yetkilendirme akışı (OAuth 2.0 [RFC6749] Bölüm 4.2'de tanımlanmıştır) genellikle tarayıcıda yetkilendirme isteğini gerçekleştirme ve yetkilendirme yanıtını URI tabanlı uygulamalar arası iletişim yoluyla alma uygulamasıyla çalışır.
Ancak, örtülü akış PKCE [RFC7636] tarafından korunamadığından (Bölüm 8.1'de gereklidir), Örtük Akışın yerel uygulamalarla kullanılması ÖNERİLMEZ .

Örtülü akış yoluyla verilen erişim belirteçleri, kullanıcı etkileşimi olmadan da yenilenemez, bu da yetkilendirme kodu verme akışını (yenileme belirteçleri verebilir), erişim belirteçlerinin yenilenmesini gerektiren yerel uygulama yetkilendirmeleri için daha pratik bir seçenek haline getirir.

Yetki Kodu

Yetkilendirme Kodu ile devam ederseniz, bir yaklaşım, cihazlardaki dağıtılmış uygulamada saklamaktan kaçınmak için belirteç isteklerini istemci sırrı ile zenginleştiren kendi web sunucusu bileşeniniz aracılığıyla proxy yapmak olacaktır.

Aşağıdaki alıntı: https://dev.fitbit.com/docs/oauth2/

Yetkilendirme Kodu Verme akışı, web hizmeti olan uygulamalar için önerilir. Bu akış, bir uygulamanın istemci sırrı kullanılarak sunucudan sunucuya iletişim gerektirir.

Not: İstemci sırrınızı asla bir uygulama mağazası veya istemci tarafı JavaScript aracılığıyla indirilen uygulamalar gibi dağıtılmış koda koymayın.

Web hizmeti olmayan uygulamalar Örtük Hibe akışını kullanmalıdır.

Sonuç

Nihai karar, istediğiniz kullanıcı deneyimini hesaba katmalı, aynı zamanda kısa listeye alınmış yaklaşımlarınız için uygun bir risk değerlendirmesi yaptıktan ve sonuçları daha iyi anladıktan sonra risk iştahınızı da hesaba katmalıdır.

Harika bir okuma burada https://auth0.com/blog/oauth-2-best-practices-for-native-apps/

Başka bir tanesidir https://www.oauth.com/oauth2-servers/oauth-native-apps/ olan durumları

Sektördeki mevcut en iyi uygulama, istemci sırrını çıkarırken Yetkilendirme Akışını kullanmak ve akışı tamamlamak için harici bir kullanıcı aracısı kullanmaktır. Harici bir kullanıcı aracısı, tipik olarak cihazın yerel tarayıcısıdır (yerel uygulamadan ayrı bir güvenlik alanıyla), böylece uygulama çerez deposuna erişemez veya tarayıcı içindeki sayfa içeriğini inceleyemez veya değiştiremez.

PKCE Değerlendirmesi

Burada açıklanan PKCE'yi de dikkate almalısınız. https://www.oauth.com/oauth2-servers/pkce/

Özellikle, Yetkilendirme Sunucusunu da uyguluyorsanız, https://www.oauth.com/oauth2-servers/oauth-native-apps/checklist-server-support-native-apps/ şunları yapmanız gerektiğini belirtir

• İstemcilerin, yönlendirme URL'leri için özel URL şemaları kaydetmelerine izin verin.
• Masaüstü uygulamalarını desteklemek için, rastgele bağlantı noktası numaralarına sahip geri döngü IP yönlendirme URL'lerini destekleyin.
• Yerel uygulamaların bir sır saklayabileceğini varsaymayın. Tüm uygulamaların herkese açık mı yoksa gizli mi olduğunu beyan etmesini ve yalnızca gizli uygulamalar için istemci sırlarını yayınlamasını zorunlu kılın.
• PKCE uzantısını destekleyin ve genel istemcilerin kullanmasını gerektirir.
• Yetkilendirme arayüzünün bir sistem tarayıcısında başlatmak yerine yerel bir uygulamanın web görünümüne ne zaman yerleştirildiğini tespit etmeye çalışın ve bu istekleri reddedin.

Web Görünümlerinde Dikkat Edilmesi Gerekenler

Vahşi ortamda Web Görünümleri, yani gömülü bir kullanıcı aracısı kullanan birçok örnek vardır, ancak bu yaklaşımdan kaçınılmalıdır (özellikle uygulama birinci taraf olmadığında) ve bazı durumlarda alıntı olarak bir API kullanmanız yasaklanabilir. buradan aşağıda gösteriyor

OAuth 2.0 kimlik doğrulama sayfasını yerleştirmeye yönelik herhangi bir girişim, uygulamanızın Fitbit API'sinden yasaklanmasıyla sonuçlanacaktır.

Güvenlik değerlendirmesi için, OAuth 2.0 yetkilendirme sayfası özel bir tarayıcı görünümünde sunulmalıdır. Fitbit kullanıcıları, yalnızca tarayıcı tarafından sağlanan URL çubuğu ve Taşıma Katmanı Güvenliği (TLS) sertifika bilgileri gibi araçlara sahiplerse orijinal Fitbit.com sitesi ile kimlik doğruladıklarını onaylayabilirler.

Yerel uygulamalar için bu, yetkilendirme sayfasının varsayılan tarayıcıda açılması gerektiği anlamına gelir. Yerel uygulamalar, kullanıcıyı yeniden tarayıcıdan izin isteyen uygulamaya yeniden yönlendirmek için yönlendirme URI'leri olarak özel URL şemalarını kullanabilir.

iOS uygulamaları, Safari'ye uygulama geçişi yerine SFSafariViewController sınıfını kullanabilir. WKWebView veya UIWebView sınıfının kullanılması yasaktır.

Android uygulamaları, uygulamanın varsayılan tarayıcıya geçişi yerine Chrome Özel Sekmelerini kullanabilir. WebView kullanımı yasaktır.

Daha fazla açıklığa kavuşturmak için, yukarıda sağlanan en iyi uygulama bağlantısının önceki taslağının bu bölümünden bir alıntı aşağıda verilmiştir

Genellikle web görünümleriyle uygulanan gömülü kullanıcı aracıları, yerel uygulamaları yetkilendirmek için alternatif bir yöntemdir. Bununla birlikte, tanım gereği üçüncü şahıslar tarafından kullanılmaları güvenli değildir. Kullanıcıların tam oturum açma kimlik bilgileriyle oturum açmasını, yalnızca daha az güçlü OAuth kimlik bilgilerine indirgemelerini içerir.

Güvenilir birinci taraf uygulamalar tarafından kullanıldığında bile, gömülü kullanıcı aracıları ihtiyaç duyduklarından daha güçlü kimlik bilgileri elde ederek en az ayrıcalık ilkesini ihlal eder ve potansiyel olarak saldırı yüzeyini artırır.

Gömülü kullanıcı aracılarının tipik web görünümü tabanlı uygulamalarında, ana bilgisayar uygulaması: kullanıcı adlarını ve parolaları yakalamak için forma girilen her tuş vuruşunu günlüğe kaydedebilir; formları otomatik olarak gönderin ve kullanıcı onayını atlayın; oturum tanımlama bilgilerini kopyalayın ve kullanıcı olarak kimliği doğrulanmış eylemler gerçekleştirmek için kullanın.

Kullanıcıları, normal adres çubuğu ve tarayıcıların sahip olduğu diğer kimlik özellikleri olmadan gömülü bir web görünümüne kimlik bilgilerini girmeye teşvik etmek, kullanıcının meşru sitede oturum açıp açmadığını bilmesini imkansız hale getirir ve oturum açsalar bile onları eğitir. önce siteyi doğrulamadan kimlik bilgilerini girmenin sorun olmadığı.

Güvenlik endişelerinin yanı sıra, web görünümleri kimlik doğrulama durumunu diğer uygulamalarla veya sistem tarayıcısıyla paylaşmaz, kullanıcının her yetkilendirme isteği için oturum açmasını gerektirir ve kötü bir kullanıcı deneyimine yol açar.

Yukarıdakilerden dolayı, güvenilir bir birinci taraf uygulamasının diğer uygulamalar için harici kullanıcı aracısı görevi görmesi veya birden çok birinci taraf uygulaması için tek oturum açma sağlaması dışında, gömülü kullanıcı aracılarının kullanılması ÖNERİLMEZ.

Yetkilendirme sunucuları, mümkün olduğunda kendilerine ait olmayan gömülü kullanıcı aracıları aracılığıyla oturum açma işlemlerini algılamak ve engellemek için adımlar atmayı düşünmelidir.

Burada bazı ilginç noktalar da dile getirilmiştir: /security/179756/why-are-developers-using-embedded-user-agents-for-3rd-party-auth-what-are-the- a

Maalesef bu sorunun net bir cevabı olduğunu sanmıyorum. Ancak, belirlediğim seçenekler şunlardır:

• Kullanıcıdan kimlik bilgilerini istemekte bir sakınca yoksa, Kaynak Sahibi Parola Kimlik Bilgilerini kullanın . Ancak bu bazı nedenlerden dolayı mümkün olmayabilir, yani

  • Kullanılabilirlik veya güvenlik politikaları, şifrenin doğrudan uygulamaya eklenmesini yasaklar
  • Kimlik doğrulama süreci, harici bir Kimlik Sağlayıcıda yetkilendirilir ve HTTP yeniden yönlendirme tabanlı bir akış (ör. OpenID, SAMLP veya WS-Federation) aracılığıyla gerçekleştirilmelidir.

• Tarayıcı tabanlı bir akış kullanılması gerekiyorsa, Yetkilendirme Kodu Akışını kullanın . Burada, redirect_uriaşağıdaki seçeneklerin bulunduğu büyük bir sorundur:

  • Https://developers.google.com/accounts/docs/OAuth2InstalledApp adresinde açıklanan tekniği kullanın; burada özel bir redirect_uri(ör. urn:ietf:wg:oauth:2.0:oob), İstemci uygulamasına yeniden yönlendirmek yerine yetkilendirme kodunu göstermek için yetkilendirme uç noktasını işaret eder. Kullanıcı bu kodu manuel olarak kopyalayabilir veya uygulama bunu HTML belge başlığından almayı deneyebilir.
  • localhostCihazda bir sunucu kullanın (bağlantı noktası yönetimi kolay olmayabilir).
  • myapp://...Başvurusu yapıldığında kayıtlı bir "işleyiciyi" tetikleyen özel bir URI şeması kullanın (örneğin ) (ayrıntılar mobil platforma bağlıdır).
  • Varsa , HTTP yeniden yönlendirme yanıtlarını kontrol etmek ve bunlara erişmek için Windows 8'de WebAuthenticationBroker gibi özel bir "web görünümü" kullanın .

Bu yardımcı olur umarım

Pedro

TL; DR: PKCE ile Yetkilendirme Kodu Verme Kullanın

1. Örtülü Hibe Türü

Örtük hibe türü, mobil uygulamalar arasında oldukça popülerdir. Ancak bu şekilde kullanılması amaçlanmadı. Yönlendirmeyle ilgili güvenlik endişeleri var. Justin Richer şöyle der :

Sorun, uzak sunucu URL'sinden farklı olarak, belirli bir yeniden yönlendirme URI'si ile belirli bir mobil uygulama arasındaki bağın sağlandığından emin olmanın güvenilir bir yolu olmadığını fark ettiğinizde ortaya çıkar. Cihazdaki herhangi bir uygulama kendisini yeniden yönlendirme sürecine eklemeyi deneyebilir ve yeniden yönlendirme URI'sini sunmasına neden olabilir. Ve tahmin edin ne oldu: yerel uygulamanızda örtük akışı kullandıysanız, saldırgana erişim jetonunuzu vermiş olursunuz. O noktadan sonra herhangi bir iyileşme yok - jetona sahipler ve onu kullanabilirler.

Ve erişim jetonunu yenilemenize izin vermediği gerçeğiyle birlikte, bundan kaçınmak daha iyidir.

2. Yetki Kodu Verme Tipi

Yetkilendirme kodu izni bir istemci sırrı gerektirir. Ancak hassas bilgileri mobil uygulamanızın kaynak kodunda saklamamalısınız. İnsanlar onları çıkarabilir. İstemci sırrını ifşa etmemek için, Facebook'un yazdığı gibi bir aracı olarak bir sunucu çalıştırmanız gerekir :

En iyi güvenliği sağlamak için Uygulama Erişim Belirteçlerinin yalnızca doğrudan uygulamanızın sunucularından kullanılmasını öneririz. Yerel uygulamalar için, uygulamanın kendi sunucunuzla iletişim kurmasını ve ardından sunucunun App Access Token'ı kullanarak Facebook'a API talepleri yapmasını öneririz.

İdeal bir çözüm değil, ancak mobil cihazlarda OAuth yapmanın yeni ve daha iyi bir yolu var: Kod Değişimi için Kanıt Anahtarı

3. Yetkilendirme Kodu Yetki Türü PKCE ile (Kod Değişimi için Kanıt Anahtarı)

Sınırlamaların dışında, Yetkilendirme Kodunu istemci sırrı olmadan kullanmanıza izin veren yeni bir teknik oluşturuldu. RFC 7636'nın tamamını veya bu kısa girişi okuyabilirsiniz .

PKCE (RFC 7636), istemci sırrı kullanmayan genel istemcilerin güvenliğini sağlamak için kullanılan bir tekniktir.

Öncelikle yerel ve mobil uygulamalar tarafından kullanılır, ancak teknik herhangi bir genel müşteriye de uygulanabilir. Yetkilendirme sunucusu tarafından ek destek gerektirir, bu nedenle yalnızca belirli sağlayıcılarda desteklenir.

dan https://oauth.net/2/pkce/

Mobil uygulamanızda bir web görünümü kullanmak, Android platformunda OAuth2.0 protokolünü uygulamanın ekonomik bir yolu olmalıdır.

Redirect_uri alanına gelince, http://localhostiyi bir seçim olduğunu düşünüyorum ve uygulamanızın içinde bir HTTP sunucusu taşımak zorunda değilsiniz, çünkü sınıfta onPageStartedişlev uygulamasını geçersiz kılabilir ve parametreyi kontrol ettikten sonra WebViewClientweb sayfasını yüklemeyi durdurabilirsiniz .http://localhosturl

public void onPageStarted(final WebView webView, final String url,
        final Bitmap favicon) {}

Kimlik doğrulama için en sorunsuz kullanıcı deneyimi ve uygulanması en kolay olanı, uygulamanıza bir web görünümü yerleştirmektir. Kimlik doğrulama noktasından web görünümü tarafından alınan yanıtları işleyin ve hatayı (kullanıcı iptali) veya onayı tespit edin (ve url sorgu parametrelerinden jetonu çıkarın). Ve bunu aslında tüm platformlarda yapabileceğinizi düşünüyorum. Bu çalışmayı aşağıdakiler için başarıyla yaptım: ios, android, mac, windows store 8.1 uygulamaları, windows phone 8.1 uygulaması. Bunu şu hizmetler için yaptım: dropbox, google drive, onedrive, box, basecamp. Windows olmayan platformlar için, platforma özgü tüm API'leri açığa çıkarmadığı varsayılan Xamarin'i kullanıyordum, ancak bunu mümkün kılmak için yeterince açığa çıktı. Bu nedenle, platformlar arası bir bakış açısıyla bile oldukça erişilebilir bir çözüm ve