OAuth 2.0 Authorization Code Request ve Response

15 Ağu

Authorization Code ile yetkilendirilen uygulamalar Confidential Client türündeki yani sunucu taraflı çalışan uygulamalardır. Bu tür uygulamaların Authorization Server tarafından yetkilendirmesi iki aşamada ve dört basamakta gerçekleşir.

  1. Authorization Request
  2. Authorization Response
  3. Token Request
  4. Token Response

1- Authorization Request

Web uygulaması için gerekli kodu (Authorization Code) elde etmek için Authorization Endpoint’e gönderilen taleptir. Kullanılan parametreler:

  • response_type : Zorunlu parametredir. Alacağı değer “code” olmalıdır.
  • client_id : Zorunlu parametredir. Authorization Server tarafından önceden verilmiştir.
  • redirect_uri : İsteğe bağlı parametredir. İstemci tarafından belirlenir.
  • scope : İsteğe bağlı parametredir Talebin kapsamını belirler.
  • state : İsteğe bağlı parametredir.

2- Authorization Response

Authorization Request sonucunda Authorization Server tarafından uygulamaya dönen cevaptır. Parametreler:

  • code : Zorunlu parametredir. Yetkilendirme kodu.
  • state : Request parametresi olarak belirtilmişse cevapta dönmesi zorunludur.

Authorization Error Response

Authorization sırasında bir hata oluşursa iki durum söz konusu olacaktır.

  1. Kullanıcının yetkilendirilemediği veya tanınmadığı durum. Bu durum geçersiz bir Redirect URI belirlendiğinde veya kullanıcı kimlik bilgileri bilinmediği durumlarda ortaya çıkar.
  2. Kullanıcı doğrulanır fakat başka bir durumdan dolayı hatanın meydana geldiği durum. Bu gibi durumlarda kullanıcıya dönen cevap şu şekilde olacaktır.
  • error : Zorunlu parametredir. Hatanın ne olduğunu belirten mesajdır.
  • error_description : Geliştiricilere bilgi veren isteğe bağlı bir parametredir.
  • error_uri : Hata hakkında bilgi veren bir web sayfasının adresini veren isteğe bağlı parametredir.
  • state : Request sırasında belirlenmiş ise cevapta dönmesi zorunludur.

3- Token Request

Yetkilendirme kodu (Authorization Code) alındıktan sonra uygulama bu kodu access token elde etmek için kullanır. Token elde etmek için token endpoint adresine talepte bulunulur. Access token talebi için parametreler:

  • client_id : Zorunlu parametredir. Authorization Server tarafından önceden verilir.
  • client_secret : Zorunlu parametredir. Authorization Server tarafından önceden verilir.
  • grant_type : Zorunlu parametredir. Alacağı değer “authorization_code” şeklindedir.
  • code : Zorunlu parametredir. Authorization Request ile elde edile koddur.
  • redirect_uri : Eğer Authorization Request sırasında belirlenmiş ise belirtilmesi gereken zorunlu parametredir.

4-Token Response

JSON formatında access token bilgisini veren cevaptır. Cevap parametreleri:

  • access_token : Zorunlu parametredir. Authorization Server tarafından üretilen şifreli bilgidir.
  • token_type : Zorunlu parametredir. Authorization Server tarafından belirlenen token türüdür.
  • expires_in : İsteğe bağlı parametredir. Access token için belirlenen saniye cinsinden geçerlilik süresidir. Süre bittiğinde token artık geçersizdir.
  • refresh_token : Zorunlu parametredir. Access token süresi dolduğunda yeni bir token elde etmek için kullanılacak olan parametredir.

 

OAuth 2.0 Implicit Request ve Response

13 Ağu

OAuth 2.0 protokolünde javascript gibi  Public Client türündeki uygulamalarda access token elde etmek için Token Endpoint adresine talepte bulunulur.

Implicit Request

Implicit yetkilendirme için token talebi için gerekeli parametreler şu şekildedir:

  • response_type : Zorunlu parametredir. Alacağı değer “token” olmalıdır.
  • client_id : Zorunlu parametredir. Authorization Server tarafından önceden verilmiştir.
  • redirect_uri : İsteğe bağlı parametredir. İstemci tarafından belirlenir.
  • scope : İsteğe bağlı parametredir Talebin kapsamını belirler.
  • state : İsteğe bağlı parametredir.

Implicit Response

Imlicit talebine karşılık olarak JSON formatında bir içerik döner.

  • access_token : Zorunlu parametredir. Authorization Server tarafından üretilen şifreli bilgidir.
  • token_type : Zorunlu parametredir. Authorization Server tarafından belirlenen token türüdür.
  • expires_in : İsteğe bağlı parametredir. Access token için belirlenen saniye cinsinden geçerlilik süresidir. Süre bittiğinde token artık geçersizdir.
  • refresh_token : Zorunlu parametredir. Access token süresi dolduğunda yeni bir token elde etmek için kullanılacak olan parametredir.

Implicit Error Response

Authorization sırasında bir hata oluşursa iki durum söz konusu olacaktır.

  1. Kullanıcının yetkilendirilemediği veya tanınmadığı durum. Bu durum geçersiz bir Redirect URI belirlendiğinde veya kullanıcı kimlik bilgileri bilinmediği durumlarda ortaya çıkar.
  2. Kullanıcı doğrulanır fakat başka bir durumdan dolayı hatanın meydana geldiği durum. Bu gibi durumlarda kullanıcıya dönen cevap şu şekilde olacaktır.
  • error : Zorunlu parametredir. Hatanın ne olduğunu belirten mesajdır.
  • error_description : Geliştiricilere bilgi veren isteğe bağlı bir parametredir.
  • error_uri : Hata hakkında bilgi veren bir web sayfasının adresini veren isteğe bağlı parametredir.
  • state : Request sırasında belirlenmiş ise cevapta dönmesi zorunludur.

OAuth 2.0 Protocol Endpoints

10 Ağu

OAuth 2.0 protokolünde tanımlanmış üç adet endpoint vardır. Bunlardan iki tanesi authorization server endpoint, bir tanesi ise client endpoint şeklindedir.

  1. Authorization Endpoint (Server)
  2. Token Endpoint (Server)
  3. Redirection Endpoint (Client)

