Yetkilendirme HTTP başlığını özelleştirin

81

Bir API'ye istek gönderdiğinde bir istemcinin kimliğini doğrulamam gerekiyor. İstemcinin bir API simgesi var ve Authorizationbelirteci sunucuya göndermek için standart başlığı kullanmayı düşünüyordum .

Normal olarak bu durum, başlık kullanılır Basicve Digestkimlik doğrulama. Ancak bu başlığın değerini özelleştirmeme ve özel bir kimlik doğrulama şeması kullanma iznim olup olmadığını bilmiyorum, örneğin:

Authorization: Token 1af538baa9045a84c0e889f672baf83ff24

Bunu tavsiye eder misin, etmez misin? Veya jetonu göndermek için daha iyi bir yaklaşım var mı?

api  http  rest  http-headers  authorization 
— Thomas Watson
kaynak

Yanıtlar:

51

Authorization:Başlığı kullanan kendi özel kimlik doğrulama şemalarınızı oluşturabilirsiniz - örneğin, OAuth bu şekilde çalışır.

Genel bir kural olarak, sunucular veya proxy'ler standart başlıkların değerlerini anlamazlarsa, onları yalnız bırakır ve görmezden gelirler. Genellikle beklenmedik sonuçlar üretebilen kendi başlık anahtarlarınızı oluşturuyor - birçok proxy, tanımadıkları adların bulunduğu başlıkları çıkarır.

Bununla birlikte, Authorization:tanımlama bilgilerinin açıkça özel değerler taşımak üzere tasarlanmasının basit bir nedeni olarak , başlık yerine belirteci iletmek için tanımlama bilgileri kullanmak daha iyi bir fikirdir , oysa HTTP'nin yerleşik kimlik doğrulama yöntemlerinin belirtimi gerçekten her iki durumda da - tam olarak ne söylediğini görmek istiyorsanız, buraya bir göz atın .

Bununla ilgili diğer bir nokta, birçok HTTP istemci kitaplığının Digest ve Basic kimlik doğrulaması için yerleşik desteğe sahip olmasıdır, ancak başlık alanında ham bir değer belirlemeye çalışırken hayatı daha da zorlaştırabilir, oysa hepsi çerezler için kolay destek sağlar ve içlerinde aşağı yukarı herhangi bir değere izin verir.

— DaveRandom
kaynak
10
OAuth'un bu şekilde çalıştığını duymak güzel. Tanımlama bilgilerini kullanmanın müşteri uygulamasını kolaylaştırdığından emin değilim. İstemciniz bir tarayıcı olmadığı sürece, çerezlerle çalışma kurallarının (yol, süre sonu vb.) Bir istemcide uygulanması, yalnızca bir başlık alanı ayarlamayı hatırlamaktan daha karmaşıktır. Çoğu istemci kitaplığı, doğru başlıkları ayarlamayı oldukça basit hale getirir.
— Thomas Watson
2
@ThomasWatson, çerez kapsamı noktaları konusunda sizinle aynı fikirde olamasam da, burada gerçekten önemli olmamalı. HTTP kimlik doğrulamasının kapsamı ( Authorization:başlık kullanılarak) etki alanına göre belirlenir. Bu, tanımlama bilgisinin etki alanını "bu etki alanı" olarak ve yolunu "/" olarak ayarlarsanız, HTTP kimlik doğrulamasının kapsamı ile aynı kapsama sahip olacağı anlamına gelir. Ancak, bu gerçekten size bağlıdır - ancak Julian Reschke'nin de işaret feel that you have something of generic useettiği gibi, başka bir uygulamada kullanılabilecek bir şey olmadıkça, muhtemelen yeni bir kimlik doğrulama şeması tanımlamamalısınız .
— DaveRandom
8

CROSS ORIGIN talebi durumunda şunu okuyun:

Bu durumla karşılaştım ve ilk başta AuthorizationBaşlığı kullanmayı seçtim ve daha sonra aşağıdaki sorunla karşılaştıktan sonra kaldırdım.

AuthorizationBaşlık, özel bir başlık olarak kabul edilir. Dolayısıyla, AutorizationBaşlık kümesiyle bir etki alanları arası istek yapılırsa , tarayıcı önce bir ön kontrol isteği gönderir . Bir ön kontrol isteği, SEÇENEKLER yöntemi tarafından yapılan bir HTTP isteğidir, bu istek, istekten tüm parametreleri çıkarır. Sunucunuzun Access-Control-Allow-Headers, özel başlığınızın ( Authorizationbaşlık) değerine sahip Başlık ile yanıt vermesi gerekir .

