RESTful Client-Server mimarisinde kimlik doğrulamanın nasıl ele alınacağı bir tartışma konusudur.
Genellikle, HTTP dünyası üzerinden SOA'da şu yollarla elde edilebilir:
- HTTPS üzerinden HTTP temel yetkilendirme;
- Çerezler ve oturum yönetimi;
- HTTP üstbilgilerinde belirteç (ör. OAuth 2.0 + JWT);
- Ek imza parametreleriyle Sorgu Kimlik Doğrulaması.
Yazılım mimarinize en iyi şekilde uyması için bu teknikleri uyarlamanız veya daha iyi karıştırmanız gerekir.
Her kimlik doğrulama düzeninin, güvenlik ilkenizin ve yazılım mimarinizin amacına bağlı olarak kendi PRO'ları ve CON'ları vardır.
HTTPS üzerinden HTTP temel yetkilendirme
Standart HTTPS protokolünü temel alan bu ilk çözüm, çoğu web hizmeti tarafından kullanılır.
GET /spec.html HTTP/1.1
Host: www.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Uygulanması kolaydır, varsayılan olarak tüm tarayıcılarda bulunur, ancak Tarayıcıda görüntülenen korkunç kimlik doğrulama penceresi gibi devam eden (burada LogOut benzeri bir özellik yoktur) gibi bazı dezavantajları vardır, bazı sunucu tarafı ek CPU tüketimi, ve kullanıcı adı ve parolanın (HTTPS üzerinden) Sunucuya iletilmesi (parolanın klavye girişi sırasında yalnızca istemci tarafında kalması ve Sunucuda güvenli karma olarak saklanması daha güvenli olmalıdır) .
Özet Kimlik Doğrulaması kullanabiliriz , ancak MiM veya Tekrar saldırılarına karşı savunmasız olduğu ve HTTP'ye özel olduğu için HTTPS de gerektirir .
Çerezlerle Oturum
Dürüst olmak gerekirse, Sunucu'da yönetilen bir oturum gerçekten Vatansız değildir.
Bir olasılık, çerez içeriğindeki tüm verileri korumak olabilir. Ve tasarım gereği, çerez Sunucu tarafında işlenir (İstemci, aslında, bu çerez verilerini yorumlamaya bile çalışmaz: sadece ardışık her istekte sunucuya geri verir). Ancak bu çerez verileri uygulama durumu verileridir, bu nedenle istemci, durumu yalnızca Vatansız bir dünyada değil sunucuda yönetmelidir.
GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123
Çerez tekniğinin kendisi HTTP'ye bağlıdır, bu nedenle protokolden bağımsız olması gereken RESTful değildir, IMHO. MiM veya Replay saldırılarına karşı savunmasızdır .
Token (OAuth2) aracılığıyla verildi
Alternatif olarak, HTTP kimliklerinin içine bir istek koymak, böylece isteğin kimliği doğrulanır. Bu nedir OAuth 2.0 örneğin yapar. RFC 6749'a bakın :
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer mF_9.B5f-4.1JqM
Kısacası, bu bir çereze çok benzer ve aynı sorunlardan muzdariptir: vatansız değil, HTTP iletim ayrıntılarına güvenen ve MiM ve Replay dahil olmak üzere birçok güvenlik zayıflığına maruz kalan sadece HTTPS üzerinde kullanılmalıdır. Tipik olarak, bir JWT token olarak kullanılır.
Sorgu Kimlik Doğrulaması
Sorgu Kimlik Doğrulaması, her RESTful isteğini URI üzerindeki bazı ek parametrelerle imzalamaktan oluşur. Bkz bu referans makalesine .
Bu makalede şöyle tanımlanmıştır:
Tüm REST sorguları, imza belirteci olarak özel kimlik bilgileri kullanılarak küçük harfli, alfabetik sırayla sıralanmış sorgu parametreleri imzalanarak doğrulanmalıdır. İmzalama, sorgu dizesini kodlayan URL'den önce yapılmalıdır.
Bu teknik belki de Stateless mimarisiyle daha uyumludur ve hafif bir oturum yönetimi ile de uygulanabilir (DB kalıcılığı yerine bellek içi oturumlar kullanılarak).
Örneğin, yukarıdaki bağlantıdan genel bir URI örneği:
GET /object?apiKey=Qwerty2010
şu şekilde iletilmelidir:
GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789
İmzalanan dize /object?apikey=Qwerty2010×tamp=1261496500ve imza, API anahtarının özel bileşenini kullanarak bu dizenin SHA256 karmasıdır.
Sunucu tarafı veri önbelleği her zaman kullanılabilir. Örneğin, bizim çerçevemizde, yanıtları URI düzeyinde değil, SQL düzeyinde önbelleğe alıyoruz. Bu yüzden bu ekstra parametreyi eklemek önbellek mekanizmasını bozmaz.
JSON ve REST tabanlı istemci-sunucu ORM / SOA / MVC çerçevemizde RESTful kimlik doğrulaması hakkında bazı ayrıntılar için bu makaleye bakın . Yalnızca HTTP / 1.1 üzerinden değil, aynı zamanda kanallar veya GDI iletileri (yerel olarak) olarak da adlandırdığımız için, HTTP özgünlüğüne (başlık veya çerezler gibi) gerçekten RESTful bir kimlik doğrulama modeli uygulamaya çalıştık.
Daha sonra Not : URI'ye imza eklemek kötü bir uygulama olarak görülebilir (örneğin, http sunucu günlüklerinde görüneceğinden), örneğin yeniden oynatmaları önlemek için uygun bir TTL tarafından azaltılması gerekir. Ancak http günlükleriniz tehlikeye girerse, kesinlikle daha büyük güvenlik sorunlarınız olacaktır.
Uygulamada, OAuth 2.0 için yaklaşan MAC Jetonları Kimlik Doğrulaması "Jeton Tarafından Verildi" mevcut şemasında büyük bir gelişme olabilir. Ancak bu hala devam eden bir çalışmadır ve HTTP iletimine bağlıdır.
Sonuç
Uygulamada çoğunlukla HTTP üzerinden uygulansa da REST'in sadece HTTP tabanlı olmadığı sonucuna varmak gerekir. REST diğer iletişim katmanlarını kullanabilir. Dolayısıyla RESTful kimlik doğrulaması, Google'ın verdiği yanıt ne olursa olsun sadece HTTP kimlik doğrulaması ile eşanlamlı bir eş anlamlı değildir. HTTP mekanizmasını hiç kullanmamalı, ancak iletişim katmanından soyutlanmalıdır. Ve HTTP iletişimi kullanıyorsanız, Let's Encrypt girişimi sayesinde , herhangi bir kimlik doğrulama düzenine ek olarak gerekli olan HTTPS'yi kullanmamanın bir nedeni yoktur.