Endpoint olarak adlandırılan kavram web server üzerinde tanımlanan bir URI adresidir. Protokole dair bağlantılar tanımlanan bu adresler üzerinden sağlanmaktadır.


Authorization Endpoint

Authorization Server üzerinde yetkilendirme amacıyla tanımlanan bir (URI) adrestir. Amacı kaynak sahibinden(Resource Owner) istemci uygulamanın(Client Applicaiton) kaynağa erişebilmesi için yetki alabilmesidir.

Authorization Server öncelikle kaynak sahibinin kimlik bilgilerini doğrular. Ancak kullanıcı kimlik doğrulama işlemi OAuth 2.0 protokolü kapsamının dışında bir işlemdir. Yani kullanıcılar Facebook, Twitter veya Google üzerindeki hesaplar olabileceği gibi şirketinize ait bir veri tabanında da bulunuyor olabilir. Bu durumda doğrulama yükü dış kaynaklı bir sürece dahildir.


Token Endpoint

Authorization Server üzerinde istemci uygulamalara(Client Applicaiton) access token sağlamak amacıyla tanımlanan (URI) adrestir. Uygulama eğer Confidential Client türünde ise doğrulama kodu (authorization code), Client ID, Client Secret gibi bilgiler karşılığında access token bilgisi elde edilir. Eğer Public Client türünde bir uygulama ise kullanıcı adı ve şifre bilgileri ile access token elde edilir.

Güvenli bir ortamda veri alışverişini sağlamak açısından Authorization Endpoint ve Token Endpoint için tanımlanan adresler için TLS(SSL) gerekliliği aranmalıdır.


Redirection Endpoint

Yetkilendirme işlemi gerçekleştiğinde, kaynak sahibinin (Resource Owner) yönlendirileceği bir aderstir (URI). Bu adres Client Applicaiton içerisinde tanımlanmaktadır.

OAtuh 2.0 Authorization Grant Flow

9 Ağu

OAuth 2.0 protokolünde Client Application (istemci uygulama) protokol kapsamında belirlenen bir akış dahilinde Resource Server üzerindeki korunmuş verilere erişebilmektedir. Bu akışa OAuth 2.0 protokolünde protocol flow denir. Bir uygulamanın Resource Server tarafına erişebilmesi için öncelikle Authorization Server tarafından yetkilendirilmesi gerekmektedir. Bu yazıda yetkilendirme adımlarının nasıl gerçekleştirildiği üzerinde durulmaktadır.

Client Application bir Resource Server üzerindeki korunmuş bir veriye erişmek istediğinde ihtiyaç duyduğu yetkiyi Authorization Server üzerinden alır. Bu nedenle yetkilendirilecek olan her Client Application öncelikle  Authorization Server üzerine kaydedilmelidir. Bu sayede hangi uygulamanın yetkilendirilecek uygulama olduğu Authorization Server tarafından bilinir ve belirlenen liste haricindeki uygulamalara geçit verilmez. Uygulamanın Authorization Server üzerine kaydı bir kez gerçekleştirilir ve kayıt silinene kadar uygulama sistemde geçerli kalır.

Bir uygulama Authorization Server üzerine kaydedildiğinde, uygulamaya özel bir Client ID ve Client Secret şeklinde benzersiz iki yetki belgesi verilir. Resource Server üzerinde korunmuş verilere erişmek isteyen her Client Application kendi Client ID ve Client Secret bilgisini Authorization Server üzerinden doğrular. Authorization Server üzerine kaydedilen Client Application için kaydedilen bir diğer parametre ise Redirect URI’dır. Bu parametre Resource Owner için başarılı bir şekilde yetkilendirme gerçekleştirildiğinde yönlendirme yapmak için kullanılır. Örneğin kullanıcı adı ve şifresini doğru giren bir kullanıcının ana sayfaya yönlendirilmesi bu şekilde gerçekleştirilebilir.

OAuth 2.0 teknolojisinde yetki verme işlemi Authorization Grant olarak adlandırılır.

Authorization Grant (Yetki Verme)

Client Application yetkilendirmesi sırasında Authorization Server ile Resource Server işbirliği içerisinde hareket eder.

OAuth 2.0 protokolünde teknik olarak dört farklı yetkilendirme seçeneği bulunmaktadır.

  1. Authorization Code
  2. Implicit
  3. Resource Owner Password Credendials
  4. Client Credentials

Bir uygulamaya yetki verme işlemi sırasında birden fazla adımdan meydana gelen bir dolaşım söz konusudur. Bu dolaşım yada akış OAuth 2.0 teknolojisinde Flow olarak adlandırılır.

Tüm akışlar (flow) her durumda kullanılabilir. Ancak her durum için kullanılması önerilen akışlar vardır. Uygulama türüne göre Web sitesi, mobil uygulama veya javascript uygulamaları için önerilen akışlar vardır. Örneğin native(mobil) ve javascript uygulamaları için implicit flow önerilir.

Authorization Code

Sunucu tabanlı çalışan uygulamalar için yetki verme işlemi Authorization Code tekniği ile gerçekleştirilir. Yani uygulama sunucusu (Client Application Server) ile veri kaynağının bulunduğu sunucu (Reource Server) arasında bir kimlik kontrolü gerçekleştirilir. Bu dolaşımda, Resource Owner tarafında kimlik bilgileri dolaşmaz. Authorization Code yetkilendirmesi Confidential Client türündeki uygulamalarda kullanılır.