Dolayısıyla, istemcinin (tarayıcının) gönderdiği her istek için, tarayıcı tarafından ek bir HTTP isteği (SEÇENEKLER) gönderiliyordu. Bu, API'min performansını bozdu. Bunu eklemenin performansınızı düşürüp düşürmediğini kontrol etmelisiniz. Çözüm olarak, http parametrelerinde belirteçler gönderiyorum, bunu yapmanın en iyi yolu olmadığını biliyorum, ancak performanstan ödün veremem.

— Abhishek Kumar
kaynak
Ayrıca oturum kimliğimi http parametrelerinde göndermeyi düşünüyorum. Neden bunun en iyi yol olmadığını söylüyorsun? Güvenlik duvarlarının başlıkları çıkarmasına ve ayrıca çapraz kaynak performans düşüşüne karşı sağlamlık avantajına sahip görünüyor. Dezavantajları nelerdir?
— 2016
1
Dezavantaj yalnızca GET talebi durumunda ortaya çıkar. Authorization tokenUygulamam için (hassas verilerimi) kullanarak kullanıcının kimliğini doğrulamak zorunda kaldım . Aynı nedenle GET'te hassas veriler göndermemeliyiz, paramlarda yetkilendirme belirteci kullanmamalıyız. W3 w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.3'e göre "HTTP protokolü, hassas verilerin gönderimi için GET tabanlı formlar KULLANMAMALIDIR".
— Abhishek Kumar
Başlıklardan hoşlanmıyorsanız belirteci çerezlerde saklayabilirsiniz. (Jetonu oturum kimliğiyle karıştırmayın). PUT ve DELETE ile SEÇENEKLERİ yine de göndereceğini unutmayın ... Çoğu zaman sunucu tarafı REST istemcisi kullandığınızı ve tarayıcının çok iyi bir REST istemcisi olarak görülmediğini unutmayın.
— inf3rno
5

Bu biraz eski ama aynı soruya cevap arayan başkaları da olabilir. API'leriniz için hangi koruma alanlarının mantıklı olduğunu düşünmelisiniz. Örneğin, API'lerinizin kullanımını bilinen, kayıtlı istemci uygulamalarıyla sınırlandırmak için istemci uygulamasının erişimini tanımlamak ve doğrulamak isteyebilirsiniz. Bu durumda,Basickullanıcı kimliği olarak istemci tanımlayıcısını ve parola olarak istemci paylaşılan sırrını içeren kimlik doğrulama şeması. Tescilli kimlik doğrulama şemalarına ihtiyacınız yoktur, sadece her koruma alanı için istemciler tarafından kullanılacak olanları açıkça belirleyin. Her koruma alanı için yalnızca birini tercih ederim, ancak HTTP standartları, her bir WWW-Authenticate başlık yanıtında hem birden çok kimlik doğrulama şemasına hem de her yanıtta birden çok WWW-Authenticate başlığına izin verir; bu, API istemcileri için hangi seçeneklerin kullanılacağı konusunda kafa karıştırıcı olacaktır. Tutarlı ve net olun, ardından API'leriniz kullanılacaktır.

— Steve Dearborn
kaynak
2

Özel şema adlarıyla HTTP kimlik doğrulamasını kullanmamanızı tavsiye ederim. Eğer jenerik kullanım şey olduğunu düşünüyorsanız, olabilir de, yeni bir düzeni tanımlar. Ayrıntılar için http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-latest.html#rfc.section.2.3 bakın.

— Julian Reschke
kaynak
Bağlanılacak belge bir HTTP / 1.1 taslağıdır. Son standarda bakmaya çalışıyorum ve özel şemaları kaydetmem gerektiğine dair hiçbir şey bulamıyorum. Bu sadece taslak hazırlama sürecinde varsayılan planları bulmak ve üzerinde anlaşmak istemeleri olamaz mı?
— Thomas Watson
Thomas, atıfta bulunduğum belge RFC 2616 / 7'nin revizyonudur (planlar için bir kayıt defteri yoktur). Devam eden bir çalışma ama tamamlanmaya yaklaşıyor.
— Julian Reschke
1

Lütfen postacıda aşağıda deneyin: -

Başlık bölümünde örnek benim için çalışsın ..

