Rich Authorization Requests Nedir? OAuth İçin 12 Güçlü Yetkilendirme Kontrolü

Klasik OAuth 2.0 sistemlerinde istemci erişim ihtiyacını çoğu zaman scope parametresiyle ifade eder. Örneğin profile.read, payments veya files.write gibi scope değerleri kullanılabilir. Ancak bazı işlemlerde yalnızca “ödeme yapabilir” demek yeterli değildir.

Bir finans uygulamasında istemcinin yalnızca belirli hesaptan, belirli tutarda ve belirli alıcıya ödeme yapabilmesi gerekebilir. Benzer şekilde bir dosya API’sinde istemciye tüm dosyaları yazma yetkisi vermek yerine yalnızca belirli klasördeki belirli dosyaya yazma yetkisi tanımlanmak istenebilir.

IETF tarafından yayımlanan RFC 9396, bu ihtiyacı karşılamak için authorization_details parametresini tanımlar. Bu nedenle Rich Authorization Requests nedir sorusuna en basit cevap; OAuth 2.0 yetkilendirmelerini daha ayrıntılı, yapılandırılmış ve bağlama özel biçimde ifade etmeyi sağlayan Rich Authorization Requests standardıdır.

Rich Authorization Requests Nedir? Hızlı Bakış

Rich Authorization Requests Nedir ve Neden Gereklidir?

Rich Authorization Requests nedir konusunun temelinde OAuth scope sisteminin doğası bulunur. Scope, birçok uygulama için yeterli ve kullanışlıdır ancak genellikle statik veya daha geniş izin kategorilerini ifade eder.

Örneğin:

scope=payments

istemcinin ödeme API’sine erişmek istediğini gösterebilir. Ancak şu soruların cevabını tek başına vermeyebilir:

• Hangi hesaptan ödeme yapılacak?
• Ödeme tutarı ne kadar?
• Para birimi nedir?
• Ödeme hangi alıcıya yapılacak?
• İstemci yalnızca ödeme başlatabilir mi?
• Ödemeyi iptal etme yetkisi var mı?

RAR, bu bilgilerin yapılandırılmış JSON verisi içerisinde taşınmasını sağlar.

Örneğin basitleştirilmiş bir yapı şöyle olabilir:

[
  {
    "type": "payment_initiation",
    "actions": [
      "initiate"
    ],
    "locations": [
      "https://api.example.com/payments"
    ],
    "instructedAmount": {
      "currency": "TRY",
      "amount": "1500.00"
    },
    "creditorName": "Örnek Mağaza"
  }
]

Böylece Authorization Server, istemcinin yalnızca genel bir “ödeme” yetkisi istemediğini; daha belirli bir işlem için izin talep ettiğini anlayabilir.

Rich Authorization Requests Nedir? 12 Güçlü Yetkilendirme Kontrolü

1. Her Authorization Details Nesnesinde type Kullanın

RFC 9396 içerisindeki en önemli alan type değeridir.

type, authorization details nesnesinin hangi yetkilendirme modelini temsil ettiğini belirtir.

Örneğin:

"type": "payment_initiation"

veya:

"type": "customer_information"

şeklinde tanımlanabilir.

Authorization Server, ilgili type değerinin hangi alanları ve hangi değerleri desteklediğini bilmelidir.

Rich Authorization Requests nedir yaklaşımında type değerini gelişi güzel kabul etmek yerine API tarafından önceden tanımlanmış ve desteklenen tiplerle sınırlandırmak gerekir.

2. Bilinmeyen Authorization Details Type Değerlerini Reddedin

Authorization Server, tanımadığı bir authorization details türünü otomatik olarak kabul etmemelidir.

RFC 9396, Authorization Server’ın bilinmeyen authorization details type değerlerini veya ilgili type tanımına uymayan nesneleri işlemeyi reddetmesini tanımlar.

Örneğin sistem yalnızca:

• payment_initiation
• account_information

türlerini destekliyorsa saldırganın:

"type": "super_admin"

gibi rastgele bir değer göndermesi yeni bir yetki oluşturmamalıdır.

Geçersiz yapıların invalid_authorization_details hatasıyla reddedilmesi gerekir.

3. Authorization Details Alanlarını Sıkı Biçimde Doğrulayın

Sadece type kontrolü yeterli değildir.

Authorization Server ilgili type içerisinde:

• bilinmeyen alan,
• yanlış veri tipi,
• geçersiz değer,
• eksik zorunlu alan

bulunup bulunmadığını da kontrol etmelidir.

Örneğin ödeme miktarının sayısal değer beklenen bir yerde saldırgan tarafından farklı veri yapısıyla gönderilmesine izin verilmemelidir.