authorization-auth-code

  1. Resource Owner(kullanıcı) korunmuş bir kaynağa erişmek üzere uygulamayı(Client Application) açar.
  2. Uygulama kullanıcıya giriş yapması gerektiğini bildiren bir sayfaya yönlendirir. Bu sayfada giriş yapmak için Authorization Server seçenekleri bulunur. Örneğin Facebook, Gmail, Twitter gibi.
  3. Bir seçeneği tercih eden kullanıcı giriş yapabilmesi için Authorization Server üzerinde bulunan login sayfasına yönlendirir. Örneğin Facebook, Gmail, Twitter giriş sayfası. Uygulama sunucusu arka planda Authorization Server tarafına Client ID bilgisini de gönderdiğinden dolayı Authorizaiton Server uygulamayı tanır.
  4. Authorization Server sayfasından kullanıcı bilgileri girilerek login işlemi gerçekleştirilir. Örneğin Twitter ile login işlemi gerçekleştirilir. Login işlemi başarılı bir şekilde gerçekleştirildikten sonra uygulamanın Twitter hesabı ile yetki almasını kabul edip etmediği sorulur. Hatta profil bilgileri, resim bilgileri kullanılsın mı şeklinde işaretlenebilir kutucuklar halinde kullanıcıya seçenekler sunulur. Kullanıcı kabul ederse Client Application’a yönlendirilir.
  5. Client Applicaiton sayfasına yönlendirildiğinde Authorization Server üzerine önceden kaydedilmiş olan Redirect URI adresine yönlendirilir. Yönlendirme ile birlikte Authorization Server tarafından yetkilendirmeyi temsil eden bir doğrulama kodu gönderir.
  6. Redirect URI yönlendirmesi sonrasında Client Application doğrudan Authorization Server ile bağlantı kurar ve doğrulama kodu(authorization code) ile birlikte Client ID ve Client Secret bilgisini gönderir.
  7. Eğer Authorization Server bilgilerin doğruluğunu kabul ederse geriye bir access token gönderir.
  8. Kullanıcı login olduğunu görüntüleyen bir sayfaya yönlendirilir.
  9. Korunmuş bir veri kaynağına erişim talebi yapılır.
  10. CLient Applicaiton daha önce elde ettiği access token ile birlikte Resource Server üzerindeki kaynağı talep eder. Bu kez Resource Server access token doğrulamasını yapmak için Authorization Server ile bağlantı kurar. Token geçerliliği doğrulanırsa kaynaktaki veri uygulamaya gönderilir.

Implicit Grant

Implicit yetkilendirme Authorization Code yetkilendirmeye benzer adımlara sahiptir. Ancak Authorization Code ile yetkilendirme sırasında yetkilendirme kodu sunucu ile Authorization Server arasında dolaşırken Implicit yetkilendirmede yetkilendirmeyi temsil eden access token vardır ve bu access token User Agent(internet tarayıcı) ile Authorization Server arasında dolaşır. Yani yetkilendirme kodu olan access token açık bir ortamda dolaşmaktadır. Bu nedenle Imlicit yetkilendirmeler Public Client türündeki uygulamalarda kullanılır. Örneğin javascript uygulamaları gibi.

Client Application yetkilendirme sırasında sadece Client ID bilgisini Authorization Server’a gönderir. Client Secret bilgisini göndermez. Aksi taktirde bu bilgiler üçüncü şahısların eline geçebilir.

authorization-implicit

Resource Owner Password Credentials

Access token elde etmek için kullanıcı adı ve şifre gibi bilgilerinin doğrudan gönderilerek yetki alma işlemi sırasında kullanılır. Bu yöntem Resource Owner ile Client arasında çok güvenilir bir ortam olduğunda tercih edilmelidir. Aksi taktirde güvenlik riskleri çok yüksek olacaktır.

Client Credentials

Client Credentials yetkilendirme türü kullanılırken uygulama(Client Application) kendine ait kimlik bilgilerini (Client ID ve Client Secret) Authorization Server’a göndererek access token bilgisini elde eder.

Bu tür yetkilendirmeler kullanıcı bilgilerini gerektirmeyen makineler arası haberleşme(machine-to-machine) gibi uygulamalarda tercih edilebilir. Bir makinenin yerine getireceği görevleri bir API üzerinden okuması veya yazması buna örnek olabilir. Ya da kullanıcı iznini gerektirmeyen kaynak kullanımlarında tercih edilebilir.

Client Credentials yetkilendirmesi sadece Client ID ve Client Secret bilgilerini gerekli kılarken, Resource Owner Password Credentials yetkilendirmesi doğrudan kullanıcının şifresini istemektedir.

OAuth 2.0 Protokolündeki Client Türleri

8 Ağu

OAuth 2.0 protokolü ile ilgili bir önceki yazıda OAuth 2.0 rollerini incelemiştik. Bu rollerden Application Client rölü, veri kaynağına erişmek amacıyla yetkilendirilen bir uygulamadır. Bu uygulama OAuth için kısaca Client şeklinde de adlandırılabilir. Veri kaynağına erişmek isteyen uygulamalar Mobil, Web Site, Jvascript/SPA (Single Page Applicaiton) veya Desktop şeklinde bir birinden farklı yapıda olabilmektedir. Altyapı ve işleyiş açısından farklılık arz eden bu uygulamalar için OAuth 2.0 protokolünde özel türler ve profiller belirlenmiştir.

Client Types (Client Türleri)

OAuth 2.0 protokolü için iki tür client tanımlanmıştır.

  1. Confidential (Gizli)
  2. Public (Açık)


Confidential Client kendi kimlik gizliliğini muhafaza edebilen yapıdaki uygulamalardır. Uygulama güvenli bir sunucu üzerinde barındırılır. Kimlik bilgileri Authorization Server tarafından önceden alınır ve uygulamaya kaydedilir verilir. Buna örnek olarak bir web site uygulamasını verebiliriz. Sunucuya yönetici haricinde kimse erişip client şifrelerine ulaşamaz.

Public Client kendi kimlik bilgilerini üzerinde güvenli bir şekilde muhafaza edemeyen uygulamalardır. Örneğin mobil, desktop uygulamaları üzerinde şifrelerin tutulması sakıncalıdır. Uygulamanın kodları bir şekilde kırıldığında kimlik bilgileriniz dolandırıcıların eline geçebilir. Benzer şekilde Javascript uygulamalarında kimlik bilgilerinin tutulması, tarayıcıda kaynağın görüntülenmesiyle ulaşılabilir olduğundan dolayı sakıncalıdır.

Client Profiles (Client Profilleri)

Client uygulamalar için OAuh 2.0 protokolünde üç farklı profili belirlenmiştir.

  1. Web Applicaiton
  2. User Agent
  3. Native

Bu profil bilgileri uygulama altyapısına göre belirlenmiş olup platform bağımsızdır.

Web Application

