REST API Giriş Kalıbı

Bir REST api oluşturuyorum, apigee önerilerini yakından takip ediyorum, fiiller değil isimler kullanarak, url'de pişmiş api sürümü, koleksiyon başına iki api yolu, POST PUT DELETE kullanımı vb.

Giriş sistemi üzerinde çalışıyorum, ancak kullanıcılara giriş yapmak için uygun REST yolundan emin değilim. Bu noktada güvenlik üzerinde çalışmıyorum, sadece giriş kalıbı veya akışı. (Daha sonra HMAC vb. İle 2 adım oAuth ekleyeceğiz)

Olası Seçenekler

• Gibi bir şeye POST https://api...com/v1/login.json
• Gibi bir şeye bir PUT https://api...com/v1/users.json
• Olmadığım bir şey ...

Kullanıcılarda oturum açmak için uygun REST stili nedir?

Roy T. Fielding ve Richard N. Taylor tarafından yapılan Modern Web Mimarisinin İlkeli Tasarımı , yani tüm REST terminolojisinden gelen çalışmaların dizisi, istemci-sunucu etkileşiminin tanımını içerir:

Tüm REST etkileşimleri vatansızdır . Diğer bir deyişle, her istek, bir bağlayıcıdan önce gelen isteklerden bağımsız olarak isteği anlaması için gereken tüm bilgileri içerir .

Bu kısıtlama, 1 ve 3 olmak üzere dört işlevi yerine getirir ve bu özel durumda önemlidir:

• 1 : konektörlerin istekler arasında uygulama durumunu koruma ihtiyacını ortadan kaldırır , böylece fiziksel kaynak tüketimini azaltır ve ölçeklenebilirliği artırır;
• 3 : bir arabulucunun , hizmetler dinamik olarak yeniden düzenlendiğinde gerekli olabilecek bir talebi ayrı olarak görüntülemesine ve anlamasına olanak tanır ;

Ve şimdi güvenlik durumunuza geri dönelim. Her istek, gerekli tüm bilgileri içermelidir ve yetkilendirme / kimlik doğrulama bir istisna değildir. Bunu nasıl başarabilirim? Kelimenin tam anlamıyla her talebi teller üzerinden gerekli bilgileri gönderin.

Bunun nasıl arşivleneceğine dair örneklerden biri karma tabanlı mesaj kimlik doğrulama kodu veya HMAC'dir . Uygulamada bu, her isteğe bir karma ileti geçerli kodu eklemek anlamına gelir. Gizli bir şifreleme anahtarı ile birlikte şifreleme karma işlevi tarafından hesaplanan karma kodu . Şifreleme karma işlevi önceden tanımlanmıştır veya isteğe bağlı kod REST kavramının bir parçasıdır (örneğin JavaScript). Gizli şifreleme anahtarı sunucu tarafından istemciye kaynak olarak sağlanmalı ve istemci bunu her istek için karma kodunu hesaplamak için kullanır.

HMAC uygulamalarına birçok örnek var , ancak aşağıdaki üç konuya dikkat etmenizi istiyorum:

• Amazon Basit Depolama Hizmeti (Amazon S3) için REST İsteklerini Doğrulama
• Soru sormadan Mauriceless'ın cevabı: "RESTful WCF API'sinde HMAC Kimlik Doğrulaması nasıl uygulanır?"
• crypto-js: Standart ve güvenli şifreleme algoritmalarının JavaScript uygulamaları

Pratikte nasıl çalışır?

İstemci gizli anahtarı biliyorsa, kaynaklarla çalışmaya hazırdır. Aksi takdirde, yetkilendirmek ve gizli anahtarı almak için geçici olarak yeniden yönlendirilir (durum kodu 307 Geçici Yeniden Yönlendirme) ve ardından orijinal kaynağa yeniden yönlendirilir. Bu durumda , istemciyi yetkilendirmek için URL'nin ne olduğunu önceden (yani bir yerde sabit kod) bilmeye gerek yoktur ve bu şemayı zamanla ayarlamak mümkündür.

Umarım bu doğru çözümü bulmanıza yardımcı olur!