Rich Authorization Requests nedir güvenlik modelinde authorization_details normal kullanıcı girdisi gibi değerlendirilerek sıkı input validation uygulanmalıdır.

4. actions Alanıyla Yetkileri İşlem Bazında Sınırlandırın

actions alanı kaynağın üzerinde hangi işlemlerin gerçekleştirilebileceğini tanımlamak için kullanılabilir.

Örneğin:

"actions": [
  "read"
]

yalnızca okuma yetkisi verirken:

"actions": [
  "read",
  "write"
]

hem okuma hem yazma yetkisi talep edebilir.

Finansal bir API içerisinde ise:

"actions": [
  "initiate",
  "status",
  "cancel"
]

gibi işlemler tanımlanabilir.

İstemciye ihtiyacı olmayan işlemleri vermemek, en az ayrıcalık ilkesinin RAR yapısındaki en önemli uygulamalarından biridir.

5. locations Alanıyla Yetkiyi Doğru Kaynağa Bağlayın

locations alanı yetkinin hangi Resource Server veya kaynak konumunda kullanılabileceğini belirtmek için kullanılabilir.

Örneğin:

"locations": [
  "https://api.example.com/payments"
]

ifadesi ilgili yetkilendirmenin ödeme Resource Server’ıyla ilişkilendirilmesine yardımcı olabilir.

Bu yapı özellikle bir Authorization Server’ın birden fazla Resource Server’a token verdiği büyük OAuth sistemlerinde önemlidir.

Bir e-posta API’si için verilen genel read yetkisinin başka bir cloud storage API’sinde yanlışlıkla geçerli kabul edilmesi engellenebilir.

Böylece Rich Authorization Requests nedir modeli audience restriction açısından da daha net bir yetkilendirme bağlamı sağlayabilir.

6. datatypes ve identifier ile Yetkiyi Daha Hassas Hâle Getirin

RAR içerisinde kullanılabilecek ortak alanlardan biri datatypes değeridir.

Örneğin müşteri API’sinde:

"datatypes": [
  "contacts"
]

kullanıldığında istemcinin yalnızca kişi bilgileriyle ilgili veri türünü talep ettiği belirtilebilir.

identifier alanı ise belirli bir kaynağın kimliğini belirtmek için kullanılabilir.

Örneğin:

"identifier": "account-12345"

gibi bir tanım kullanılarak yetkilendirme yalnızca belirli bir hesaba bağlanabilir.

Bu model tüm kaynaklara geniş erişim vermek yerine yalnızca gerekli nesne üzerinde işlem yapılmasını kolaylaştırır.

7. privileges Alanını En Az Ayrıcalık İlkesine Göre Tasarlayın

privileges alanı kaynak üzerinde talep edilen ayrıcalık veya yetki seviyelerini tanımlamak için kullanılabilir.

Örneğin:

"privileges": [
  "standard"
]

veya bazı API tasarımlarında:

"privileges": [
  "admin"
]

gibi değerler bulunabilir.

Ancak yüksek ayrıcalıklı değerler otomatik olarak verilmemelidir.

Authorization Server:

• istemci kimliğini,
• kullanıcı yetkisini,
• işlem bağlamını,
• kurum politikasını

kontrol ettikten sonra yetkilendirme kararı vermelidir.

Rich Authorization Requests nedir yaklaşımının amacı daha ayrıntılı yetki tanımlayabilmek olduğu için gereksiz yüksek privilege kullanımı standardın sağladığı avantajı ortadan kaldırabilir.

8. scope ve authorization_details Yapısını Gereksiz Yere Karıştırmayın

RFC 9396, scope ve authorization_details değerlerinin aynı authorization request içerisinde kullanılmasına izin verir.

Bu özellikle mevcut OAuth uygulamalarının RAR sistemine kademeli biçimde geçebilmesini kolaylaştırır.

Ancak aynı API için erişim politikasının bir kısmını scope, diğer kısmını authorization_details üzerinden ifade etmek karmaşıklık oluşturabilir.

Bu nedenle belirli bir API için mümkün olduğunca tek bir yetki ifade modelinin tercih edilmesi daha anlaşılır olabilir.

İkisi birlikte kullanılıyorsa Authorization Server tüm yetkilendirme ihtiyaçlarını birlikte değerlendirmeli ve kullanıcıya birleştirilmiş izin setini göstermelidir.

9. authorization_details Verisini PAR veya JAR ile Koruyun

Rich Authorization Requests nedir güvenliğinin en kritik konularından biri authorization request manipülasyonudur.

