Erişim belirteçlerinin süresi neden doluyor?


209

Google API ve OAuth2 ile çalışmaya yeni başladım. Müşteri uygulamamı yetkilendirdiğinde bana "yenileme simgesi" ve kısa süreli "erişim kodu" verilir. Artık erişim belirtecinin süresi dolduğunda, yenileme kodumu Google'a POST yapabilirim ve bana yeni bir erişim belirteci verecekler.

Benim sorum erişim belirtecinin süresinin dolmasının amacı nedir? Neden yenileme jetonu yerine uzun süreli bir erişim jetonu olamaz?

Ayrıca, yenileme simgesinin süresi doluyor mu?

Google OAuth2 iş akışı hakkında daha fazla bilgi için Google API'larına Erişmek için OAuth 2.0'ı Kullanma konusuna bakın .

Yanıtlar:


226

Bu, uygulamaya özgüdür, ancak genel fikir, sağlayıcıların uzun vadeli yenileme belirteçleriyle kısa süreli erişim belirteçleri düzenlemelerine izin vermektir. Neden?

  • Birçok sağlayıcı, güvenlik açısından çok zayıf olan taşıyıcı belirteçlerini destekler. Onları kısa ömürlü ve yenilenme gerektirerek, bir saldırganın çalınan bir jetonu kötüye kullanma süresini sınırlandırırlar.
  • Büyük ölçekli dağıtım, her API çağrısında veritabanı araması yapmak istemez, bunun yerine şifre çözme ile doğrulanabilen kendi kendine kodlanmış erişim belirteci verir. Bununla birlikte, bu aynı zamanda bu tokenleri iptal etmenin bir yolu olmadığı anlamına gelir, böylece kısa bir süre için yayınlanırlar ve yenilenmeleri gerekir.
  • Yenileme belirteci, istemci kimlik doğrulaması gerektirir ve bu da onu güçlendirir. Yukarıdaki erişim belirteçlerinin aksine, genellikle bir veritabanı aramasıyla uygulanır.

4
İki soru: 1) Mobil uygulamalar söz konusu olduğunda, istemci kimlik doğrulaması gereksinimi onu daha da güçlendiriyor mu? Client_secret, uygulama kaynak kodunun bir parçası olduğu için hiçbir şekilde gizli değildir. Erişim belirtecinin yalnızca TLS ile paylaşıldığını (ve ilk madde işaret noktanızın geçerli olmadığını) varsayarsak ekstra güvenlik var mı? 2) Tüm bunların senaryomuzda geçerli olduğunu varsayarsak (yalnızca TLS, kendinden kodlu kurtarılamaz jetonlar yok), süresi dolmayan erişim jetonları vermek doğru mudur?
Thilo

4
Taşıyıcı belirteci nedir ve yenileme ve erişim belirteçleriyle ne ilgisi vardır?
allyourcode

7
@Thilo Bence fikir, erişim belirteçlerinin iptal edilebilir olması gerekmiyor. Eran'ın belirttiği gibi, bu talep edilen hizmetin <em> bazı veritabanındaki erişim belirtecine bakmadan </em> bir talebe hizmet verip vermemeye karar vermesini mümkün kılar. AFAICT, yenileme simgelerini ve erişim simgelerini ayırmanın gerçek yararı budur.
allyourcode

5
Bir erişim belirteci nasıl kısa ömürlüdür? Süresi dolmuş bir taşıyıcı belirteciyle istekte bulunursam, yenileme belirteci yeni bir taşıyıcı belirteci döndürür. Aynı şekilde, birisinin çerezlerini çerezlerinden çalarsam ve bu çerezle kendi çerezimi takarsam, sunucuya gönderirim, yenilenir ve bana yeni bir tane gönderir. Bunu durduracak ne var? IP Adresi veya MAC bile demeyin, çünkü bu mantıksız.
Suamere

3
@Suamere, bu zaten açıklanmıştı. Taşıyıcı belirteçleri, kimlik doğrulama veritabanına dokunmayan bir şifreleme işlemi tarafından doğrulanır ve bu da onları sık kaynak erişimi için çok daha verimli hale getirir. Yenileme belirteçleri, veritabanının hala geçerli olduğundan emin olmak için denetlenmesini içeren bir işlemde doğrulanır. Şimdi gmail'in nasıl çalıştığını düşünün. Birisi hesabınıza beklenmedik bir coğrafi konumdan giriş yaparsa bir uyarı alabilirsiniz. Şu anda geçerli yenileme jetonlarına sahip olabilecek tüm konumları görebilirsiniz. Diğer tüm yenileme jetonlarını geçersiz kılarak tüm konumlardan çıkış yapabilirsiniz.
Bon

33

Birkaç senaryo, erişim ve yenileme simgelerinin amacını ve bir oauth2 (veya başka bir kimlik doğrulaması) sistemi tasarlamadaki mühendislik değişimlerini göstermeye yardımcı olabilir:

