API anahtarı nereye yerleştirilir: Özel bir HTTP üstbilgisi VS Özel bir şemaya sahip Yetkilendirme üstbilgisi

Bir API Anahtarı üzerinden yetkilendirme / kimlik doğrulama kullanarak bir REST API tasarlıyorum.

Bunun için en iyi yer ne olduğunu anlamaya çalıştım ve birçok insan gibi özel bir HTTP üstbilgisi kullanmanızı öneririz öğrendim ProjectName-Api-Key, örneğin:

ProjectName-Api-Key: abcde

ancak Authorizationbaşlığı özel bir şema ile kullanmak da mümkündür ve ideolojik olarak doğrudur , örneğin:

Authorization: ApiKey abcde

Öte yandan, özel bir Yetkilendirme şemasının bazı istemciler tarafından beklenmedik ve desteklenemeyebileceğini ve yine de özel koda yol açabileceğini düşündüm, bu nedenle müşteriler hakkında herhangi bir beklentisi olmadığı için özel bir başlık kullanmak daha iyidir.

Hangi yolla API Anahtarı göndermeyi tercih edersiniz?

— Romang
kaynak

Rehberliğindeki projeler Authorization: Bearer <token>başlık kullanıyor ve bununla ilgili hiçbir zaman tek bir sorun yoktu. Jetonlar JWT s'dir.

— Andy

@DavidPacker Anladığım kadarıyla, Bearerşema yalnızca oAuth2 ile birlikte kullanılıyor. OAuth seslerinden ayrı olarak uygulamak, yanlış kullanım olarak algılanır. OAuth yoksa bu şemayı kullanmak neden doğrudur? Bu arada, API'm için bir tür yetkilendirme seçme konusunda sorun yaşadım. API yalnızca bir güvenilir hizmet için kullanılabilir olacak, bu yüzden oAuth2'nin istemci kimlik bilgileri akışını araştırdım ve benim durumumda ApiKey ile karşılaştırıldığında herhangi bir fayda bulamadım.

— RomanG

@DavidPacker Daha sonra anladım ki, ApiKey yetkilendirmesi ApiKeyyeniden adlandırılmış ve Access Tokenson kullanma tarihi olmadan müşteriye verilen bir yorum olarak yorumlanmışsa geçerli bir oAuth uygulaması olarak kabul edilebilir . Bu bir tür felsefi açıdan, eğer benim durumum basit terimlerle tarif edilebiliyorsa karmaşık tanımlamalar getirmemeye ve sadece "ApiKey" demeye karar verdim. Protokolünüz oAuth standardını uyguluyorsa, kullanmaya karar verebilirim Bearer, ancak kabul etmiyor, sanırım bu şema uygulanamaz.

— RomanG

Kendinizi çok kısıtlıyorsunuz. API tüketicisi, OAuth uygulasanız da uygulamasanız da daha az umursamazdı. Önem verdikleri şey token güvenliği, token veren işler ve doğru bir şekilde doğrulanabilmeleridir. Taşıyıcıyı doğrudan JWT belgelerinde kullanmanızı önerirler . JWT, Bearer şemasına mükemmel bir şekilde uyuyor ve JWT'leri daha fazla tavsiye edemedim. REST uygulamaları için mükemmeldir, çünkü iptal etme özelliğine gerek duymadıkça, veritabanına çarpmadan bile bir kullanıcının kimliğini doğrulayabilirsiniz.

— Andy

(sürerek) ... lütfen api anahtarlarının kimlik veya yetkilendirmeyi iletmek için değil, genellikle yapılandırılmış bir güvenen taraf ile bir kimlik doğrulayıcı arasında paylaşılan paylaşılan sırlar olduğunu bilin . Başka bir deyişle, kimlik doğrulama sonucunu temsil etmeyen, yalnızca bir güvenlik anlaşması başlatmaları amaçlanmıştır. Api anahtarı, kendinizi sistemin güvenilir doğrulayıcısına karşı tanımlama yetkinizi bildirir. Güvenli kaynak erişimini kontrol etmek için anahtarı bir jeton olarak kullanmak kötü juju

— K. Alan Bates

Yetkilendirme kullanıyorsanız tutarlı olun

Bazıları, aşağıdakilerin gereksiz olduğunu iddia eder ( ve çok uzun zaman önce onlarla anlaşmış olurdum ), ancak bu günlerde, Authorizationbaşlığı kullanırsak token türünü bilgilendirmeliyiz , çünkü API anahtarları kendiliğinden açıklayıcı değildir ¹ .

