OAuth 2.0'a giriş

Apigee Edge belgelerini görüntülüyorsunuz.
Apigee X belgelerine gidin. bilgi

OAuth ana sayfası: Sağladığımız OAuth kılavuzuna üst düzey bir bakış için OAuth ana sayfasına göz atın.

Bu konuda, Apigee Edge'de OAuth 2.0'a dair temel bilgiler verilmektedir.

OAuth 2.0 nedir?

OAuth 2.0 ile ilgili birçok kitap, blog ve site vardır. Başlangıç olarak IETF OAuth 2.0 spesifikasyonunu incelemenizi önemle tavsiye ederiz. OAuth 2.0 IETF spesifikasyonundaki OAuth 2.0 tanımı şöyledir:

"OAuth 2.0 yetkilendirme çerçevesi, bir üçüncü taraf uygulamasının bir HTTP hizmetine sınırlı erişim elde etmesini sağlar. Bu, kaynak sahibi ile HTTP hizmeti arasında bir onay etkileşimi düzenleyerek kaynak sahibi adına veya üçüncü taraf uygulamasının kendi adına erişim elde etmesine izin vererek gerçekleştirilir."

Bilmeniz gereken en önemli nokta, OAuth 2.0'ın uygulamaların kullanıcının giriş kimlik bilgilerini uygulamaya vermesine gerek kalmadan kullanıcının korunan kaynaklarına (ör. banka hesabı veya kullanıcının bir uygulamadan erişmek isteyebileceği diğer hassas bilgiler) sınırlı erişim elde etmesini sağlayan bir yöntem olduğudur.

OAuth 2.0 akışı

OAuth 2.0 güvenlik çerçevesinin genel akışı aşağıda verilmiştir. Bu akışı, OAuth 2.0'ın işleyiş şekli hakkında birçok bilgi veren bir şemayla başlayarak bu konuda daha ayrıntılı olarak ele alacağız. Bu diyagramda kullanılan terimlere aşina değilseniz hızlı bir giriş için bu bölümü okuyun.

Bilmeniz gereken terimler

• İstemci: "Uygulama" olarak da adlandırılır. Mobil cihazda çalışan bir uygulama veya geleneksel bir web uygulaması olabilir. Uygulama, kaynak sahibi adına kaynak sunucusuna korumalı öğeler için istek gönderir. Kaynak sahibi, uygulamanın korumalı kaynaklara erişmesine izin vermelidir.
• Kaynak sahibi: "Son kullanıcı" olarak da adlandırılır. Bu kişi genellikle korunan bir kaynağa erişim izni verebilen kişidir (veya başka bir tüzel kişidir). Örneğin, bir uygulamanın sosyal medya sitelerinizden birindeki verileri kullanması gerekiyorsa kaynak sahibi sizsinizdir. Uygulamaya verilerinize erişim izni verebilecek tek kişi sizsinizdir.
• Kaynak sunucu: Kaynak sunucuyu Facebook, Google veya Twitter gibi bir hizmet; ya da intranetinizdeki bir İK hizmeti veya B2B ekstranetinizdeki bir iş ortağı hizmeti olarak düşünebilirsiniz. Apigee Edge, API isteklerinin işlenmesi için OAuth jetonu doğrulaması gerektiğinde kaynak sunucu olur. Kaynak sunucunun, uygulamaya korumalı kaynaklar sunmadan önce bir tür yetkilendirmeye ihtiyacı vardır.
• Yetkilendirme sunucusu: Yetkilendirme sunucusu, OAuth 2.0 spesifikasyonuna uygun şekilde uygulanır ve yetkilendirme izinlerini doğrulayıp uygulamaya kaynak sunucusundaki kullanıcı verilerine erişim izni veren erişim jetonlarını yayınlamaktan sorumludur. Apigee Edge'de "token uç noktalarını" yapılandırabilirsiniz. Bu durumda Edge, yetkilendirme sunucusu rolünü üstlenir.
• Yetkilendirme izni: Uygulamaya, son kullanıcı adına erişim jetonu alma izni verir. OAuth 2.0, dört özel "izin türü" tanımlar. Aşağıdaki "OAuth 2.0 erişim izni türleri nelerdir?" bölümüne bakın.
• Erişim jetonu: Korumalı kaynaklara erişmek için kullanılan bir kimlik bilgisi görevi gören uzun bir karakter dizisidir. Aşağıdaki "Erişim jetonu nedir?" bölümüne de bakın.
• Korunan kaynak: Kaynak sahibine ait veriler. Örneğin, kullanıcının kişi listesi, hesap bilgileri veya diğer hassas verileri.

