OAuth Nedir?

OAuth, kullanıcı deneyimini iyileştirmek ve güvenlik sağlamak amacıyla oluşturulmuş bir yetkilendirme protokolüdür. Açık standartlı olarak çalışmaktadır ve kullanıcının parolasına erişim sağlamadan 3. parti uygulamadan sağlanan “token” ile hedef web uygulamasında kullanıcının oturum açabilmesine olanak tanır. OAuth bir API değil, bir standarttır ve günümüzde 2 versiyonu bulunmaktadır; OAuth 1.0 ve OAuth 2.0. İkisi birbirinden tamamen farklı teknolojiler olup artık yaygın olarak OAuth 2.0 kullanılmaktadır.

OAuth ve API Arasındaki İlişki

Teknolojinin gelişmesine bağlı olarak geliştiriciler web uygulamaları için oluşturdukları verileri masaüstü ve mobil cihazlarda da kullanmak istediler. Bu soruna da “API” ile çözüm buldular. Birçok sistemle etkileşimde olması gereken API’ların sadece gerekli sistemleri güvenmesi gerekiyordu, bu durum da her seferinde kullanıcıdan kimlik bilgilerini almayı gerektiriyordu. Her seferinde kullanıcı kimlik bilgilerini kullanmayı engellemek ve mevcut güvenliği artırmak için API’lar ile etkişime geçilirken de OAuth protokolü kullanılmaya başlandı.

OAuth, uygulamalara sadece gerekli yetkilerle ihtiyaç duyduklar kaynaklara kullanıcının parolasını almadan erişebilme özelliği kazandırdı. Okta‘da bu durum “otel kartı” örneği ile açıklanmaktadır. OAuth’u otel kartı olarak düşünebiliriz. Resepsiyon ile görüşüp kimliğimizi doğruladıktan sonra otelin tüm kaynaklarına erişim için bir kart alırız…

 

OAuth’un Bileşenleri

OAuth bileşenleri temelde 6 adettir:

• Kapsam
• Aktörler
• Client sistem
• Token
• Yetkilendirme sunucusu
• OAuth akışı

 

OAuth’un Kapsamı

Kapsam, OAuth protokolünün erişim sağlayacağı hakları ifade eder. Örneğin bir web uygulamasında oturum açarken o web uygulamasının ihtiyaçlarına bağlı olarak OAuth protokolü vasıtasıyla Google profilinize, e-posta adresinize ve lokasyon bilginize erişim hakkı verebiliriz. Web uygulamasının erişim sağladığı haklar, OAuth protokolünün kapsamında yer alan verilerdir.

 

OAuth Aktörleri

OAuth’un aktörleri protokolün kullanımı sırasında etken şekilde faliyet gösteren objelerdir:

• Kaynak Sahibi: Kaynak sunucusunda ilgili veriye sahip olan kişi. Örneğin ben WordPress’de kendi hesabımın “kaynağının sahibi”yim.
• Kaynak Sunucusu: OAuth protokolünü kullanarak kaynak sahibinin verisine erişim sağlanmak istenen sunucu. Örn: WordPress sunucusu.
• Client: Kullanıcının verisine erişim sağlamak isteyen 3. parti web uygulaması. Örneğin Gravatar, Gravatar’da oturum açmak için WordPress ile oturum aç seçeneğini kullanabiliriz.
• Yetkilendirme Sunucusu: OAuth protokolünün çalıştığı sunucu. OAuth sağlayıcısı… Bizim örneğimizde bu WordPress.com oluyor.

 

OAuth Token’ları

OAuth’da yer alan token’lar client sistemler tarafından kaynak API’ına erişim sağlamak amacıyla kullanılırlar. Bu tokenlar kısa vadeli olup bir süre sonra otomatiken devre dışı kalırlar.

OAuth token’ları olarak günümüzde güvenilir ve güvenli olarak kabul gören Json Web Token (JWT)’ler kullanılır.

OAuth Token’ları kısa süreli tokenlar oldukları için sürekli güncellenmeleri gerekmektedir. OAuth Token’ları temelde şu şekilde çalışır:

• OAuth protokolü gereği oluşturulan access token ile yetki alınır,
• Süresi dolan access token, refresh token ile değiştirilir,
• Refresh token artık access token olarak ayarlanır,
• Yeni access token’ın süresi dolduğunda 2. adıma yeniden dönülür.

 

OAuth Token etkileşimini bir örnekle açıklayalım:,

1. OAuth işlemi için kaynak sahibi bir OAuth akışı başlatır.
2. Client, yetkilendirme isteğini ihtiyacı olan kapsamı belirterek tarayıcı üzerinden Yetkilendirme Sunucusu (Authorization Server)’nda yer alan Yetkilendirme Uç Noktası’na gönderir.
3. Yetkilendirme Sunucusu kullanıcının bu durumu onaylayıp onaylamadığını sorar.
4. Yetkilendirme talebi kullanıcı tarafından onaylanınca sunucu cevabı uygulamalya iletir.

 