Neden gerekli olduğunu düşünüyorum ve neden önemli olduğunu düşünüyorum? Çünkü günümüzde farklı kimlik doğrulama / yetkilendirme protokollerini desteklemek zorunludur. AuthorizationBaşlığı tüm bu protokoller için kullanmayı planlıyorsak , kimlik doğrulama hizmetimizi tutarlı hale getirmeliyiz. Ne tür bir token gönderdiğimiz ve hangi yetkilendirme protokolünün uygulanması gerektiğini bildirmenin yolu da başlığa gitmelidir.

Authorization: Basic xxxx
Authorization: Digest xxxx
Authorization: Bearer xxxx
Authorization: ApiKey-v1 xxxx
Authorization: ApiKey-v2 xxxx

Bunu umursamıyordum, ancak güncellemeleri garanti edilmeyen uygulama istemcisi uygulamalarıyla çalıştıktan sonra (çoğunlukla cep telefonları ve sensörler) başladım. Güvenliği uygulama şeklimde daha temkinli olmaya başladım, böylece istemci ile uğraşmadan ve sunucu tarafında çok fazla acı çekmeden genişletebiliyorum.

Endişeler

Kendi planlarımı uygularken karşılaştığım sorunlar, yorumlanana benzerdi.

Öte yandan, özel bir Yetkilendirme düzeninin bazı istemciler tarafından beklenmedik ve desteklenemeyebileceğini ve yine de özel koda yol açabileceğini düşündüm

Müşterilere söyle , kütüphaneler, çerçeveler, ters proxy'ler söyle .

Avantajları

Önemli bir avantajı önbellektir. Aksi belirtilmedikçe, paylaşılan önbellekler başlığı önbelleğe almaz (ve bu elbette iyidir).

Yetkilendirme mi yoksa özel başlık mı?

Deneyimlerime göre, kendi Authorizationplanımı uygulamak, özel yetkilendirme başlıklarını uygulamaktan çok daha fazla iş (veya daha fazla) aldı, özel başlıklar kullandığımda daha fazla tasarım özgürlüğü ve önbellek üzerinde daha fazla kontrole sahip olma gibi küçük bir fark. Nedeni, oldukça aptaldır Ben çoğu zaman Cache-controliçin set no-cacheveya no-storebana ne olursa olsun daha deterministik sunucuya çağrı (Bu izleme ve test için geldiğinde bu önemlidir) ağın topoloji yapmak için izin.

^{1: Bu cevabın API Anahtarları ile ilgili çok açık olduğunu düşünüyorum}

— LAIV
kaynak

Kullanımı X-2012 yılı itibari ile kaldırılmıştır: stackoverflow.com/a/3561399/923720

— Darkhogg

ops! Bilmiyordum. Düzenlendi ve düzeltildi.

— Laiv

Bu sorudan önce herkesin API anahtarını URL'ye koyduğunu, ancak gizlemek için HTTPS kullandığını düşündüm. Bazı alternatifleri görmek güzel. Örneğin, İçerikli, Yetkilendirmeye veya sorgulama çapına izin verir: contentful.com/developers/docs/references/content-delivery-api/…

— user949300

@ user949300 ... şifreli bir paylaşımlı sır kullanmak (örn. suri üzerinden uri'de api anahtarı) hiçbir şeyden daha güvenli değildir, ancak ele geçirilirse ve kimlikler üzerinde ayrıntılılık sağlamazsa kolayca taklit edilebilir. Asla güvenen taraflar ve paylaşılan sır ile hareket etmeye yetkili beyaz listeye alınmış makine kimlikleri arasındaki paylaşılan sırrı eşleştirdiğim makine-makine iletişimi dışında hiçbir şey için api_keys kullanmadım. Makineden makineye bağlantı yapıldıktan sonra, insan operatörü diğer yollarla kimlik doğrulaması yapar.

— K. Alan Bates

@K. Alan Bates API etkileşimlerimin çoğu, coğrafi kodlama, hava durumu raporları ve benzerlerinin serbest katmanları gibi nispeten "önemsiz" şeyler için olmuştur; burada API anahtarı, hız sınırlaması için ciddi kullanıcı sırlarından daha fazladır. Bu nedenle, OP'ye gelince, hangi güvenlik seviyesinin gerekli olduğuna bağlıdır.

— user949300