Apigee Edge belgelerini görüntülüyorsunuz.
Apigee X belgelerine gidin. bilgi
OAuth ana sayfası: Sağladığımız OAuth kılavuzunun üst düzey bir görünümü için OAuth ana sayfasına bakın.
Bu başlıkta, Apigee Edge'deki OAuth 2.0 için temel bir genel bakış sunulmaktadır.
OAuth 2.0 nedir?
OAuth 2.0'a adanmış çok sayıda kitap, blog ve site vardır. IETF OAuth 2.0 spesifikasyonunu inceleyerek başlamanızı önemle tavsiye ederiz. Aşağıda, OAuth 2.0 IETF spesifikasyonundaki OAuth 2.0 tanımı verilmiştir:
"OAuth 2.0 yetkilendirme çerçevesi, bir üçüncü taraf uygulamasının 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 bir HTTP hizmetine sınırlı erişim elde etmesini sağlar."
Bilmeniz gereken en önemli nokta, OAuth 2.0'ın, kullanıcının giriş kimlik bilgilerini uygulamaya bildirmesine gerek kalmadan kullanıcıların korunan kaynaklarına (örneğin, banka hesabını veya kullanıcının bir uygulamadan erişmek isteyebileceği diğer hassas bilgileri) sınırlı erişim elde etmesidir.
OAuth 2.0 akışı
OAuth 2.0 güvenlik çerçevesinin genel akışı aşağıda verilmiştir. OAuth 2.0'ın nasıl çalıştığı hakkında birçok şey gösteren bir şemayla başlayarak bu akışı bu konuda daha ayrıntılı olarak ele alacağız. Bu şemada kullanılan terimlere aşina değilseniz kısa bir tanıtım için bu bölümü okuyun.
Bilmeniz gereken terimler
- İstemci: "Uygulama" olarak da adlandırılır. Bu, mobil cihazda çalışan bir uygulama veya geleneksel bir web uygulaması olabilir. Uygulama, kaynak sahibi adına korunan öğeler için kaynak sunucuya istek gönderir. Kaynak sahibi, uygulamanın korunan kaynaklara erişmesine izin vermelidir.
- Kaynak sahibi: "Son kullanıcı" olarak da adlandırılır. Bu genellikle korunan bir kaynağa erişim izni verebilen kişi (veya başka bir tüzel kişi) şeklindedir. Örneğin, bir uygulamanın sosyal medya sitelerinizden birindeki verileri kullanması gerekiyorsa kaynağın sahibi, yani uygulamanın verilerinize erişmesine izin verebilecek tek kişi sizsinizdir.
- Kaynak sunucusu: Kaynak sunucuyu Facebook, Google veya Twitter gibi bir hizmet, intranetinizdeki İK hizmeti veya B2B extranetinizde bir iş ortağı hizmeti olarak düşünebilirsiniz. Apigee Edge, API isteklerini işlemek için OAuth jeton doğrulaması gerektiği durumlarda kullanılan bir kaynak sunucusudur. Kaynak sunucusunun, korunan kaynakları uygulamaya sunması için bir tür yetkilendirmeye ihtiyacı vardır.
- Yetkilendirme sunucusu: Yetkilendirme sunucusu, OAuth 2.0 spesifikasyonuna uygun şekilde uygulanır ve yetkilendirme izinlerinin doğrulanmasından ve uygulamanın kaynak sunucudaki kullanıcı verilerine erişmesine izin veren erişim jetonlarının verilmesinden sorumludur. Apigee Edge'de "jeton uç noktaları" 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 izin türleri nedir?" başlıklı bölümü inceleyin.
- Erişim jetonu: Korunan kaynaklara erişmek için kullanılan kimlik bilgisi görevi gören uzun bir karakter dizesi. Aşağıdaki "Erişim jetonu nedir?" bölümünü de inceleyin.
- Korunan kaynak: Kaynak sahibine ait verilerdir. Örneğin, kullanıcının kişi listesi, hesap bilgileri veya diğer hassas veriler.
Apigee Edge'in geçtiği yerler
Apigee Edge üzerinden proxy kullanan tüm API'leri OAuth 2.0 ile koruyabilirsiniz. Edge, yetkilendirme sunucusu uygulaması içerir ve bu nedenle erişim jetonları oluşturup doğrulayabilir. Geliştiriciler işe uygulamalarını Apigee Edge'e kaydederek işe başlar. Kayıtlı uygulamalar, dört izin türü etkileşiminden herhangi biri aracılığıyla erişim jetonları isteyebilir.
Apigee, her bir bağış türünün ayrıntılarını uygulayan çok yönlü bir OAuthV2 politikası sağlayarak Apigee Edge'de OAuth kurulumunu nispeten daha kolay hale getirir. Örneğin, erişim jetonu için istek 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 çağrılarınızın bir güvenlik duvarının arkasında olması gerektiğini unutmayın (yani kaynaklara, API proxy'si veya iyi korunmuş başka bir API dışında başka hiçbir yöntemle erişilememelidir).
OAuth 2.0 izin türleri nedir?
İzin türlerini, bir uygulamanın erişim jetonu almak 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. Kendi ihtiyaçlarınıza göre hangi izin türlerinin kullanılacağını seçmeniz gerekir. Genel olarak her hibe türünün avantajları ve dezavantajları vardır. Bunları ticari kullanım alanlarınıza göre tartmanız gerekir. Göz önünde bulundurulması gereken önemli noktalardan biri, verilerinize erişecek uygulamaların "güvenilirliğidir". Genel olarak üçüncü taraf uygulamaları, bir kuruluşta geliştirilip kullanılan uygulamalardan daha az güvenilirdir.
Apigee Edge, dört ana OAuth 2.0 hibe türünü destekler:
- yetkilendirme kodu -- En güvenli izin türü olarak kabul edilir. Yetkilendirme sunucusunun erişim jetonu yayınlaması için önce uygulamanın kaynak sunucudan yetkilendirme kodu alması gerekir. Uygulamanız, kaynak sunucusunun giriş sayfasını açan bir tarayıcı açıp 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üşmek için kullanabileceği bir yetkilendirme kodu alır. Bu izin türü genellikle uygulama, istemci yerine bir sunucuda bulunduğunda kullanılır. İstemci uygulaması, kaynak sunucusu için kullanıcının kullanıcı adını veya şifresini hiçbir zaman işlemediği veya görmediği (örneğin, uygulama Twitter kimlik bilgilerinizi hiçbir zaman görmez veya işlemediği) için bu izin türü son derece güvenli olarak kabul edilir. Bu izin türü akışı, "üç aşamalı" OAuth olarak da adlandırılır.
- implicit (dolaylı): 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 JavaScript veya başka bir kodlama dili kullanılarak tarayıcıya uygulanır (ayrı bir web sunucusunda oturup çalışmak yerine). Bu izin türü akışında, yetkilendirme sunucusu önce yetkilendirme kodu yayınlamak 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 özelliğini iyileştirebilir ancak bu avantajın, IETF spesifikasyonunda açıklandığı gibi olası güvenlik sonuçları açısından değerlendirilmesi gerekir.
- kaynak sahibi şifre kimlik bilgileri -- 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üvenilir uygulamalar için önerilir. Bu akışın temel kimlik doğrulamasına göre avantajı, kullanıcının kullanıcı adını/şifresini yalnızca bir kez sunmasıdır. Sonrasında erişim jetonu kullanılır.
- istemci kimlik bilgilerini -- İstemci uygulamasının kendi adına hareket ettiği durumlarda kullanmayı düşünün. Yani istemci aynı zamanda kaynağın da sahibidir. Bu izin türü, genellikle uygulamanın bir arka uç veri depolama hizmetine erişmesi gerektiğinde kullanılır. Hizmet, işini yapmak için uygulama tarafından kullanılmalıdır. Hizmet son kullanıcı için opak olmalıdı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ıza gerek yoktur. Edge, herhangi bir API proxy'si için uygulaması kolay, kullanıma hazır bir istemci kimlik bilgisi çözümü sunar.
Erişim jetonu nedir?
Erişim jetonu, korunan kaynaklara erişmek için kullanılan kimlik bilgisi görevi gören uzun bir karakter dizesidir. Kaynak jetonları (hamiline ait 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 sunucusu, erişim jetonunun kullanıcı adı ve şifre gibi kimlik bilgileri için "yer aldığını" anlar. Ayrıca, erişim jetonları kısıtlamalarla verilebilir. Böylece, örneğin, uygulama kaynak sunucudaki verileri okuyabilir ancak yazamaz veya silemez. Örneğin, uygulamanın güvenliği ihlal edilirse 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 kaynaklar sunucusunda (ör. Facebook veya Twitter) kullanıcı adınızı veya şifrenizi değiştirmeniz gerekmez.
Erişim jetonlarının genellikle bir son kullanma tarihi vardır (güvenlik nedeniyle). Bazı izin türleri, yetkilendirme sunucusunun yenileme jetonu yayınlamasına izin verir. Bu sayede uygulama, eski jetonun süresi dolduğunda yeni bir erişim jetonu getirebilir. 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ı altında, kullanıcı genellikle erişim düzeyini bir izin sayfası (örneğin, kullanıcının başka bir mekanizmanın onay kutusuyla kapsamı seçtiği bir web sayfası) aracılığıyla belirtir.
Uygulama kaydetme
Tüm istemciler (uygulamalar), erişim jetonları istemeyi düşündükleri OAuth 2.0 yetkilendirme sunucusuna kaydolmalıdır. Bir uygulamayı kaydettiğinizde bir anahtar grubu alırsınız. Biri istemci kimliği adı verilen ortak anahtar, diğeri ise istemci gizli anahtarı adı verilen gizli anahtardır. Bu anahtarlar olmadan uygulamalar yetkilendirme sunucusuna yetkilendirme kodu veya erişim jetonu isteği gönderemez. IETF OAuth spesifikasyonu, bu anahtarları istemci kimliğini ve istemci gizli anahtarını çağırırken Apigee Edge kullanıcı arayüzünün bunları Tüketici Kimliği ve Tüketici sırrı olarak çağırdığını unutmayın. Bunlar eşdeğerdir.
OAuth 2.0 kullanım alanlarının özeti
Bazı izin türleri diğerlerinden daha güvenli olduğu için hangi OAuth 2.0 izin türü akışını uygulamayı seçtiğiniz özel kullanım alanınıza bağlıdır. İzin türü seçiminiz, istemci uygulamasının güvenilirliğine bağlıdır ve aşağıdaki tabloda açıklandığı gibi dikkatli bir değerlendirme gerektirir:
| Kullanım Örneği | İtimat | Önerilen OAuth 2.0 Yetkilendirme Hakkı Türleri | Açıklama |
|---|---|---|---|
| B2B (extranet), intranet, diğer |
API sağlayıcıyla güvenilir bir iş ilişkisine sahip olan şirket içi geliştiriciler veya geliştiriciler tarafından yazılmış, son derece güvenilir uygulamalar. Kendi adlarına kaynaklara erişmesi gereken uygulamalar. |
|
|
| İntranet siteler, portallar |
Şirket içi veya güvenilir üçüncü taraf geliştiriciler tarafından yazılmış güvenilir uygulamalar. Sigorta seçimleri yapmak, yorum göndermek veya kişisel bilgileri değiştirmek için şirketinizin İK sitesine giriş yapmak buna iyi bir örnektir. |
|
|
| Herkese açık uygulamalar | Güvenilmeyen uygulamalar, API sağlayıcısıyla güvenilir bir iş ilişkisi olmayan üçüncü taraf geliştiriciler tarafından yazılır. Örneğin, herkese açık API programlarına kaydolan geliştiricilerin genel olarak güvenilir olmaması gerekir. |
|
|
| B2C | Bireysel bir son kullanıcı (mobil kullanıcı) söz konusudur ve kullanıcı kimlik bilgileri mobil cihazda depolanır. |
|
|
OAuth 2.0 - API anahtarı güvenliği karşılaştırması
API anahtarı doğrulama işlemi için uygulamanın Edge'e anahtar göndermesi gerekir. Anahtar, API proxy'si ile ilişkilendirilmiş bir Apigee Edge geliştirici uygulamasından alınan geçerli tüketici anahtarı olmalıdır. Herhangi bir nedenle bir istemci uygulamasının proxy'ye çağrı yapması için izni iptal etmeniz gerekirse bu tüketici anahtarını iptal etmeniz gerekir. Bu anahtarı kullanan istemci uygulamaları da API proxy'sine erişemez. Öte yandan OAuth jetonu, uygulamanın anahtarları iptal edilmeden herhangi bir zamanda iptal edilebilir. Uygulama, kullanıcı adına yeni bir jeton isteyebilir ve bir jeton verilirse uygulama, API proxy'sini kullanmaya devam edebilir.
API anahtarı ile jeton arasındaki başka bir fark, jetonun daha sonra alabileceğiniz ve kullanabileceğiniz meta veri özellikleri içerebilmesidir. Örneğin, API çağrısını yapan kullanıcının kimliğini depolayabilir ve arka uç hedef hizmetine yapılan çağrıları özelleştirmek için kullanabilirsiniz.
API anahtarı doğrulama hakkında ayrıntılı bilgi için API anahtarları konusuna bakın. OAuth jetonlarıyla özel özellikler kullanma hakkında bilgi edinmek için Jetonları ve Yetkilendirme Kodlarını Özelleştirme bölümüne bakın.
Önerilen kaynaklar
Okuma
OAuth 2.0 hakkında bilgi edinme başlıklı makaleyi inceleyin.