Authorization request kullanıcı tarayıcısı üzerinden geçiyorsa authorization_details verileri kullanıcı veya saldırgan tarafından değiştirilmeye çalışılabilir.

RFC 9396, bütünlüğün önemli olduğu durumlarda authorization details yapısının manipulation ve swapping saldırılarına karşı korunmasını ister.

Bunun için:

• JWT-Secured Authorization Request yani JAR,
• Pushed Authorization Requests yani PAR

gibi OAuth mekanizmaları kullanılabilir.

PAR özellikle authorization parametrelerinin tarayıcı üzerinden geçirilmeden önce Client tarafından doğrudan Authorization Server’a gönderilmesini sağlar.

Bu yapı biraz önce oluşturduğumuz FAPI 2.0 güvenlik mimarisiyle de güçlü biçimde örtüşür.

10. Hassas authorization_details Verilerinin Sızmasını Engelleyin

RAR kullanılırken authorization_details içerisinde hassas bilgiler bulunabilir.

Örneğin:

• banka hesap bilgileri,
• ödeme tutarı,
• alıcı bilgileri,
• belirli dosya kimlikleri,
• müşteri verileri

authorization isteğinin parçası hâline gelebilir.

Bu bilgilerin:

• browser history,
• Referrer header,
• proxy logları,
• analytics sistemleri,
• uygulama hata logları

üzerinden sızmaması gerekir.

Hassas veriler söz konusu olduğunda PAR veya güvenli request object mekanizmaları kullanılabilir.

Ayrıca uygulama yalnızca yetkilendirme için gerçekten gerekli verileri authorization_details içerisine eklemelidir.

11. Kullanıcıya Açık ve Anlaşılır Consent Ekranı Gösterin

RAR’ın en önemli avantajlarından biri izin isteğinin daha detaylı hâle getirilebilmesidir.

Ancak JSON nesnesinin ayrıntılı olması kullanıcı deneyiminin de otomatik olarak iyi olduğu anlamına gelmez.

Authorization Server gelen teknik bilgileri kullanıcıya anlaşılır biçimde göstermelidir.

Örneğin kullanıcıya:

“Bu uygulama ödemelerinize erişmek istiyor.”

gibi genel bir ifade yerine:

• 1.500 TL ödeme yapılacak,
• alıcı: Örnek Mağaza,
• yalnızca bu işlem için yetki verilecek,
• ödeme iptal yetkisi verilmeyecek

gibi daha açıklayıcı bir consent ekranı gösterilebilir.

Rich Authorization Requests nedir yaklaşımının gerçek değeri, teknik olarak ince yetkilendirme yaparken kullanıcının neye izin verdiğini de netleştirebilmesidir.

12. Resource Server’da Gerçek Authorization Details Yetkisini Doğrulayın

Authorization Server’ın doğru authorization_details üretmesi tek başına yeterli değildir.

Resource Server gelen Access Token’ın hangi hakları taşıdığını anlamalı ve API isteğini bu haklarla karşılaştırmalıdır.

Örneğin token yalnızca:

"actions": [
  "read"
]

yetkisini taşıyorsa Resource Server:

DELETE /customers/123

gibi bir isteğe izin vermemelidir.

Aynı şekilde belirli account identifier için verilen izin başka hesaba karşı kullanılmamalıdır.

RAR verilerinin token, token introspection veya Authorization Server tarafından oluşturulan uygun yetki modeline doğru biçimde yansıtılması gerekir.

Bu kontrol sayesinde Rich Authorization Requests nedir yapısı yalnızca authorization ekranında kalan metadata olmaktan çıkar ve gerçek API yetkilendirme kararına dönüşür.

Rich Authorization Requests Nedir? scope ile RAR Arasındaki Fark

Rich Authorization Requests Nedir? authorization_details Yapısı

RAR isteğinin temelinde authorization_details isimli JSON array bulunur.

Basitleştirilmiş bir örnek:

[
  {
    "type": "customer_information",
    "locations": [
      "https://api.example.com/customers"
    ],
    "actions": [
      "read"
    ],
    "datatypes": [
      "contacts"
    ]
  }
]

Bu yapı şu anlama gelebilir:

• Yetkilendirme türü: customer_information
• Resource Server: customer API
• İşlem: read
• Veri türü: contacts

İstemci aynı authorization_details array içerisinde birden fazla nesne de gönderebilir.

Rich Authorization Requests Nedir? Ortak Alanlar

API tasarımcıları bu ortak alanlara ek olarak kendi type modelleri için API’ye özel alanlar da tanımlayabilir.

Rich Authorization Requests Nedir? Authorization Server Metadata