Yetkilendirme: JWT eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyIkX18iOnsic3RyaWN0TW9kZSI6dHJ1ZSwiZ2V0dGVycyI6e30sIndhc1BvcHVsYXRlZCI6ZmFsc2UsImFjdGl2ZVBhdGhzIjp7InBhdGhzIjp7InBhc3N3b3JkIjoiaW5pdCIsImVtYWlsIjoiaW5pdCIsIl9fdiI6ImluaXQiLCJfaWQiOiJpbml0In0sInN0YXRlcyI6eyJpZ25vcmUiOnt9LCJkZWZhdWx0Ijp7fSwiaW5pdCI6eyJfX3YiOnRydWUsInBhc3N3b3JkIjp0cnVlLCJlbWFpbCI6dHJ1ZSwiX2lkIjp0cnVlfSwibW9kaWZ5Ijp7fSwicmVxdWlyZSI6e319LCJzdGF0ZU5hbWVzIjpbInJlcXVpcmUiLCJtb2RpZnkiLCJpbml0IiwiZGVmYXVsdCIsImlnbm9yZSJdfSwiZW1pdHRlciI6eyJkb21haW4iOm51bGwsIl9ldmVudHMiOnt9LCJfZXZlbnRzQ291bnQiOjAsIl9tYXhMaXN0ZW5lcnMiOjB9fSwiaXNOZXciOmZhbHNlLCJfZG9jIjp7Il9fdiI6MCwicGFzc3dvcmQiOiIkMmEkMTAkdTAybWNnWHFjWVQvdE41MlkzZ2l3dVROd3ZMWW9ZTlFXejlUcThyaDIwR09IMlhHY3haZWUiLCJlbWFpbCI6Im1hZGFuLmRhbGUxQGdtYWlsLmNvbSIsIl9pZCI6IjU5MjEzYzYyYWM2ODZlMGMyNzI2MjgzMiJ9LCJfcHJlcyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbbnVsbCxudWxsLG51bGxdLCIkX19vcmlnaW5hbF92YWxpZGF0ZSI6W251bGxdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltudWxsXX0sIl9wb3N0cyI6eyIkX19vcmlnaW5hbF9zYXZlIjpbXSwiJF9fb3JpZ2luYWxfdmFsaWRhdGUiOltdLCIkX19vcmlnaW5hbF9yZW1vdmUiOltdfSwiaWF0IjoxNDk1MzUwNzA5LCJleHAiOjE0OTUzNjA3ODl9.BkyB0LjKB4FIsCtnM5FcpcBLvKed_j7rCCxZddwiYnU

— Madan Dale
kaynak
1
JWT'de gerçekten parola / karma gönderiyor musunuz? Basit bir base64'tür.
— Zakhar
1
@Zakhar: SPA'lar için oldukça tipik bir uygulama, tüm kullanıcı oturumunu JWT içinde kapsüllemek (çünkü tam bir json belgesi olduğundan), sunucu tarafında oturum depolama ihtiyacını ortadan kaldırmaktır.
— cowbert
@cowbert: JWT'de bir tür oturum belirtecinden daha fazlasını kapsüllemenin tipik olup olmadığından emin değilim (örneğin bu gönderiye bakın ).
— Alexander Abakumov
1
@AlexanderAbakumov yanlış yönlendirmelerle dolu makalesi, bazı puanlar aldı, ama bir çok noktası mantıklı gelmiyor ve bir kısmı sebepsiz yere karşı çıkıyor, sadece kurabiyeyi çok sevdiğini söyleyebilirim ve bence bir şeyler alması gerekiyor Fırıncılık ve makalesini düzelttim, kurabiye kullandığım ve günlerimi boşa harcadığım birçok durum var, localStorage ile JWT beni çok fazla baş ağrısından ve zamandan kurtardı, sadece 2 saat çalışma ve patlama, bir daha asla ziyaret etmeyin. Acaba bir mobil uygulama geliştirip geliştirmediğini, sıkı bir şekilde kısıtlanmış güvenlik kurallarına sahip tarayıcıları denediğini vb.
— Mothafar
Al-Mothafar @: Eğer gibi ifadeleri genişletmek müteşekkir olurum that article full of misleadings, a lot of his points does not make sensebir şekilde, vb (anlam, burada muhtemelen bir yorumun ötesinde bir şey). Belki bir cevap veya blog yazısı yazabilirsin? Tartışmaları karşılaştırmak gerçekten ilginç olurdu.
— Alexander Abakumov
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.