Apigee Edge'in kullanıldığı yerler

Apigee Edge üzerinden proxy'si oluşturulan tüm API'leri OAuth 2.0 ile koruyabilirsiniz. Edge, bir yetkilendirme sunucusu uygulaması içerir ve bu nedenle erişim jetonları oluşturup doğrulayabilir. Geliştiriciler, Apigee Edge'e uygulamalarını kaydederek başlar. Kayıtlı uygulamalar, dört izin türü etkileşiminden herhangi biri aracılığıyla erişim jetonları isteyebilir.

Apigee, her yetkilendirme türünün ayrıntılarını uygulayan çok yönlü bir OAuthV2 politikası sunar. Bu sayede, Apigee Edge'de OAuth'u ayarlamak nispeten kolaydır. Örneğin, erişim jetonu isteği alan, gerekli tüm kimlik bilgilerini değerlendiren ve kimlik bilgileri geçerliyse erişim jetonu döndüren bir politika yapılandırabilirsiniz.

Güvenli API proxy'nizin çağırdığı tüm kaynak sunucuların güvenlik duvarının arkasında olması gerektiğini unutmayın (yani kaynaklara, API proxy'si veya iyi güvenliği sağlanmış başka bir API dışında herhangi bir yolla erişilememelidir).

OAuth 2.0 erişim izni türleri nelerdir?

İzin türlerini, bir uygulamanın erişim jetonu elde etmek için kullanabileceği farklı yollar veya etkileşimler olarak düşünebilirsiniz. Her hibe türü bir veya daha fazla kullanım alanına yöneliktir ve kendi ihtiyaçlarınıza göre hangi hibe türlerini kullanacağınızı seçmeniz gerekir. Genel olarak, her izin türünün avantajları ve dezavantajları vardır. İşletmenizin kullanım alanlarına göre bu avantaj ve dezavantajları değerlendirmeniz gerekir. Önemli bir nokta da verilerinize erişecek uygulamaların "güvenilirliğidir". Genel olarak, üçüncü taraf uygulamaları bir işletme içinde geliştirilen ve kullanılan uygulamalardan daha az güvenilirdir.

Apigee Edge, dört ana OAuth 2.0 erişim izni türünü destekler:

• authorization code (yetkilendirme kodu): En güvenli izin türü olarak kabul edilir. Yetkilendirme sunucusu bir erişim jetonu yayınlamadan önce uygulamanın kaynak sunucusundan bir yetkilendirme kodu alması gerekir. Uygulamanız, kaynak sunucusunun giriş sayfasını açmak için tarayıcıyı her kullandığında ve sizi gerçek hesabınıza (ör. Facebook veya Twitter) giriş yapmaya davet ettiğinde bu akışı görmüşsünüzdür.

Başarıyla giriş yaparsanız uygulama, yetkilendirme sunucusuyla erişim jetonu görüşmesi yapmak için kullanabileceği bir yetkilendirme kodu alır. Genellikle bu izin türü, uygulama istemcide değil sunucuda bulunduğunda kullanılır. Bu yetki türü, istemci uygulaması kaynak sunucunun (ör. uygulama, Twitter kimlik bilgilerinizi hiçbir zaman görmez veya işlemez) kullanıcı adını ya da şifresini hiçbir zaman kullanmadığı veya görmediği için yüksek düzeyde güvenli kabul edilir. Bu yetki türü akışına "üç ayaklı" OAuth da denir.

