RESTful API'de API Anahtarları ile HTTP Kimlik Doğrulaması ve OAuth Karşılaştırması


102

Bakımını yaptığım uygulamalardan biri için bir RESTful API oluşturmaya çalışıyorum. Şu anda, daha kontrollü erişim ve güvenlik gerektiren çeşitli şeyler inşa etmeye çalışıyoruz. API güvenliğini nasıl sağlayacağımı araştırırken, hangi formu kullanacağım konusunda birkaç farklı fikir buldum. Bazı kaynaklarda HTTP-Auth'un gidilecek yol olduğunu söylerken, diğerlerinin API anahtarlarını tercih ettiğini ve diğerlerinin (burada SO'da bulduğum sorular dahil) OAuth'a yemin ettiğini gördüm.

Sonra, tabii ki, API anahtarlarını tercih edenler, OAuth'un bir kullanıcı adına erişim sağlayan uygulamalar için tasarlandığını söyler (anladığım kadarıyla, Facebook hesabınızı kullanarak Facebook dışı bir sitede oturum açmak gibi), ve özellikle kaydolduğu bir sitedeki kaynaklara doğrudan erişen bir kullanıcı için değil (Twitter sunucularına erişen resmi Twitter istemcisi gibi). Ancak, OAuth için öneriler en temel kimlik doğrulama ihtiyaçları için bile geçerli gibi görünüyor.

Öyleyse sorum şu: Tüm bunların HTTPS üzerinden yapıldığını varsayarsak, üçü arasındaki pratik farklardan bazıları nelerdir? Ne zaman biri diğerlerine göre düşünülmelidir?


ne ile sonuçlandın?
Irwin

@Irwin - Bu soruyu epey bir süre önce sordum ve o zamandan beri bunu gerektiren projeden ayrıldım, ancak API anahtarları ve HTTP kimlik doğrulaması kullanılarak gönderilen (kullanıcıların asla görmediği) şifre kombinasyonunu kullandım.
Shauna

Yanıtlar:


67

Bu sizin ihtiyaçlarınıza bağlıdır. İhtiyacın var mı:

  • Kimlik - API talebinde bulunduğunu iddia eden kim?
  • Kimlik doğrulama - gerçekten olduklarını söyledikleri kişi mi?
  • Yetkilendirme - yapmaya çalıştıkları şeyi yapmalarına izin veriliyor mu?

ya da üçü?

API Çağrılarının hacmini veya sayısını takip etmek için arayanı tanımlamanız gerekiyorsa basit bir API Anahtarı kullanın. API anahtarını verdiğiniz kullanıcı bunu başka biriyle paylaşırsa, sizin API'nizi de çağırabileceğini unutmayın.

Ancak, Yetkilendirmeye de ihtiyacınız varsa, yani yalnızca API arayanı temelinde belirli kaynaklara erişim sağlamanız ve ardından oAuth'u kullanmanız gerekir.

İşte iyi bir açıklama: http://www.srimax.com/index.php/do-you-need-api-keys-api-identity-vs-authorization/


"belirli kaynaklar" ile "belirli api çağrılarını" mı yoksa "belirli veritabanı kayıtlarını" mı yoksa her ikisini birden mi kastediyorsunuz?
Magne

Çoğunlukla DB kayıtları (veya korumalı durumu ortaya çıkaran veya durumu değiştiren herhangi bir şey). Ama aynı zamanda, db'de gerçekten hiçbir şeyi değiştirmeyen, ancak sistem kaynaklarını kullanan ve yalnızca yetkili kişiler tarafından kullanılabilen premium bir özellik (bulut üzerinde bir algoritma çalıştırmak gibi) gibi bir şey de olabilir.
Sid

@Sid Facebook veya LinkedIn'e kaydolan kullanıcıları kaydetmek için OAuth kullanan bir uygulama üzerinde çalışıyorum. Ek olarak, verileri yönetmek için diğer hizmetler için API'mizi açıyoruz. Bu durumda, kullanıcı kimlik doğrulaması için OAuth'u ve API'ye erişen hizmetler için bir api anahtarı veya kullanıcı adı ve şifre kombinasyonunu (bağlantı yaptığınız makalede olduğu gibi) önerir misiniz? OAuth ve api anahtarının her ikisi de farklı amaçlar için kullanılır, değil mi?
Tom Doe

@TomDoe Merhaba Tom - Evet bu mantıklı. Muhtemelen OAuth2'yi şimdi kullanmak istiyorsunuz. Sunucunuz Python'da (Django veya Flask) ise github.com/omab/python-social-auth
Sid