Web Application profiline sahip uygulamalar sunucu üzerinde çalışan uygulamalardır. Bu tür uygulamalarda sunucu(server) ve istemci(client) şeklinde iki taraf vardır. Sunucu, web sayfasını oluşturan(render eden) taraftır. İstemci ise internet tarayıcısında web sayfasını görüntüleyen taraftır. Örneğin asp.net web forms, asp.net mvc uygulaması veya java jsf uygulaması gibi uygulamalardır.

overview-client-types-1

Bu tür uygulamalar Confidential Client uygulama türündedir. Web Application profilindeki uygulamaların sunucu tarafı admin yetkisinde bulunduğundan bu kısıma üçüncü şahısların dışarıdan erişmesi söz konusu değildir. Eğer bir Web Application üzerinden bir Reource Server’a erişmek isteniyorsa uygulamaya(client) ait kimli bilgileri (id, şifre gibi) sunucu üzerinde tutulur. Böylece kimlik bilgileri gizlenmiş olur.

User Agent

User Agent profilindeki uygulamalar tamamen internet tarayıcısı üzerinde çalışan uygulamalarıdır. User Agent uygulamaları da Web uygulamaları gibi sunucu üzerinde barındırılır. Ancak uygulama, internet tarayıcısına bir kez indirilir ve indirildikten sonra tarayıcı üzerinde çalışmaya başlar. Kaynak (Resource Server) üzerinden ihtiyaç duyulan veriler http, https veya ws gibi protokoller üzerinden talep edilir.

Günümüzde User Agent uygulamalarına en iyi örnek javascript uygulamalarıdır. Bir kaç yıl öncesine kadar Java Flex, Microsoft Silverlight ve Adobe Flash uygulamlar da User Agent açısından önemli bir yere sahipti. Fakat bu tür uygulamaların çalışması için platform bağımlılığını gerektiren bir takım ek yazılımlar gerektiğinden ve mobil cihazlarda uyum sorunu ortaya çıktığından dolayı artık bunların yerine Javascript tercih edilmektedir.

overview-client-types-2

Bu tür uygulamalar Public Client uygulama türündedir. User Agent profilindeki uygulamaların kaynağı internet tarayıcısından görüntülenebildiği için bu uygulamalar üzerinde kullanıcı adı veya şifre gibi kimlik bilgileri muhafaza edilmez.

Native

Native profilindeki uygulamalar, kişisel bilgisayarlar ve mobil cihazlar üzerinde çalışan uygulamalardır. Örneğin Desktop, Android, iOS, Windows Mobile gibi uygulamalar Native profilli uygulamalardır. Bu tür uygulamalar doğrudan cihazlara yüklenerek çalışırlar.

overview-client-types-3

Native uygulamalar Public Client uygulama türündedir. Kişisel cihazlara erişim açık olduğundan dolayı uygulamaların kodlarının kırılması durumunda uygulama kimlik bilgilerine erişmek mümkündür.

OAuth 2.0 Protokolünde Roller

7 Ağu

Bir önceki yazıda OAuth 2.0 protokolünü gelen bakış şeklinde incelemiştik. Bu yazıda OAuth 2.0 protokolüne ait rolleri incelemeye çalışacağız. Protokolde dört farklı rol bulunmaktadır. Bunlar:

Roller aslında protokol dahilinde birbirleri ile haberleşecek olan taraflardır diyebiliriz. Bu taraflar kişi veya uygulamalar olabilir. Yani her bir rolün fiziki veya mantıksal bir karşılığı vardır. Rollerin bu bağlamda topolojik olarak dizilimi aşağıdaki şekilde gösterilmiştir.

overview-roles
Resim Kanak: http://tutorials.jenkov.com/images/oauth2/overview-roles.png

Grafikte ifade edildiği üzere Resource Owner sadece Client Application ile iletişim kurmaktadır. Client Application ise yetki almak için Authorization Server ile, aldığı yetki neticesinde kaynağa erişmek için Resource Server ile iletişim kurmaktadır. Yine grafikte görüldüğü üzere Resource Server ile Authorization Server arasında bir iletişim söz konusudur. Bu iletişim Client Application access token ile Resource Server  tarafına her talepte bulunduğunda access token doğrulamasının yapılması için gerçekleştirilir.

Resource Owner

Reource Owner, verinin sahibi olan kişi veya uygulamadır. Örneğin Facebook veya Instagram kullanıcıları sistemdeki verilerin gerçek sahipleri olduklarından birer Resource Owner’dır. Sunucuların birbirleri ile veri alış verişi yaptığı durumlarda ise Resource Owner bir insan yerine bir uygulama olmaktadır.

Resource Server

Mahrem verinin tutulduğu sunuculardır. Yani veri kaynağı sunucusudur. Örneğin Twitter uygulamasının tweet akışı için yayın yaptığı sunucular birer Resource Server’dır. Her önüne gelen size ait özel bilgileri buradan okuyamaz.

Client Application

Resource Server üzerindeki verilere erişmek üzere talepte bulunan uygulamalara Client Application denir. Örneğin kişisel blog sayfanızda Flickr üzerindeki resimlerinizi yayınlamak istiyorsanız blog sayfanız Flickr uygulaması için Client Application olacaktır. Bu durumda Resource Owner da siz olursunuz.

Authorization Server

Veri kaynağına (Resource Server) ulaşmak isteyen istemci uygulamaları(Client Applications) yetkilendirir. Authorization Server ve Resource Server aynı sunucu üzerinde veya farklı sunucular üzerinde olabilir. Farklı sunucular üzerinde bulunması iletişim açısından teknik olarak bir sorun teşkil etmez.

Bir istemci uygulamanın Authorization Server tarafından yetkilendirilebilmesi için istemci uygulamaya ait adres bilgileri Authorization Server tarafına kaydedilmelidir. Yani Authorization Server, hangi uygulamayı tanıyıp yetkilendireceğini bilmelidir.

OAuth 2.0

5 Ağu

OAuth 2.0 protokolüne genel bir bakış niteliğinde olan bu yazıda uygulama detaylarına girmeden protokolün işleyişi ve karakteristiği incelenmektir. Uygulamalı örnekleri belki daha sonraki yazılarda paylaşma imkanı olabilir.

OAuth protokolü Web , Mobil ve Masaüstü uygulamalarına basit ve standart bir yöntemle uygulamalara güvenli yetkilendirme imkanı sunan açık bir protokoldür. OAuth sayesinde erişim izni sınırlı olan verilerin yani korunmuş verilerin güvenli bir şekilde hizmete sunulması basitleştirilmiştir.