• implicit: Yetkilendirme kodunun basitleştirilmiş bir sürümü olarak kabul edilir. Bu izin türü genellikle uygulama istemcide bulunduğunda kullanılır. Örneğin, uygulamanın kodu ayrı bir web sunucusunda bulunup çalışmak yerine JavaScript veya başka bir kodlama dili kullanılarak tarayıcıda uygulanır. Bu yetki verme türü akışında, yetkilendirme sunucusu önce yetkilendirme kodu vermek yerine kullanıcı kimliği doğrulandığında doğrudan bir erişim jetonu döndürür. Örtülü izinler bazı durumlarda uygulamanın yanıt verme hızını artırabilir ancak bu avantaj, IETF spesifikasyonunda açıklandığı gibi olası güvenlik etkileriyle karşılaştırılmalıdır.
• resource owner password credentials: Bu akışta, kullanıcının kullanıcı adı/şifresi yetkilendirme sunucusu tarafından doğrulandığında istemciye bir erişim jetonu verilir. Bu akış, yüksek düzeyde güvenilen uygulamalar için önerilir. Bu akışın, örneğin temel kimlik doğrulamaya kıyasla avantajı, kullanıcının yalnızca bir kez kullanıcı adını/şifresini göndermesidir. Bu noktadan itibaren erişim jetonu kullanılır.
• client credentials (istemci kimlik bilgileri): İstemci uygulamasının kendi adına hareket ettiği durumlarda kullanmayı düşünebilirsiniz. Yani müşteri, kaynağın da sahibidir. Bu izin türü genellikle uygulamanın bir arka uç veri depolama hizmetine erişmesi gerektiğinde kullanılır. Uygulamanın çalışması için hizmeti kullanması gerekir ve hizmet, son kullanıcı için başka bir şekilde anlaşılmazdır. Bu izin türüyle bir uygulama, istemci kimliğini ve istemci gizli anahtarını yetkilendirme sunucusuna sunarak erişim jetonu alabilir. Başka bir işlem yapmanız gerekmez. Edge, herhangi bir API proxy'si için kolayca uygulanabilen, kullanıma hazır bir istemci kimlik bilgileri çözümü sunar.

Erişim jetonu nedir?

Erişim jetonu, korumalı kaynaklara erişmek için kullanılan kimlik bilgisi işlevi gören uzun bir karakter dizisidir. Kaynak jetonları (taşıyıcı jetonlar olarak da adlandırılır) Yetkilendirme üst bilgilerinde şu şekilde iletilir:

$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \
  http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282

Kaynak sunucu, erişim jetonunun kullanıcı adı ve şifre gibi kimlik bilgilerinin yerine kullanıldığını anlar. Ayrıca, erişim jetonları kısıtlamalarla verilebilir. Örneğin, uygulama kaynak sunucusundaki verileri okuyabilir ancak yazamaz veya silemez. Örneğin, uygulama saldırıya uğrarsa erişim jetonunun iptal edilebileceğini unutmayın. Bu durumda, uygulamayı kullanmaya devam etmek için yeni bir erişim jetonu almanız gerekir. Ancak, korunan kaynak sunucusunda (ör. Facebook veya Twitter) kullanıcı adınızı ya da şifrenizi değiştirmeniz gerekmez.

Erişim jetonlarının genellikle bir geçerlilik süresi vardır (güvenlik nedeniyle). Bazı yetki türleri, yetkilendirme sunucusunun yenileme jetonu vermesine olanak tanır. Bu jeton, eski jetonun süresi dolduğunda uygulamanın yeni bir erişim jetonu getirmesine olanak tanır. Erişim ve yenileme jetonları hakkında daha fazla bilgi için IETF OAuth 2.0 spesifikasyonuna bakın.