Örnek olarak Gmail hesabını kullanarak kullanıcıyı yetkilendirmek isteyen bir uygulama tarafından Google’a yapılan istek şu şekildedir:

GET https://accounts.google.com/o/oauth2/auth?scope=gmail.insert gmail.send
&redirect_uri=https://app.example.com/oauth2/callback
&response_type=code&client_id=812741506391
&state=af0ifjsldkj

• scope: OAuth kapsamında kullanılacak yetkiler
• redirect_uri: Yetkilendirme işlemi sonracı dönülecek uygulama adresi
• response_type: OAuth akışını değiştirmek için beklenen cevap türü.
• client_id: Yetkilendirilecek kullanıcı sistemin ID değeri, bu id değeri yetkinin kullanılacağı uygulama için geçerlidir.

 

Yukarıda beliritlen isteğe Google’dan dönen yanıt ise şu şekildedir:

HTTP/1.1 302 Found
Location: https://app.example.com/oauth2/callback?
code=MsCeLvIaQm6bTrgtp7&state=af0ifjsldkj

• code: İstekte belirtilen ve OAuth süreci için kullanılmak istenen kod, yetkinin verildiğini ifade eden değer.
• state: Sonucun sahte olmadığını ifade eden değer.

 

Yukarıda bahsedilen istek-cevap akışı OAuth sürecinin Ön Kanal (Front Channel) tarafında yer alan akıştır. Şimdi de arkada olup biteni inceleyelim.

Client sunucu, Yetkilendirme Sunucusu (Authorization Server)’na bir Access Token isteği gönderir ve bu istekte client’a ait kimlik bilgileri ve client id değerini belirtir.

Bu işlem yapılırken yetkinin alınacağı (yetkilendirme sunucusuna) sunucuya atılan istek şu şekildedir:

POST /oauth2/v3/token HTTP/1.1
Host: www.googleapis.com
Content-Type: application/x-www-form-urlencoded

code=MsCeLvIaQm6bTrgtp7&client_id=812741506391&client_secret={client_secret}&redirect_uri=https://app.example.com/oauth2/callback&grant_type=authorization_code

Yukarıda belirtilen istekte yer alan grant_type parametresi ile bir authorization kodu beklenildiği ifade edilir. Bu isteğe sonuç olarak yetkilendirme sunucu eğer ön kanalda kullanıcı talebi onayladıysa aşağıdaki yanıtı döner:

{
  "access_token": "2YotnFZFEjr1zCsicMWpAA",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA"
}

Yanıtta yer alan acess_token’i kullanan bir istemci artık bu token sayesinde korunan içeriğe erişim sağlayabilir.

 

OAuth Akışı

OAuth akışı temelde birkaç farklı şekilde olmaktadır:

• Implicit Flow (2 Legged Flow)
• Authorization Code Flow (3 Legged Flow)
• Client Credential Flow
• Resource Owner Password Flow
• Assertion Flow
• Device Flow

Implicit Flow

Token bölümünde kısaca akış şemasından bahsetmiştik, 2 Legged OAuth şemasında sadece ön kanal kullanılmakta ve tüm işlem tarayıcı üzerinde gerçekleşmektedir. Tüm işlemin tarayıcı üzerinde çalışması güvenlik risklerini beraberinde getirmektedir.

 

Authorization Code Flow

3 Legged OAuth’da ise hem ön kanal hem de arka kanal çalışmaktadır. Ayrıca bu tür akışta hem refresh token hem de access token kullanılmaktadır. Arka kanal (back-end) kullanımı da güvenlik seviyesini artırmaktadır.

 

Client Credential Flow

Genellikle sunucudan sunucuya iletişim sırasında kullanılan bu tarz OAuth flow’larında daha çok servis hesapları karşımıza çıkmaktadır. Örneğin bir sunucuda çalıştırıdğınız web servisi veri iletişim için başka bir sunucuda çalıştırdığınız veritabanı servisine erişim ihtiyacı duyabilir. Bunun için client’ın kimlik bilgileri yeterlidir. Güvenliği artırmak için burada kimlik bilgileri simetrik veya asimetrik anahtarlar kullanılarak şifrelenebilir.

 

Resource Owner Password Flow

Yetki almak için yetkilendirme sunucusuna kaynak sahibinin kullanıcı adı ve parolasının direkt olarak iletildiği, güvenli olmayan OAuth akışıdır. Eğer kullanıcı kimlik bilgileri doğruysa yetkilendirme sunucusu uygulmaya gerekli yetkileri tanımlayan authorization code’u iletmektedir.

 

 

Assertion Flow

İşleme biçimi bakımıdan Client Credential Flow’a benzeyen Assertion Flow’da 3. taraf servislere güvenilir. Daha çok SAML gibi teknolojilerin kullanıldığı ortamlar için tercih edilmektedir.

 

Device Flow

Herhangi bir web tarayıcısının kullanılmadığı, TV gibi cihazlarda yetkilendirme amacıyla kullanılan OAuth akış şeklidir. Örneğin TV’de uzaktan kontrol için ekranda belirtilen URL adresine farklı bir cihazdan gidilerek yetkilendirme işlemi sağlanabilir.