Web uygulaması senaryosu

Web uygulaması senaryosunda birkaç seçeneğiniz vardır:

  1. kendi oturum yönetiminiz varsa, access_token ve refresh_token öğelerini oturum durumu hizmetinizde oturum durumunda oturum kimliğinizde saklayın. Kaynağa erişmenizi gerektiren kullanıcı tarafından bir sayfa istendiğinde access_token öğesini kullanın ve access_token süresinin dolması durumunda yenisini almak için refresh_token öğesini kullanın.

Birisinin oturumunuzu ele geçirmeyi başardığını düşünelim. Mümkün olan tek şey sayfalarınızı istemektir.

  1. oturum yönetiminiz yoksa, access_token öğesini bir çereze koyun ve bunu oturum olarak kullanın. Ardından, kullanıcı web sunucunuzdan sayfa istediğinde access_token'ı gönderir. Gerekirse uygulama sunucunuz access_token'i yenileyebilir.

1 ve 2 karşılaştırması:

1'de access_token ve refresh_token yalnızca yetkilendirme sunucusu (sizin durumunuzda google) ve uygulama sunucunuz arasındaki kablo üzerinden seyahat eder. Bu güvenli bir kanalda yapılabilir. Bir bilgisayar korsanı oturumu ele geçirebilir, ancak yalnızca web uygulamanızla etkileşime girebilir. 2'de, bilgisayar korsanı access_token'i alıp kullanıcının erişim izni verdiği kaynaklara ilişkin kendi isteklerini oluşturabilir. Bilgisayar korsanı access_token'i ele geçirse bile, kaynaklara erişebilecekleri kısa bir pencereye sahip olacaklar.

Her iki durumda da refresh_token ve clientid / secret sunucu tarafından bilinir ve web tarayıcısından uzun süreli erişim elde etmeyi imkansız hale getirir.

Oauth2 uyguladığınızı ve erişim belirtecinde uzun bir zaman aşımı ayarladığınızı düşünelim:

1) Uygulama sunucusunda gizli olduğu için kısa ve uzun erişim jetonu arasında çok fazla fark yoktur. 2) Birisi tarayıcıda access_token'ı alabilir ve daha sonra kullanıcının kaynaklarına uzun süre doğrudan erişmek için kullanabilir.

Mobil senaryo

Cep telefonunda bildiğim birkaç senaryo var:

  1. İstemci kimliği / sırrını cihazda saklayın ve cihazın, kullanıcının kaynaklarına erişim elde etmesini sağlayın.

  2. İstemci kimliği / sırrını tutmak ve düzenlemeyi yapmasını sağlamak için bir arka uç uygulama sunucusu kullanın. Access_token'ı bir tür oturum anahtarı olarak kullanın ve bunu istemci ile uygulama sunucusu arasında geçirin.

1 ve 2 karşılaştırması

1) Cihazda müşteri kimliği / sır sahibi olduktan sonra artık gizli değillerdir. Herkes koda olabilir ve elbette kullanıcının izniyle sanki senmişsin gibi davranmaya başlayabilir. Access_token ve refresh_token de bellektir ve güvenliği ihlal edilmiş bir cihazdan erişilebilir, bu da kullanıcı kimlik bilgilerini vermeden birisinin uygulamanız olarak hareket edebileceği anlamına gelir. Bu senaryoda, refresh_token access_token ile aynı yerde olduğundan access_token uzunluğunun hack'lerde bir fark yaratmaz. 2) müşteri kimliği / sırrı veya yenileme jetonu tehlikeye atılır. Burada access_token süresinin dolması, bir bilgisayar korsanının kullanıcı kaynaklarına erişebilmesi için ne kadar süre erişebileceğini belirler.

Vade uzunlukları

Burada erişim_konusu sona erme sürenizin ne kadar olması gerektiğine dair kimlik doğrulama sisteminizle ne güvenceye aldığınıza bağlıdır. Kullanıcı için özellikle değerli bir şey varsa, kısa olmalıdır. Daha az değerli bir şey, daha uzun olabilir.

Google gibi bazı kişilerin refresh_token süreleri dolmaz. Bazıları yığın akışı gibi. Süre bitimine ilişkin karar, kullanıcı kolaylığı ve güvenlik arasındaki bir ödünleşmedir. Yenileme belirtecinin uzunluğu, kullanıcının dönüş uzunluğuyla ilişkilidir; yani, yenilemeyi kullanıcının uygulamanıza ne sıklıkta geri döndüğüne ayarlayın. Yenileme belirtecinin süresinin sona ermesinin tek yolu iptal edilmezse, açıkça iptal edilir. Normalde bir oturum açma işlemi iptal edilmez.

Umarım oldukça uzun yazı yararlıdır.


MOBİL SENARYO hakkında İstemci kimliğini sunucunuzda saklarsanız önemlidir. böylece herkes uygulaması sadece sunucunuza istek gönderebilir ve kendi sunucunuz üzerinden kullanıcı kaynaklarına erişebilir, bu yüzden aynı
Amir Bar