Kapsamlar aracılığıyla sınırlı erişim

OAuth 2.0, kapsam mekanizması aracılığıyla bir uygulamaya korunan kaynaklara sınırlı erişim izni verebilir. Örneğin, bir uygulama yalnızca belirli kaynaklara erişebilir, kaynakları güncelleyebilir veya yalnızca salt okuma erişimi verilebilir. "Üç aşamalı" OAuth akışlarında kullanıcı, genellikle bir izin sayfası (ör. kullanıcının kapsamı başka bir mekanizmanın onay kutusuyla seçtiği bir web sayfası) aracılığıyla erişim düzeyini belirtir.

Uygulama kaydetme

Tüm istemcilerin (uygulamalar), erişim jetonları istemeyi planladıkları OAuth 2.0 yetkilendirme sunucusuna kaydolması gerekir. Bir uygulamayı kaydettiğinizde bir dizi anahtar alırsınız. Biri istemci tanımlayıcısı olarak adlandırılan bir ortak anahtar, diğeri ise istemci gizli anahtarı olarak adlandırılan bir gizli anahtardır. Bu anahtarlar olmadan bir uygulama, yetkilendirme sunucusuna yetkilendirme kodları veya erişim jetonları için istek gönderemez. IETF OAuth spesifikasyonu bu anahtarları istemci kimliği ve istemci gizli anahtarı olarak adlandırırken Apigee Edge kullanıcı arayüzünün bunları tüketici kimliği ve tüketici gizli anahtarı olarak adlandırdığını unutmayın. Bunlar eşdeğerdir.

OAuth 2.0 kullanım alanlarının özeti

Hangi OAuth 2.0 yetki verme türü akışını uygulamayı seçtiğiniz, belirli kullanım alanınıza bağlıdır. Bazı yetki verme türleri diğerlerinden daha güvenlidir. Seçtiğiniz izin türleri, istemci uygulamasının güvenilirliğine bağlıdır ve aşağıdaki tabloda açıklandığı gibi çok dikkatli bir şekilde değerlendirilmelidir:

OAuth 2.0 ve API anahtarı güvenliği

API anahtarı doğrulamasında, uygulamanın Edge'e bir anahtar göndermesi gerekir. Anahtar, API proxy'siyle ilişkili bir Apigee Edge geliştirici uygulamasından alınan geçerli bir tüketici anahtarı olmalıdır. Bir istemci uygulamasının proxy'ye çağrı yapma iznini herhangi bir nedenle iptal etmeniz gerekirse söz konusu tüketici anahtarını iptal etmeniz gerekir. Bu anahtarı kullanan tüm istemci uygulamaları da API proxy'sine erişemez. Diğer yandan, OAuth jetonu, uygulamanın anahtarları iptal edilmeden herhangi bir zamanda iptal edilebilir. Uygulama, kullanıcı adına yeni bir jeton isteyebilir ve jeton verilirse API proxy'sini kullanmaya devam edebilir.

API anahtarı ile jeton arasındaki bir diğer fark, jetonun daha sonra alıp kullanabileceğiniz meta veri özelliklerini içerebilmesidir. Örneğin, API çağrısı yapan kullanıcının kimliğini saklayabilir ve arka uç hedef hizmetine yapılan çağrıları özelleştirmek için bu kimliği kullanabilirsiniz.

API anahtarı doğrulama hakkında ayrıntılı bilgi için API anahtarları başlıklı makaleyi inceleyin. Özel özellikleri OAuth jetonlarıyla kullanma hakkında bilgi edinmek için Jetonları ve Yetkilendirme Kodlarını Özelleştirme başlıklı makaleyi inceleyin.

Önerilen kaynaklar

Okuma

OAuth 2.0 hakkında bilgi başlıklı makaleyi inceleyin.