OAuth 2.0 protokolü, OAuth 1.0 üzerinde geliştiricilere yönelik kolaylıklar sağlamak amacıyla yapılan bir dizi düzenlemeler sonrası 2006 yılında ortaya çıkan versiyondur.

OAuth 2.0 uygulamaların birbirleri arasında veri erişimine olanak sağlayan açık bir yetkilendirme protokolüdür. Burada vurgulamak isterim ki OAuth, kullanıcı doğrulama amaçlı değil uygulama yetkilendirme amaçlı bir protokoldür. Bir uygulamanın başka bir uygulama tarafından doğrulanmış kullanıcılara izin vermesidir. Örneğin stackoverflow uygulamasın giren ziyaretçilerin sisteme erişebilmeleri için kişisel Facebook hesapları ile giriş yapanlarına izin verilmektedir.

Günümüzde sosyal medya uygulamalarının bir çoğu (Facebook, Google, Twitter v.s) OAuth 2.0 protokolünü desteklemektedir. Örneğin bir web sitesinin Login seçenekleri arasında Facebook veya Google hesabı ile kullanıcılarına Login seçeneği sunuyor olması bu uygulamaların kullanıcı doğrulama ve uygulama yetkilendirme işlemini OAuth protokolünü kullanarak gerçekleştirmesi sayesinde mümkün olmaktadır.

bootstrap-login

OAuth bir istemci veya sunucu kütüphanesi değildir. Sadece uygulamalar arasında yetkilendirme amacıyla oluşturulmuş bir protokolüdür. Ancak OAuth standardına uygun olacak şekilde çeşitli platformlarda (PHP, Java, .Net, Python, Nodejs, v.s) geliştirilmiş sunucu ve istemci kütüphaneleri mevcuttur. İlgili kütüphanelere buradan erişmek mümkündür.

file-POvDVUfM8H

Bu kütüphaneler sayesinde gerçekleştirilebilecek iki tür uygulama vardır.

  • Birincisi sunucu tarafında oluşturulan bir yetkilendirme uygulaması. Bu uygulama sayesinde siz de bir doğrulama ve yetkilendirme sunucusu oluşturabilirsiniz. Başka uygulamalar da sizin bu uygulamanızı kullanarak tıpkı Facebook ve Google gibi sizin uygulamanız ile yetkilendirme yapabilirler.
  • İkincisi OAuth 2.0 protokolüne uygun bir istemci uygulaması. Bu uygulama ile OAuth 2.0 destekli bir sunucu uygulamasında bulunan kaynağa erişebilirsiniz.

OAurh 2.0 Teknolojisinde Roller

OAuth 2.0 protokolü dahilinde birbirleri ile iletişim kuran taraflar şu şekildedir.

  1. Resource owner
  2. Client Application
  3. Authorization Server
  4. Resource Server

Resource Owner: Bir sistemde bulunan veriye sahip olan kişi veya uygulamadır. Örneğin Twitter uygulamasında hesabınıza girerek paylaştığınız tweet, resim veya videolar size ait birer veridir ve burada Resource Owner siz olursunuz.

Client Application: Resource Owner’ın sahip olduğu verilere erişen uygulamadır.  Eğer kişisel blog sayfanızda size ait tweet’leri paylaşmak istiyorsanız blog sayfanızın Resource Server’a yani Twitter sunucularına erişmeniz gerekir. Bu durumda Client, sizin kişisel blog sayfanız olur.

Authorization Server: Client Application olarak belirlenen uygulamalara yetki veren sunuculardır. Size ait Tweet’leri kişisel blog sayfanıza çekmek istediğinizde Twitter sunucularının sizin blog sayfasını tanıması gerekmektedir. Bu durumda önce sayfanızın adres bilgilerini Twitter sunucularına kaydetmeniz gerekmektedir. Ardından sizin sayfanızdan Twitter sunucularına bir talep gittiğinde uygulamanız yetkilendirilecektir. Bu doğrulamayı ve yetkilendirmeyi yapan Twitter sunucuları OAuth 2.0 protokolündeki Application Server’dır.

Resource Server: Erişilmek istenen korunmuş verilerin bulunduğu yerdir. Örneğin kişisel blog sayfanızda yayınlamak üzere erişmek istediğiniz Tweet’leri sunan Api uçları (endpoints) Reource olarak adlandırılır.

OAuth 2.0 Dolaşım Sistemi (Flows)

OAuth 2.0 protokolünde kullanıcının(client) gerekli olan veriye erişmek amacıyla izlediği yola flow denir. Örneğin access_token veya id_token bilgilerine erişmek bir flow süreci kapsamında gerçekleştirilir. Flow sürecinde, taraflar arasında gerçekleşen dolaşım sistemi (flows) genel olarak şu şekildedir:

slack_oauth_flow_diagram@2x
Resim Kaynağı: https://api.slack.com/docs/oauth

Dolaşım sisteminin başlangıç noktası Resource Owner yani kaynak sahibidir. Reource Owner, yetkilendirme akışını Client Application üzerinden başlatır. Yetki verme (Authorizetion Grant) isteği uygulama üzerinden Authorization Server tarafına aktarılır. Kullanıcı doğrulandığında Client Application tarafına kaynağa erişmek amacıyla bir Access Token gönderilir. Artık Access Token ile Resource Server üzerindeki bilgilere erişmek mümkün hale gelmiştir.

OAuth 2.0 Genel Kavramları

OAuth 2.0 bünyesinde ele alınacak olan genel kavramlar genel başlıklar halinde şöyledir:

  1. OAuth 2.0 Roles
  2. OAuth 2.0 Client Types
  3. OAuth 2.0 Authorization Flows
  4. OAuth 2.0 Authorization Endpoints

OAuth 2.0 protokolü ile ilgili detaylı bilgilere buradan ulaşmak mümkündür.

Nesnelerin interneti (Internet of Things IoT)

30 Tem