TL; Her istek için DR Girişi API güvenliğini uygulamak için gerekli bir bileşen değildir, kimlik doğrulamasıdır.

Genel olarak güvenlik hakkında konuşmadan giriş hakkındaki sorunuza cevap vermek zordur. Bazı kimlik doğrulama şemalarında geleneksel giriş yoktur.

REST herhangi bir güvenlik kuralı gerektirmez, ancak uygulamada en yaygın uygulama 3 yönlü kimlik doğrulamalı OAuth'dur (sorunuzda belirttiğiniz gibi). En azından her API isteğinde değil, kendiliğinden giriş yoktur. 3 yollu kimlik doğrulamayla sadece jetonları kullanırsınız.

1. Kullanıcı API istemcisini onaylar ve uzun ömürlü bir belirteç şeklinde istekte bulunma izni verir
2. Api müşterisi, uzun ömürlü olanı kullanarak kısa ömürlü bir jeton alır.
3. Api istemcisi, her istekle kısa ömürlü jeton gönderir.

Bu şema kullanıcıya istediği zaman erişimi iptal etme seçeneği sunar. Gördüğüm halka açık RESTful API'lerin neredeyse tamamı bunu uygulamak için OAuth kullanıyor.

Sorununuzu (ve sorunuzu) giriş açısından çerçevelemeniz gerektiğini düşünmüyorum, genel olarak API'yi güvence altına almayı düşünüyorum.

Genel olarak REST API'lerinin kimlik doğrulaması hakkında daha fazla bilgi için aşağıdaki kaynaklara bakabilirsiniz:

• http://www.infoq.com/news/2010/01/rest-api-authentication-schemes
• REST API Kimlik Doğrulaması
• RESTful API Kimlik Doğrulaması

REST felsefesinin büyük bir kısmı, API'nizi tasarlarken HTTP protokolünün mümkün olduğunca çok standart özelliğinden yararlanmaktır. Bu felsefeyi kimlik doğrulama, istemci ve sunucuya uygulamak API'da standart HTTP kimlik doğrulama özelliklerini kullanır.

Giriş ekranları insan kullanıcı kullanım durumları için mükemmeldir: bir giriş ekranını ziyaret edin, kullanıcı / şifre sağlayın, bir çerez ayarlayın, müşteri bu çerezleri gelecekteki tüm isteklerde sağlar. Web tarayıcıları kullanan kişilerin her bir HTTP isteğiyle bir kullanıcı kimliği ve şifre sağlaması beklenemez.

Ancak bir REST API için, bir giriş ekranı ve oturum çerezleri kesinlikle gerekli değildir, çünkü her istek bir insan kullanıcıyı etkilemeden kimlik bilgilerini içerebilir; ve müşteri herhangi bir zamanda işbirliği yapmazsa, 401"yetkisiz" bir yanıt verilebilir. RFC 2617 , HTTP'deki kimlik doğrulama desteğini açıklar.

TLS (HTTPS) de bir seçenek olabilir ve diğer tarafın ortak anahtarını doğrulayarak her istekte istemcinin sunucuya doğrulanmasına (veya tersi) izin verir. Ayrıca bu, kanalı bonus olarak korur. Tabii ki, bunu yapmak için iletişimden önce bir anahtar çifti değişimi gereklidir. (Bu, özellikle kullanıcının TLS ile tanımlanması / kimliğinin doğrulanmasıyla ilgilidir. TLS / Diffie-Hellman kullanarak kanalı güven altına almak, kullanıcıyı ortak anahtarıyla tanımlamasanız bile her zaman iyi bir fikirdir.)

Örnek: Bir OAuth jetonunun tam oturum açma kimlik bilgileriniz olduğunu varsayalım. İstemci OAuth jetonuna sahip olduğunda, her bir istekle standart HTTP kimlik doğrulamasında kullanıcı kimliği olarak sağlanabilir. Sunucu ilk kullanımda belirteci doğrulayabilir ve denetimin sonucunu her istekle yenilenen bir yaşam süresi ile önbelleğe alabilir. Kimlik doğrulaması gerektiren herhangi bir istek 401sağlanmazsa geri döner .