Web Servis ve Kimlik Doğrulama (Authentication) Yöntemleri
1. Web Servis Nedir?
Web servisler, farklı platformların arasındaki iletişimi standardize edilmiş bir takım protokellere ve veri formatlarına göre yapabilmeyi sağlayan yazılımlardır.
Bir Web servisinde, HTTP gibi bir Web teknolojisi orijinal olarak insandan makineye iletişim için tasarlanmıştır. HTML, XML, JSON gibi makine tarafından okunabilen dosya formatlarını aktarmak için kullanılır.
1.1 Web Servis Çeşitleri
Farklı görevlere sahip bir çok web servis teknolojisi vardır. Günümüzde en çok kullanılan bir kaç web servis teknolojine değinelim;
- XML-RPC
- UDDI
- SOAP
- REST
1.1.a XML-RPC
Remote Procedure Call, bir ağdaki çeşitli cihazlar arasında veri alışverişi yapmak için en temel XML protokolüdür. Verileri hızlı ve kolay bir şekilde aktarmak ve diğer bilgileri istemciden sunucuya iletmek için HTTP protokolünü kullanır.
1.1.b UDDI
Universal Description, Discovery, and Integration, web servislerini yayınlamak ve keşfetmek için XML tabanlı bir standarttır.
1.1.c SOAP
Simple Object Access Protocol, dağıtık uygulamalarda ve web servislerinin haberleşmesinde kullanılmak üzere tasarlanan, XML-RPC modelini kullanan, istemci/sunucu mantığına dayalı bir protokoldür. Daha genel olarak SOAP, web üzerinden fonksiyonları kullanmak için geliştirilmiş bir sistemin XML tabanlı kurallar topluluğudur.
Service-Oriented Architecture felsefesini pratiğe uyarlayan iki interface'den biridir. Üzerinde bulunan Universal Description Discovery and Integration (UDDI) ile birlikte hizmet yönelimli mimarinin pratikte kullanılmasını mümkün kılar.
1.1.d REST
REpresentational State Transfer, istemci-sunucu arasında HTTP protokolünü kullanarak veri format kısıtlaması (HTML,XML,JSON,TEXT vb.) yapmadan veri aktarımı sağlayan bir mimaridir. REST mimarisine uygun olan servislere RESTful adı verilmektedir.
2. API Nedir?
Application Programming Interface, bir yazılımın başka bir yazılımda tanımlanmış işlevlerini kullanabilmesi için oluşturulmuş bir tanım bütünüdür. API, Web uygulaması, İşletim sistemi, veritabanı, donanımlar gibi bir çok alanda yazılım kütüphanesi için kullanılabilir.
API'nin istemci-sunucu arasında web uygulamalarında kullanılan tanım haline Web API denir.
2.1 API vs Web Servis
- API bir yazılımdır,Web Servis bir mimari yada web teknolojisidir.
- Her Web Servis bir API olabilir ama her API bir web servis olamaz.
- API herhangi bir standarta bağlı olmadan oluşturulabilir. Web Service, RFC standartlarını kullanır.
3. Web API'lerde Doğrulama (Authentication)
Web API üzerinden yetkisiz erişimleri engellemek için istemci-sunucu arasında bir birini tanıma işlemini yapabilmek için Authentication yöntemleri kullanır.Günümüzde birçok farklı mimaride ve teknolojide Authentication yöntemleri vardır.
Biz bunlardan birkaç tanesine değineceğiz;
- Basic
- Bearer (Token)
- OAuth2
- HMAC
3.1 Basic Authentication
HTTP protokolü üzeride ki header alanı üzerinden istemci'den sunucuya iletilen BASE64 ile encode edilmiş bir veri ile kimlik doğrulama işlemidir.
HTTP Request Header :
Header_Name : Basic BASE64({VERI_I}{AYRAÇ}{VERI_II})
Basic Authentication istemci-sunucu arasında encode/decode işlemi BASE64 ile yapıldığı için çözülmesi kolaydır.
- HTTPS ile iletilmesi tavsiye edilir.
- Public (Herkese Açık) API uygulamalarında kullanılmaması tavsiye edilir.
- İstemci tarafından oturum kapatma işlemi bu yöntem ile yapılamaz.
- Oturum süresi, oturum durumu gibi istemci tarafı bilgiler bu yöntem ile işlenemez.
- Standart halinde `Authentication` adı altından HTTP Request Header ile Basic kelimesi ,boşluk ve veri halinde gönderilmesi tavsiye edilir.
- Bu yöntem ile kimlik verileri her istekde gönderilir.
3.1.a Digest Authentication
HTTP Digest Authentication, Basic Authentication'daki parolanın güvensiz ortamda karşı tarafa gönderilmesi problemini çözmek üzere ortaya çıkmıştır. Burada istemci parolanın kendisini göndermek yerine parolanın Digest'ını (Hash) alarak sunucuya gönderir. Parolanın kendisi ya da Hash'i sunucu tarafında da tutulduğu için sunucu isteğin kimden geldiğini doğrulayabilir. Bu yöntemin iletim katmanı şifrelenmemiş bir ortamda kullanılması durumunda kötü amaçlı kişilerin parolayı öğrenemese bile Hash'ini öğrenebileceği öngörülmüştür.
3.2 Bearer Authentication
Bearer kimlik doğrulaması (ya da token bazlı doğrulama), Bearer olarak adlandırılan kimlik doğrulama alanları içeren bir HTTP kimlik doğrulama şemasıdır.Belirli bir kaynağa veya URL'ye erişime izin veren kimlikler genellikle bir oturum açma isteğine yanıt olarak sunucu tarafından oluşturulan şifreli bir dize veridir.
Authorization: Bearer <token>
İstemci-sunucu arasında bir kez kimlik doğrulama yapıldıktan sonra sunucu tarafından istemciye bir şifreli veri verilir, bu veri ile istemci her isteğinde sunucu tarafından kimlik doğrulması yapabilir bu şekilde istemci her seferinde güvenlik verilerinin gönderilmesinin önüne geçilir.
İstemci bir sunucuya kendisini doğrulattıktan sonra kendisine (MAC, IP veya bazen ikisi de alınarak ya da başka veriler ile) ait benzersiz(unique) bir anahtar oluşturulur ve bu anahtar ile sonraki işlemlerinde kendisini sisteme doğrulatır. Bu doğrulama esnasında ilgili anahtar farklı şekillerde gönderilebilir.
Bu yöntemler günümüze kadar HTTP üzerinden;
- Body (Gövde) içinde bir alan olarak,
- Header içerisinde (Authorization: Apikey BFEBFBFF000506E3-QCQRL1061100G3),
- Basic içerisinde (Authorization: Basic BFEBFBFF000506E3-QCQRL1061100G3),
- Query String (?apikey=BFEBFBFF000506E3-QCQRL1061100G3) şeklinde gönderildiği gözlenmiştir.
Bu yöntem üzerinden oluşturulan şifreli veri istemci üzerinden saklanması gerekmektedir.
- Kullanımı ve uygulaması kolay olduğu için çokça tercih edilir.
- Her istek ile sunucu tarafından işlem yükü oluşur.
- İstemci tarafından saklandığı için üçüncü kişiler tarafından ele geçirebileceği unutmamalıdır.
- Şifreleme işlemlerini günümüzde kullanılan,standartlaşan ve açık kaynaklı yöntemler ile yapılması tavsiye edilir.
- Oluşturulan şifreli veri içerisine `zaman-aşımı`,`oturum süresi` gibi veriler koyularak oturum durumunu yönetebilirsiniz.
3.2.a JWT Token
JSON Web Token, istemci-sunucu taraflarının birbirleri arasındaki veri alışverişini ve bunun doğrulamasını sağlayan JSON tabanlı RFC 7519'de tanımlanmış açık bir standarttır.
JWT üç ana bölümden oluşur ve her bölüm "."(nokta) ile ayrılır;
- Header
- Oluşturulan Token ile ilgili şifreleme algoritmasını ve tipini tutar
- Payload
- İçine vereceğimiz her türlü veriyi tutar
- Signatıre
- Token ile ilgili doğrulama bilgisini tutar
BASE64({JSON_HEADER}).
BASE64({JSON_PAYLOAD}).
{ŞİFRELEME_YÖNTEMİ}(BASE64(JSON_HEADER) + "." + BASE64(JSON_PAYLOAD), {SECRE_KEY})
JWT sunucu tarafından kimlik bilgileri ile üretilip içerisine veri konularak istemci tarafına gönderilir. İstemci JWT içerisinde ki veriyi okuyup işleyebilir ama SECRET olmaksızın işlemlerini yapar.
- Stateless çalışır. İstemci ya da sunucu tarafında oturum ile bilgiler tutulmaz , istenilen her bilgi JWT içerisine konulmalıdır.
- Portable çalışır. Encode ya da decode işlemi açık kaynaklı olduğu için her türlü platform üzerinden oluşturulup kullanılabilir.
- Veriler JSON formatı ile tutulur.
- Token'nın HEADER ve PAYLOAD alanları herhangi bir şifreleme işlemi uygulanmaz bu yüzden PAYLOAD alanına önemli veriler konulmamalıdır.
- JWT üzerinden `zaman aşımı-sona erme zamanı` gibi bilgiler tutulduğu için oturum zamanı yönetimi sağlanabilir.
- Sunucu tarafından her hangi bilgi tutulmadığı için sunucu yükü azalır.
3.3 OAuth
Open Authentication açık standartlı bir yetkilendirme protokolüdür; doğrulama ve yetkilendirme işlemlerini bir bütün haline getirip doğrulama işlemlerini daha modüler bir yapı ile birbiriyle ilişkisi olmayan sunucu ve/veya sistemlerin birbirleri arasında kullanıcıların doğrulanması için iletişim kurmasını sağlayan bir framework (iş çatısı) ve protokoldür.
İki farklı versionu vardır (OAuth 1.0 ve OAuth 2.0) , Bu versionlar mimari olarak bir birine benzerdir ama kullanım olarak tamamen farklıdır. Günümüzde güncel olarak OAuth2 verison'u kullanılmaktadır.
Mimari olarak farklı bölümlerde farklı işlemler yapılarak tanımlanmıştır:
- Resource owner
- Client Application
- Authorization Server
- Resource Server
Uygulamanızın yapısına göre bu bölümlerin bazıları birleştirilebilir.
Kısaca akış:
- İstemci işlem yapmak istediği veri için "Resource Owner"'dan izin ister.
- Resource Owner izin verdikten sonra istemci "Authorization Server" istek atarak doğrulama için erişim kimliği(Access Token) ister.
- İstemci erişim kimliği(Access Token) ile "Resource Server" istek atarak işlemlerini yapar.
Detaylı bilgilendirme için bakınız : Wikipedia Digest , OAuth Web Site
3.3.a OpenId Connect
OpenId 1.0, OAuth2 protokolü üzerine kurulmuş basit bir kimliklendirme katmanıdır. İstemci uygulamaların için bir Authorization Server tarafından son kullanıcı kimlik doğrulaması yapmasının yanı sıra REST benzeri bir yapı ile son kullanıcının basit profil bilgilerini elde etmesini sağlar
OpenId Connect, Web tabanlı, mobil ve JavaScript istemcileri de dahil olmak üzere bir dizi istemcinin kimliği doğrulanmış oturumlar ve son kullanıcılar hakkında bilgi istemelerine ve almalarına olanak tanır.
3.4 HMAC
Hashing Message Authentication Code, kriptografik özet fonksiyonu ve gizli bir kriptografik anahtar içeren bir mesaj doğrulama kodu türüdür. Diğer MAC türleri gibi, HMAC de hem veri bütünlüğünü kontrol etmek hem de mesaj içeriğini onaylamakta kullanılabilir.
HMAC aslında bir kriptografik mesaj doğrulama yöntemidir ama biz kullanıcı bilgisi olmadan kullanılan Web Servis'lerde kimlik doğrulama olarak kullanıyoruz.
Burada istemci ve sunucu tarafından birbirinden bağımsız olarak iki hash'lenmiş veri(key) üretilir ve eğer iki veri bir birine eşleşirse kimlik doğrulama yapılır
Örnek olarak;
"/get-news" Web Servis'ine istemci üzerinden istek atıp işlem yapmak istiyoruz
İstemci
- İstek atacağı Web Servis'i ve verilerini belirler. (URL : "/get-news" , Body Data : "id:1")
- Sunucu tarafından okunabilicek veriler ile HMAC işlemi yapılır.
- HMAC("{URL}:{BODY_DATA}:{UTC_TIME}",{SECRET_KEY})
- İstemci HMAC sonucunda üretilen hash'lenmiş veriyi(key) HTTP ile sunucuya gönderir.
Sunucu
- İstemci tarafından gelen isteği alır
- İstek üzerinden veriler okunur
- Okunan veriler ile HMAC işlemi yapılır (Request URL : "/get-news" , Body Data : "id:1")
- HMAC("{URL}:{BODY_DATA}:{UTC_TIME}",{SECRET_KEY})
- İstemcinin gönderdiği şifrelenmiş veri ile sunucu tarafından oluşturulan hash'lenmiş veri (key) eşleşirse sunucu isteği kabul eder.
Burada ki HMAC algoritması ve içindeki veriler her iki tarafında birbirinden bağımsız olarak anladığı veriler olduğu sürece istenildiği gibi değiştirile bilinir.(Url,Body,HTTP Method,UTC Time vb.)
- Kullanıcı bazlı Web Servislerde diğer yöntemlerin kullanılması tavsiye edilir.
- Zamansal bir veri kullanılarak şifrelenmiş veri (key) benzersiz hale getirilebilir.
- Her iki taraftada şifrelenme işleme yapılacağı için istemci tarafından SECRET verisinin ve HMAC algoritmasının oldukça karmaşık ve gizli hale getirilmesi tavsiye edilir.
- Zamansal bir ifade ile sunucu tarafından "zaman aşımı-sona erme zamanı" oturum durumları kullanılabilir.
4. Seneryolar
Günümüzde bir çok kimlik doğrulama yöntemi mevcuttur. Projenin ya da uygulamanın yapısına göre tercih edilebilir.
4.1 İnternete Kapalı Projeler
Bu proje tipleri genellikle kurum içi projelerdir. Bu tip projeler BASIC Authentication yöntemini kullanabilinir.
- Kullanımı ve entegrasyonu kolaydır.
- Kurum içi olduğu için üçüncü kişiler tarafından erişilemeyeceği garanti altındadır.
- Platform desteği yoksa bile kendimiz yazabiliriz.
4.2 İnternete Açık Kullanıcı Bazlı Projeler
Bu projeler bir çok yöntem kullanılabilinir. Eğer proje katmanlı ve kırılımlı ise OAuth2 yöntemi kullanıla bilinir.
- Kullanımı ve entegrasyonu zordur.
- Kırılımı çok olan projeler için ortak kimlik doğrulama sağlar
- Oturum ve kullanıcı yönetimi kapsamlıdır.
Eğer tek katmanlı bir proje ise Bearer (Token) ya da Digest Authentication yöntemleri kullanıla bilinir.
- Kullanımı ve entegrasyonu kolaydır.
- Oturum ve kullanıcı yönetimi yeterlidir.
- Tüm platformlar üzerine uygulana bilinir.
4.3 İnternete Açık Kullanıcı Olmaksızın Projeler
Bu proje tipleri güvenlik ve kimlik doğrulamalarının en zor hali olan projelerdir çünkü bu proje genel kullanımı açık ve kullanıcı bazlı değillerdir o yüzden sunucu taraflı işlemlerin üçüncü taraf kişiler tarafından zarar verilmemesi için ek önlemler alınması gerekir. Bu tip projeler HMAC ya da Bearer (Token) yöntemleri çokça tercih edilir.
Teşekkürler ,çok yardımcı oldu.
YanıtlaSilBu konular ile ilgili bir şeyelr biliyordum fakat bazı şeyler muallakta kalıyordu. Çok güzel bir anlatımınız var şuan herşey aklımda daha net oturdu. Teşekkürler.
YanıtlaSil