Elektromanyetik dalgalar aracılığı ile haberleşme yani Wireless(kablosuz) teknolojisi 1880’lerde başlamıştır. Günümüze kadar ki süreçte bu teknolojinin kullanım alanı ve tercih edilme oranı, ekonomik maliyetlere bağlı olarak farklılık göstermiştir. Kişiler ve kurumlar açısından haberleşmede neyin lüks neyin ihtiyaç olduğu dengesi teknolojinin gelişim süreci içerisinde sürekli değişiklik gösterebilmektedir. Örneğin 15 yıl önce mobil telefon kullananların konuşma dakikalarını hatta saniyelerini bile hesaplarken günümüzde saatlere varan iletişim paketleri bile yetersiz kalabilmektedir.

İnsanlar ve nesneler tarafından üretilen bilgiler ortak bir platform olan internet ortamında birleştirdikten sonra iletişim daha hızlı bir şekilde yaygınlaşmaya başlamıştır. Birim boyuttaki veriler artık daha düşük maliyetlerle taşınabilir olmuştur. Algılayıcı teknolojisinin gelişmesiyle birlikte maliyeti düşük ve boyutu küçük sensörler üretilmeye başlamıştır. Böylece bir nesneye ait teknik verilerin ölçülmesi ve ölçülen verinin transfer edilmesi daha kolay bir şekilde yapılmaya başlamıştır. Artık herhangi bir nesnenin herhangi bir bilgisini internete aktarmak teknolojik olarak kolaylaşmış ve ucuzlamıştır. Artık insanların yanında, nesnelerin de çıktığı bir teknolojiden bahsedilmeye başlanmıştır.

IoT(internet of things) veya Nesnelerin interneti, günlük hayatımızda kullandığımız nesnelerin birbirleri ile haberleştiği iletişim ağıdır.  Bu ağı, insanların kişisel bilgisayar veya akıllı telefonlar ile iletişim kurmak için kullandıkları internet ağından ayıran özellik, düşük enerji ile geniş alanlara erişebilmeyi amaçlamasıdır. Bu özellikteki teknolojiler Low Power Wide Area Netword(LPWAN) olarak isimlendirilmiştir.

Nesnelerin internetinde amaç düşük verileri en uzak mesafelere ulaştırmaktır. Nesnelerden alınacak olan veriler çok düşük boyutlu verilerdir. Örneğin;

  • Bir cihazın çalışır durumda olup olmadığı bilgisi,
  • Evlerimizde herhangi bir kapı ve pencerenin açık olup olmadığı bilgisi,
  • Bir elektrik dağıtım şirketinin abonelerine ait sayaç bilgisi,
  • Cihazların günlük ortalama enerji tüketimi, cüzdanınız ve anahtarınızın gibi değerli eşyaların konum takibi bilgisine kadar sayısız örnekler verilebilir.

İşte bu noktada teknolojik yapılabilirlik ile yönetmeliklerin çarpıştığı, çatıştığı bazı noktalar ortaya çıkmaya başlıyor. Bu çatışmaya günlük hayattan şöyle bir örnek verebiliriz. Kısa mesafede taşımanız gereken 10 kg’lık bir yükünüz var ve zaman konusunda da aceleniz olmadığını düşünün. Bu yükü taşımak için bisiklet kullanmanız halinde düşük bir yatırımla biraz daha uzun zamanda hedefe ulaştırabilirsiniz. Araba kullanmak istediğinizde ise çok daha hızlı bir şekilde bu paketi taşımış olacaksınız. Ancak yüzlerce kilo kapasiteli bir aracı sadece 10 kilo için kullanmanız ve bunun için yakıt sarfiyatı yapmanız bir yana, senelik sigorta, MTV, kasko vs. birçok masrafı da göz önüne almanız gerekecektir. IoT teknolojisinde kullanılan ücretsiz bant ile GSM arasındaki durum bu şekilde ele alınabilir. Düşük boyutlu bilgileri normal GSM teknolojisi üzerinden tarifeli bir şekilde transfer etmek binlerce cihazın kullanıldığı durumlarda yüksek maliyetlere ulaşmaktadır. Ayrıca GSM teknolojileri ile resim, video ve ses gibi yüksek boyutlu verilerin taşınabilmesi amaçlanmıştır. Bu nedenle GSM bant genişliği nesnelerin veri boyutuna göre çok büyüktür.

ddd

GSM teknolojisi kullanıldığında belki MB’larca veriyi çok hızlı bir şekilde aktarma imkanı olacaktır. Ancak her bir hat için satın alma süreci, tesis vergisi, işletme vergisi vb. gibi bürokratik ve mali yükler olacağı gibi haberleşmenin sağlandığı enerji kaynağında da aşırı tüketim söz konusu olacaktır. LPWAN teknolojisinde kullanılan haberleşmelerde küçük bir veriyi daha uzak mesafeye az enerji tüketerek daha ucuza aktarma imkanı olduğundan Nesnelerin İnterneti’nde efektif bir çözüm olarak tercih edilmektedir.

LPWAN teknolojisinde enerji maliyetini düşüren en önemli etken, LPWAN teknolojisinin günün belirli bir zaman aralıklarında haberleşme yapmasıdır. GSM teknolojisinde ise sürekli online bağlantı bulunmaktadır. Bu durum enerji sarfiyatını büyük ölçüde artırmaktadır.

Yaygın Kullanılan IoT Standartları

Nesnelerin interneti için daha düşük bant genişlikleri kullanılarak amaca uygun standartlar belirlenmiştir. Bu standartlardan bazıları şunlardır:

Bu standartların iletişim ağına dair topolojik yapısı benzer şekilde yapılanmaktadır. Bilgisi alınacak olan nesnenin üzerinde iletişim kurmak amacıyla yerleştirilen özel cihazlar bulunur. Bu cihazlar topladıkları bilgileri üzerilerinde bulunan antenler aracılığı ile gateway denen geçiş noktalarına aktarırlar. Burada toplanan bilgiler de ana merkezde bulunan sunuculara aktarılır. Günlük hayatımızda cep telefonlarının baz istasyonları aracılığı ile GSM operatör merkezine veri göndermesine benzer bir mantık işletilmektedir.

LoRa_Technology_Network_Topology

Lora düşük boyutlu verilerin uzun mesafelere ulaştırılmasını amaçlayan 868 bandında iletişim sağlayan bir standarttır. Bölgesel LPWAN çözümleri için idealdir. Örneğin bir şehirde dağılmış vaziyette bulunan nesnelerin bilgilerini toplamak amacıyla herhangi bir kurum kendi LORA altyapısı kurulabilir.