RAR destekleyen Authorization Server hangi authorization details türlerini desteklediğini metadata üzerinden ilan edebilir.

RFC 9396 bunun için:

authorization_details_types_supported

metadata parametresini tanımlar.

Örneğin:

{
  "authorization_details_types_supported": [
    "payment_initiation",
    "account_information"
  ]
}

Client, bu bilgi sayesinde Authorization Server’ın hangi RAR türlerini anlayabildiğini öğrenebilir.

Bu yapı Rich Authorization Requests nedir entegrasyonlarında istemci ve Authorization Server arasında daha öngörülebilir bir sözleşme oluşturulmasına yardımcı olur.

Rich Authorization Requests İçin Örnek Ödeme Yetkilendirmesi

[
  {
    "type": "payment_initiation",
    "actions": [
      "initiate"
    ],
    "locations": [
      "https://api.example.com/payments"
    ],
    "instructedAmount": {
      "currency": "TRY",
      "amount": "1500.00"
    },
    "creditorName": "Örnek Mağaza",
    "creditorAccount": {
      "iban": "TR000000000000000000000000"
    }
  }
]

Bu yapı genel bir payments scope’undan çok daha ayrıntılı yetkilendirme bilgisi taşır.

Authorization Server kullanıcıya tam olarak hangi işlemin yapılacağını gösterebilir ve Access Token yalnızca izin verilen işlemle ilişkilendirilebilir.

Rich Authorization Requests Hangi Sistemlerde Kullanılabilir?

Rich Authorization Requests nedir teknolojisi yalnızca finans sektörü için kullanılmak zorunda değildir.

İnce yetkilendirme gerektiren birçok API mimarisinde değerlendirilebilir:

• açık bankacılık,
• ödeme API’leri,
• fintech sistemleri,
• sağlık kayıtları,
• sigorta platformları,
• e-devlet API’leri,
• doküman ve dosya sistemleri,
• kurumsal SaaS uygulamaları,
• IoT cihaz yönetimi,
• yüksek hassasiyetli veri API’leri.

Rich Authorization Requests Nedir? 12 Maddelik Güvenlik Kontrol Listesi

1. Her authorization_details nesnesinde geçerli type kullanın.
2. Bilinmeyen authorization details type değerlerini reddedin.
3. Alan isimlerini, veri tiplerini ve değerleri sıkı doğrulayın.
4. actions ile yalnızca gerekli işlemleri verin.
5. locations ile yetkiyi uygun Resource Server’a sınırlandırın.
6. datatypes ve identifier ile kaynak erişimini daraltın.
7. privileges değerlerini en az ayrıcalık ilkesine göre yönetin.
8. scope ve authorization_details kullanım politikasını açıkça belirleyin.
9. Authorization request bütünlüğünü PAR veya JAR ile koruyun.
10. authorization_details içerisindeki hassas bilgilerin sızmasını engelleyin.
11. Kullanıcıya anlaşılır consent ekranı gösterin.
12. Resource Server’da gerçek authorization details haklarını doğrulayın.

Rich Authorization Requests Nedir? En Sık Yapılan 12 Hata

1. Client’ın gönderdiği type değerine otomatik güvenmek
2. Bilinmeyen JSON alanlarını kabul etmek
3. actions listesini kontrol etmemek
4. Tüm Resource Server’lara aynı yetkiyi vermek
5. Gereksiz admin privilege kullanmak
6. RAR ile scope yetkilerini çelişkili tasarlamak
7. authorization_details verisini browser üzerinden korumasız taşımak
8. Hassas ödeme bilgilerini URL ve loglara sızdırmak
9. Consent ekranında teknik JSON göstermek
10. Kullanıcının onayladığından daha geniş Access Token üretmek
11. Resource Server’da authorization details kontrolünü uygulamamak
12. Geçersiz authorization details yapılarını sessizce kabul etmek

Rich Authorization Requests Nedir? Sık Sorulan Sorular

Rich Authorization Requests nedir?

Rich Authorization Requests nedir sorusuna; OAuth 2.0 authorization işlemlerinde detaylı erişim ihtiyaçlarını JSON tabanlı authorization_details parametresiyle ifade etmeyi sağlayan RFC 9396 standardı şeklinde cevap verilebilir.

RAR neyin kısaltmasıdır?

Rich Authorization Requests ifadesinin kısaltmasıdır.

RAR OAuth 2.0’ın yerine mi geçer?

Hayır. RAR, OAuth 2.0 yetkilendirme sistemini daha ince ayrıntılı izin bilgileriyle genişleten bir standarttır.

authorization_details nedir?

