şükela:  tümü | bugün
  • oauth 1.0'dan çok daha basit bir protokole sahip, kodlanması birkaç kat daha kolay, yine de aynı güvenliği verebilen web tabanlı yetkilendirme protokolü. browserınızdan elle bile debug edebiliyorsunuz. facebook, foursquare falan bunu kullanıyor.

    oauth 1.0'a kiyasla, verilen access_token'i bi kere aldiktan sonra kaptirmamaniz lazim kimseye. cunku son adimda verilen access_token imzalanmaya gerek duymadan kullaniliyor. iyi saklamak lazim.
  • scribe adinda guzel bir open source java library'si de bulunmaktadir. suradan indirilebilir.
  • oauth 1.0'da boyna aldigimiz biseyleri hmac ile imzalayip yolluyorduk, hem client hem server tarafinda bos yere implementasyonda zaman kaybediyorduk. oauth 2.0'da boyle seyler yok, cok basit isliyor. hemen birkac ornekle aciklayalim.

    1) authorization

    kullaniciyi example.com/oauth2/authenticate?response_type=code&client_id=xxxxxxxxx&redirect_uri=callback_adresiniz_urlencoded sayfasina yonlendiriyorsunuz. sonra hedef site kullaniciya soruyo kanka napalim diye, onay verilirse sizin callback adresinize ?code=zzzzzz seklinde bi donus yapiliyor.

    2) access_token alma

    callback adresinize gelen code parametresini access_token'la degistirmek icin servera request yapmalisiniz. example.com/oauth2/access_token?grant_type=authorization_code&client_id=xxxxxxxxx&client_secret=xxxxxxxxxxxxx&code=zzzzzzz dediginiz anda size soyle bir json cevap gelir: {"access_token": "zaaaaaa"} (baska seyler de gelebilir ama access_token zorunlu)

    3) endpointleri kullanma

    aldiginiz access token'la api'in butun endpointlerine ?access_token=zaaaaaa diyerek erisebilirsiniz. aman kaptirmayin milletin access_token'ini, gidip client_secret'inizi resetleyip butun issued tokenlari invalidate etmek zorunda kalsiniz olm.

    can alici nokta: server tarafiyla yapilan butun iletisimde ssl (https) zorunlu tutun.
  • oauth 1.0'da var olan signing ve client verification gibi guvenlik ozellikleri barindirmaz. bunlarin tamamini ssl/tls'e havale eder.
  • spec'inin hazirlanma surecinde guvenlik endiselerinin yeterince karsilanmamasi ve fikir anlasmazliklari sebebiyle protokolun orijinal yazari eran hammer'in spec'lerden adini sildirmesi ve ayrilmasi hakkinda:

    http://hueniverse.com/…th-2-0-and-the-road-to-hell/
    http://hueniverse.com/2012/07/on-leaving-oauth/
  • protokolü rfc 6749'de açıklanmıştır... okumak için http://tools.ietf.org/html/rfc6749
  • bunun bir de jwt ile yapilan two-legged olan bir akisi var. ama rfc'de bahsedilmiyor. sunucudan sunucuya olan isteklerde kullaniliyor (client delegation degil yani). private key onceden elinizde oluyor ve bunu sha256 ile imzalayarak bir assertion olusturuyorsunuz. bu assertion ile istek atilabiliyor. kisacasi authorization adimina gerek yok. google cloud gce veya gae disindan atilan servis request'leri icin bu yaklasimi kullandiriyor. zaten google bunu implicit yapan kutuphaneleri sagliyor.

    ha olur da benim gibi kendiniz implement etmeye kalkarsaniz, bir api spec standardi bulunmuyor; kodu generate ettiremiyorsunuz mesela swagger ile. rfc'de gecen 4 flow var two legged oauth bunlardan biri degil. referans olarak burasi kullanilabilir.
  • her api-based projemde kullandığım protokol. acaba bugün ne giysem derdi olanlar için şöyle güzel bir şema ile hangi tipte uygulanacağı seçilebilir.

    görselin bulunduğu makale: https://alexbilbie.com/guide-to-oauth-2-grants/