Sigfox iletişim altyapısı merkez bir operatör firma tarafından kurulmaktadır. Şu anda Avrupa’da bir çok ülkede önemli seviyede bir kapsama alanına ulaşmış durumdadır. İletişim sağlayan sensör cihazlar firma tarafından temin edilmekte ve aylık veya yıllık faturalandırma yapılmaktadır. Veri bankası ise merkezi bir bulut sisteminde bulundurulmaktadır.

NarrowBand IoT genelde GSM altyapısına sahip olan kuruluşların lisanslı ve dolayısıyla vergi dahilinde bir iletişim sunan GSM altyapısına alternatif olacak şekilde M2M(machine to machine) teknolojisine dahil teknolojidir diyebiliriz.

IoT Teknolojisinin Kullanım Alanları

IoT teknolojisinin tercih edildiği sektörler,

  • Enerji
  • Taşımacılık
  • Ulaşım
  • Sağlık
  • Tarım
  • Güvenlik
  • Savunma Sanayii

IoT teknolojisinin giderek yaygınlaşan bir teknoloji olmaya başladığı açıktır. Bu anlamda GSM kuruluşlarından kamu kuruluşlarına kadar geniş ve orta ölçekli bir çok kurum bu alanda yatırımlarını arttırmaya başlamıştır.

Visual Studio Code

30 Haz

indirProgramlama dillerinin platform bağımsız bir alana taşınmaya başladığı günümüzde kod geliştirme disiplinleri de baştan aşağı değişiklik göstermektedir. Bir programlama dili ile geliştirme yapmak için her türlü işletim sistemi kullanılabilir olmalıdır. Son bir kaç yılda Microsoft teknolojileri de bu değişime  ayak uydurarak açık kaynak ürünler ve platform bağımsız teknolojiler üretmeye başlamıştır. Microsoft .Net ile artık Mac ve Linux platformlarında geliştirme yapmak mümkün hale gelmiştir. Şu anda (2016 Haziran) Visual Studio Code 1.2.1 sürümü ile yayınlanmıştır.

Adsız

Geliştirme altyapısının platform bağımsız bir yapıya büründüğü Microsoft tarafında geliştirme ortamı da her platformda çalışabilecek bir ürün olan  Visual Studio Code ile desteklenmiştir. Visual Studio Code hızlı, hafif olmanın yanında Microsoft, Linux ve Mac işletim sistemlerinde çalışabilen bir araçtır. Kurulum yapıldığında  basit bir metin editörü görüntüsü ile karşımıza çıkan ürün, eklentiler sayesinde Nodejs, Ruby, Python, C/C++, C#, Javascript gibi bir çok programlama dilini desteklemektedir. Yani klasik Visual Studio ürünleri gibi her şeyi bünyesinde barındırmak yerine çekirdek bir yapı ile başlatılıp lazım olan parçaların eklentiler halinde ürüne eklenmesi sağlanarak mantıklı bir hareket yapılmıştır. Eklentilerin indirilebildiği bir market ortamı oluşturulmuştur.

Visual Studio Code ürününün başlıca özellikleri:

  • Hızlıdır.
  • Platform bağımsız kod geliştirebilmeyi destekler.
  • Code Debugger desteği vardır.
  • Zengin bir kod tanıma(code intellisense) içeriği vardır.
  • Zengin bir kod refactoring desteği vardır.

Windows 10 ve Linux Ubuntu dağıtımında Visual Studio Code kurulumunu ve denemelerini yapsam da henüz Mac versiyonunu deneme şansı bulamadım.

Adsız

ilk izlenimlerime göre klasik Visual Studio 2012,2013 serisinden sonra bu ürünü kullanmak insana ilk başta biraz eziyet gibi geliyor. Çünkü eski alışkanlıklar yüzünde insanın gözü dolu dolu bir IDE arayüzü aramaya başlıyor. Ardından kendinize gelip bunun bir IDE değil editör olduğunu hatırlıyorsunuz.

SSL Güvenlik Protokolü ve SSL Sertifikası

29 Haz

İş dünyasının ve ticaretin internet ortamına taşındığı günden itibaren internetin güvenliği sürekli sorgulanmıştır. Milyonlarca internet site arasından müşteri bilgilerinin güvenliğini ve mahremiyetini sağlayanlar öncelikli olarak tercih edilmiş ve rekabette bir adım önde olmuştur.

İnternet üzerinden yapılan iletişimin güvenliği noktasında iki önemli soruna çözüm bulunmalıdır.

  1. Veri gönderen ve alan tarafın, iletişim süresi boyunca birbirlerini tanıdıklarından emin olmaları gerekir. Alıcı tarafın, üçüncü şahıslar olması durumunda kişisel bilgiler, hesaplar gibi önemli verilerin güvenliği tehlikede demektir.
  2. Alıcı taraf, gönderilen verinin iletişim yolu üzerinde hiç değiştirilmeden geldiğinden emin olmak durumundadır.

Uzmanlar güvensiz ağ üzerinde güvenlik üzerinde kafa yorarak http protokolüne güvenlik mekanizmasını ekleyip https protokolünü oluşturmuşlardır.

  • http: hyper text transper protocol.
  • https: secured  hyper text transper protocol.

HTTP Protokolü

Protokol kavramı bilgisayar dünyasında gerçek hayatta ki sözlük anlamından farksızdır. Günlük hayatta protokoller iki taraf arasında uyulacak kuralları belirlemek amacıyla imzalanan anlaşma metnidir. Bilgisayar dünyasında ise haberleşen taraflar arasında belirlenen dijital iletişim kurallarıdır. Gönderen tarafın ve alıcı tarafın ilgili protokol kurallarına göre veri göndermesi ve alması gerekmektedir. HTTP protokolü sunucudaki 80 numaralı port üzerinden haberleşir.

HTTP protokolü, belli kurallar dahilinde istemci ve sunucu arasında talep/cevap göndermeyi sağlayan bir protokoldür.

https-ranking-signal-02 - Kopya