OAuth authorization isteğinde ince ayrıntılı yetkilendirme gereksinimlerini taşıyan JSON array parametresidir.

RAR ile scope aynı mı?

Hayır. Scope genellikle daha genel string tabanlı izinleri ifade ederken RAR yapılandırılmış JSON nesneleri kullanarak daha ayrıntılı yetki bilgisi taşıyabilir.

scope ve authorization_details birlikte kullanılabilir mi?

Evet. RFC 9396 ikisinin aynı authorization request içerisinde kullanılmasına izin verir. Ancak belirli bir API’nin mümkün olduğunca tutarlı bir yetki ifade modeli kullanması önerilir.

RAR içinde type zorunlu mu?

Evet. Authorization details nesnesinin hangi yetki modelini temsil ettiğini belirleyen temel alandır.

RAR ile ödeme miktarı belirtilebilir mi?

Evet. İlgili authorization details type tanımı destekliyorsa miktar, para birimi, alıcı ve benzeri API’ye özel alanlar tanımlanabilir.

RAR güvenliğini nasıl artırabilirim?

Input validation, en az ayrıcalık, Resource Server doğrulaması ve authorization request bütünlüğü için PAR veya JAR gibi mekanizmalar kullanılabilir.

RAR ile FAPI 2.0 aynı şey mi?

Hayır. RAR ince ayrıntılı authorization verisini tanımlayan OAuth standardıdır. FAPI 2.0 ise yüksek güvenlikli API’ler için daha geniş bir OAuth güvenlik profilidir. Aynı mimaride tamamlayıcı biçimde değerlendirilebilirler.

Rich Authorization Requests, OAuth Scope ve FAPI 2.0 İlişkisi

Rich Authorization Requests nedir konusunu bugünkü içerik serimizdeki diğer teknolojilerle birlikte değerlendirmek faydalıdır.

• OAuth 2.0: Yetkilendirme çerçevesini oluşturur.
• JWT: Bazı token ve güvenlik mesajlarında kullanılabilecek veri formatıdır.
• OpenID Connect: OAuth üzerine kullanıcı kimlik doğrulama katmanı ekler.
• DPoP: Access Token kullanımını istemcinin kriptografik anahtarına bağlayabilir.
• FAPI 2.0: Yüksek değerli API’ler için OAuth kullanımını daha katı güvenlik kurallarıyla sınırlar.
• RAR: İstemcinin tam olarak hangi işlem için hangi yetkiyi istediğini daha ayrıntılı ifade eder.

Bu teknolojiler birbirinin yerine geçen standartlar değildir. Doğru mimaride farklı güvenlik problemlerini çözmek için birlikte kullanılabilirler.

İlgili İçerikler

OAuth 2.0 Güvenliği Nedir? 10 Kritik Önlem

FAPI 2.0 Nedir? Yüksek Güvenlikli API’ler İçin 12 Kritik Kontrol

DPoP Nedir? OAuth Token Güvenliği İçin 12 Güçlü Önlem

JWT Güvenliği Nedir? 12 Kritik Önlem

OpenID Connect Güvenliği Nedir? 12 Kritik Önlem

Resmî ve Güvenilir Kaynaklar

IETF / RFC Editor — RFC 9396: OAuth 2.0 Rich Authorization Requests

IETF Datatracker — RFC 9396

Sonuç: Rich Authorization Requests Nedir?

Rich Authorization Requests nedir sorusuna; OAuth 2.0’ın klasik scope modelini daha ayrıntılı ve yapılandırılmış authorization bilgileriyle genişleten, RFC 9396 ile standartlaştırılmış bir yetkilendirme yöntemi şeklinde cevap verilebilir.

authorization_details içerisinde type, actions, locations, datatypes, identifier ve privileges gibi bilgiler kullanılarak istemcinin tam olarak hangi kaynak üzerinde hangi işlemi yapmak istediği çok daha açık şekilde tanımlanabilir.

Ancak bu ayrıntılı yapı beraberinde daha sıkı güvenlik ihtiyacı da getirir. Authorization Server’ın tüm alanları doğrulaması, kullanıcıya anlaşılır consent göstermesi, hassas authorization_details bilgilerinin sızmasını önlemesi ve Resource Server’ın verilen hakları her API çağrısında gerçekten uygulaması gerekir.

PAR veya JAR ile authorization request bütünlüğünün korunması, locations ile Resource Server sınırlandırması ve en az ayrıcalık politikası birlikte uygulandığında Rich Authorization Requests nedir yaklaşımı OAuth tabanlı API’lerde çok daha hassas ve kontrol edilebilir bir yetkilendirme modeli oluşturabilir.