doğru, ancak daha sonra, temel jetona tam erişim yerine, yalnızca sağladığınız olanaklara erişebilirler. Yani uygulamanızı taklit edebilirler. Genellikle, belirteçlerin geniş izinleri olabilir, ancak yalnızca bir alt kümeye ihtiyacınız vardır. Arka uçta jetona basmak, ihtiyacınız olduğunda daha fazla kısıtlama sağlar.
Ed Sykes

11

Diğer yanıtlara ek olarak:

Erişim Simgeleri alındıktan sonra, genellikle İstemcilerden korunan Kaynak Sunucularına her istekle birlikte gönderilir. Bu, erişim belirtecinin çalınması ve yeniden yürütülmesi için bir risk oluşturur (elbette erişim belirteçlerinin "Taşıyıcı" türünde olduğu varsayılır (ilk RFC6750'de tanımlandığı gibi).

Gerçek hayatta bu risklere örnekler:

  • Kaynak Sunucuları genellikle dağıtılmış uygulama sunuculardır ve Yetkilendirme Sunucularına kıyasla daha düşük güvenlik düzeylerine sahiptir (düşük SSL / TLS yapılandırması, daha az sertleştirme vb.). Yetkilendirme Öte yandan sunucular genellikle kritik Güvenlik altyapısı olarak kabul edilir ve daha sert bir şekilde sertleştirilir.

  • Erişim Belirteçleri, Kaynak Sunucularında veya istemcilerde tanılama amacıyla yasal olarak toplanan HTTP izlerinde, günlüklerinde vb. Görünebilir. Bu izler halka açık veya yarı halka açık yerlerde (böcek izleyiciler, servis masası vb.) Değiştirilebilir.

  • Backend RS uygulamaları az ya da çok güvenilir üçüncü taraflara sağlanabilir.

Öte yandan Yenileme Jetonu genellikle kablolar üzerinden yalnızca iki kez ve her zaman istemci ve Yetkilendirme Sunucusu arasında iletilir : bir kez istemci tarafından alındığında ve bir kez yenileme sırasında istemci tarafından kullanıldığında (önceki yenilemeyi etkin bir şekilde "süresi doluyor") jeton). Bu, müdahale ve tekrarlama için büyük ölçüde sınırlı bir fırsattır.

Son düşünce, Yenileme Jetonları, tehlikede olan müşterilere karşı çok az koruma sağlar.


Biraz buna değindiniz, ancak jetonları almak için (veya tersine açık bir şekilde açığa çıkarmak) daha büyük saldırı yüzeyinin uygulama günlüklerinde veya haksız eklenmiş kaynak hizmetlerinde (bugün bir MITM saldırısı değil) olduğunu vurgulayacağım. Ortak bir API arka ucundaki hemen hemen her yerde kullanılan erişim belirtecine erişimi vardır (HttpRequest vb nesnesine erişimi varsa). Yalnızca sistemdeki İKİ kod yolunun yenileme koduna erişimi vardır - bu kodu ilk başta oluşturan koddur ve onu yeni bir erişim koduyla değiştirir. Bu önemli bir saldırı yüzeyi farkıdır.
Tom Dibble

9

Bu aslında bir güvenlik önlemidir. Uygulamanızın güvenliği ihlal edilirse, saldırgan yalnızca kısa ömürlü erişim koduna erişebilir ve yeni bir tane oluşturmanın yolu yoktur.

Yenileme simgelerinin süresi de doluyor, ancak erişim belirtecinden çok daha uzun yaşaması gerekiyor.


45
Ancak saldırganın yenileme jetonuna da erişimi olmaz mı? ve bunu yeni bir erişim belirteci oluşturmak için kullanabilir mi?
levi

10
@ levi, bilgisayar korsanı yeni erişim belirteci oluşturmak için yenileme belirtecini kullanamaz çünkü yeni erişim belirtecini oluşturmak için istemci kimliği ve istemci sırrı yenileme belirteciyle birlikte gereklidir.
Spike

9
@Spike True, ancak uygulamada istemci kimliği ve sırrı da gömülü değil mi?
Andy

9
Bu nedenle, kesişme yalnızca sıradan veri isteklerini yakaladığı sürece paket koklamasına karşı bir miktar koruma sağlar (Chuck yalnızca erişim belirtecini alır)? Bu biraz zayıf geliyor; siyah şapka, kullanıcı yeni bir erişim belirteci isteyene kadar biraz beklemek zorunda kalır ve ardından istemci kimliğini, sırrını ve yenileme belirtecini alır.

3
Bu sadece burada geciktirilebilir, ancak SSL üzerinden gönderilirse, başka bir olası güvenlik katmanına eklenmez. Herkesin SSL'nin ne olduğunu bildiğini varsayıyorum.
Damon Drake
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.