Örneğin bir tarayıcı sunucuya gönderdiği talepte protokol gereği şunları söyler:

  • Benim metodum GET,
  • Ulaşmak istediğim kaynak URL şudur,
  • QueryString parametrelerim şunlar,
  • Kabul ettiğim Accept-Encoding gzip, deflate
  • Tarayıcı dilim en-EN
  • Tarayıcı bilgilerim şunlar gibi.

HTTP protokolünün kurallarını, sunucu bilgisayar da bildiği için tarayıcının ne söylediğini anlayabilir ve ona göre ilgili kaynaktaki bilgiyi cevap olarak geri gönderir.

HTTP protokolü güvenlik gerektirmeyen bir ağ üzerinde çalışabilmek amacıyla tasarlanmıştır.

HTTPS Protokolü

HTTPS protokolünün oluşturulma amacı güvensiz bir ağ ortamında güvenli bir iletişim yolu oluşturmaktır. Çünkü HTTP protokolü man-in-the-middle diye tabir edilen saldırılara açıktır. Bu tür saldırılarda ağı dinleyen saldırganlar, kişisel hesap bilgilerini ve parolaları kolay bir şekilde ele geçirebilirler. HTTPS bu tür saldırılardan korunmak amacıyla tasarlanmış bir protokoldür. HTTPS = HTTP + SSL şeklinde bir formül ile ifade edebiliriz. HTTPS protokolü sunucudaki 443 numaralı port üzerinden haberleşir.

https-ranking-signal-02

Bir web sitesinde https protokolünün kullanılmasını gerektiren durumlar özetle şu şekildedir.

  • E-ticaret ve ödemek işlemleri gerçekleştirilen sitelerde maddi kayıpları önlemek amacıyla kullanılır.
  • Kişisel hesapların oluşturulduğu sitelerde kişisel verilerin korunması ve kullanıcı güvenliği amacıyla kullanılır.
  • Kullanıcıların kötü niyetli şahıslar tarafından oluşturulan benzer sitelere gitmesini engellemek için bilgilendirmek amacıyla kullanılır.

https ile veri mahremiyeti ve bütünlüğünü sağlamak amacıyla verinin şifrelenmesi ve iletişime geçilen sunucuların güvenliği doğrulanmış olması gerekmektedir. Veri şifrelemesi için doğrulanmış ve güvenilir sunucu sertifikaları kullanılır. Bu sertifikalara SSL sertifikaları denir. SSL sertifikaları, SSL protokolünün bir parçasıdır.

SSL Protokolü

SSL protokolü, ağ üzerinden gönderilen bilginin sadece doğru adreste deşifre edilerek okunabilmesi amacıyla tasarlanmış kriptolama protokolüdür. Protokol kuralları gereği gönderilen bilgi gönderici tarafında şifrelenir, ve sadece ulaşması istenen tarafta deşifre edilmesi garanti altına alınır. Böylece her iki tarafta doğrulamalar yapılarak veri mahremiyeti ve bütünlüğü sağlanmış olur.

ssl

Veri şifrelemede güvenliğin seviyesi şifreleme anahtarının uzunluğuna göre değişir. Örneğin 8 bit anahtar 0-255 arası değerler alacağından 256 olasılık sıra ile denenerek anahtar bilgisi elde edilebilir. SSL protokolünde genelde 128 ve daha fazla bit ile şifreleme kullanılır. 128 bit şifreleme durumda 2128 adet değişik anahtar kullanılmaktadır. 128 bitlik şifrenin çözülmesi için çok büyük yatırım maliyetleri ve çok uzun süre gereklidir.

SSL protokolü ile iletişim kurulabilmesi için SSL sertifikalarına ihtiyaç duyulur ancak olmazsa olmaz bir şart değildir.

SSL Sertifikaları

SSL Sertifikaları, internet işlemlerini güvenli hale getiren veri şifreleme işleminin önemli bir bileşenidir. Sertifikalar, veri gizliliğini ve bütünlüğünü sağlamak amacıyla web sitelerinin kimlik bilgisini doğrulayan dijital belgelerdir. SSL sertifikaları SSL protokolü aracılığıyla kullanıcıların güvenli bir oturum başlatmalarını sağlar. Sertifika olmadan şifreleme anahtarları ve web sitesini tanıtan şirket bilgileri olmayacağından güvenli bir bağlantı sağlanamaz.

Sertifikalar tanınmış resmi kuruluşlar tarafından sağlanır. Bu kuruluşlara Certificate Authority(CA) denir. Sertifika içeriğinde veri şifreleme için kullanılacak olan bir public key ve sertifika veren kuruluş bilgileri bulunur. Sertifika veren kuruluşlar istemci bilgisayarların sertifika depolarında bulunduğundan sunucu ile iletişime geçen bir internet tarayıcısı bize ilgili sitenin sertifikasının güvenilir bir kuruluş tarafından verilip verilmediğini veya geçerli olup olmadığını uyarılar şeklinde belirtir.

HTTPS ile Güvenli İletişimin Adımları

HTTPS protokolü üzerinden bir internet tarayıcısı ve sunucu arasında gerçekleştirilen iletişim adımları şu şekilde gerçekleşir.

https://www.thesslstore.com/blog/wp-content/uploads/2016/02/howsslworks-1.png
https://www.thesslstore.com/blog/wp-content/uploads/2016/02/howsslworks-1.png

 

Adım-1: İstemci internet tarayıcısında https protokolü üzerinden sunucuya bir talep gönderir.

Adım-2: Sunucu kendisine ait şifreleme yöntemini belirten genel anahtarı(public-key) bulunduran bir sertifikayı istemciye gönderir.

Adım-3: İstemci tarayıcısı, sertifikanın:

  • Güvenli bir CA tarafından üretilip üretilmediğini,
  • Sertifikanın hala geçerli olup olmadığını,
  • Sertifikanın ilgili siteye ait olup olmadığını kontrol eder.

Adım-4: Tarayıcı public-key kullanarak rasgele simetrik şifreleme ile bilgileri şifreleyerek sunucuya gönderir.

Adım-5:Sunucu simetrik şifreyi private-key yardımı ile çözerek veriye ulaşır.

Adım-6: Sunucu istemciye html dökümanını şifreleyerek geri gönderir.

Adım-7: İstemcinin internet tarayıcısı şifreyi çözerek html dökümanını görüntüler.