Bir API anahtarının bu üç şeyi nasıl sağlayamayacağını anlamıyorum. Kimlik ve Kimlik Doğrulamanın her ikisi de "belirli bir sırrı biliyor musunuz?" (ayrı bir konu olan 2FA'yı tanıtmadığınız sürece). Kullanıcı 5'in çok uzun API anahtarını verirsem, bu en azından bir kullanıcı adı / şifre kadar Kullanıcı 5 olduğumu iddia eder ve kanıtlar. Ve farklı API anahtarlarına farklı izinler atanmaması için hiçbir neden yoktur. Sağ? Burada neyi özlüyorum?
Nathan Long

3

API Anahtarları ve hatta Jetonlar, REST API'lerinin açık kaynaklarına erişim sağladıkları için doğrudan Kimlik Doğrulama ve Yetkilendirme mekanizmaları kategorisine girer. Bu tür doğrudan mekanizmalar, yetkilendirme kullanım durumlarında kullanılabilir.

Bir kaynağa veya REST uç noktaları tarafından açığa çıkan bir dizi kaynağa erişim elde etmek için, istekte bulunan ayrıcalıklarının kimliğine göre kontrol edilmesi gerekir. İş akışının ilk adım, daha sonra ile kimlik doğrulama bir doğrulama isteği; birbirini izleyen adım, erişim düzeyini (yani okuma, yazma veya okuma / yazma) yetkilendirmek için bir dizi tanımlanmış kurala göre kimliği kontrol etmektir . Bahsedilen adımlar tamamlandıktan sonra, tipik bir diğer endişe, izin verilen istek oranıdır , yani talep sahibinin verilen kaynak (lar) a karşı saniyede kaç istek gerçekleştirmesine izin verildiği anlamına gelir.

OAuth (Açık Yetkilendirme) , çoğu zaman büyük İnternet Şirketleri tarafından parola sağlamadan erişim sağlamak için kullanılan, temsili erişim için standart bir protokoldür . Açıkça görüldüğü gibi, OAuth, yukarıda belirtilen endişeleri yerine getiren bir protokoldür: Kaynak sahibi adına sunucu kaynaklarına güvenli yetkilendirilmiş erişim sağlayarak Kimlik Doğrulama ve Yetkilendirme. Üçüncü tarafın, kaynak sahibi adına sunucu tarafından yönetilen kaynağa erişmesine izin veren erişim Jetonları mekanizmasına dayanır. Örneğin, ServiceX, John yetkilendirmeyi yetkilendirdikten sonra John adına John Smith'in Google Hesabına erişmek ister; Ardından, ServiceX'e Google Hesabı ayrıntılarına erişmek için zamana dayalı bir Token verilecektir, büyük olasılıkla yalnızca okuma erişiminde.

API Anahtarı kavramı, yukarıda açıklanan OAuth Jetonuna çok benzer. En büyük fark, yetkilendirmenin olmamasıdır: Kullanıcı, anahtarın birbirini izleyen programatik etkileşimler için hizmet sağlayıcıdan doğrudan talep etmesidir. API Anahtarının durumu da zamana dayalıdır: OAuth Jetonu olarak Anahtar bir süreli kiralamaya veya sona erme süresine tabidir. İlave bir husus olarak, Anahtar ve Token, hizmet sözleşmesi ile oran sınırlamasına tabi olabilir, yani, saniyede sadece belirli sayıda talep yerine getirilebilir.

Özetlemek gerekirse, gerçekte geleneksel Kimlik Doğrulama ve Yetkilendirme mekanizmaları ile Anahtar / Belirteç tabanlı sürümler arasında gerçek bir fark yoktur. Paradigma biraz farklıdır: İstemci ile sunucu arasındaki her etkileşimde kimlik bilgilerini yeniden kullanmaya devam etmek yerine, genel etkileşim deneyimini daha sorunsuz ve muhtemelen daha güvenli hale getiren bir destek Anahtarı / Belirteci kullanılır (genellikle JWT standardını, Anahtarları ve Jetonlar, işçiliği önlemek için sunucu tarafından dijital olarak imzalanır).

  • Doğrudan Kimlik Doğrulama ve Yetkilendirme : Geleneksel kimlik bilgilerine dayalı sürümlerin bir çeşidi olarak anahtar tabanlı protokoller.
  • Yetkilendirilmiş Kimlik Doğrulama ve Yetkilendirme : Sırayla Belirteçleri kullanan OAuth tabanlı protokoller gibi, yine kimlik bilgilerine dayalı sürümlerin bir çeşidi olarak (genel amaç parolayı herhangi bir üçüncü tarafa ifşa etmek değildir).

Her iki kategori de, ilgilenen kaynakların sahibi olan sunucuyla ilk etkileşim için geleneksel bir kimlik doğrulama iş akışı kullanır.

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.