Apigee Edge belgelerini görüntülüyorsunuz.
.
Git:
Apigee X belgeleri. bilgi
OAuth ana sayfası: OAuth rehberliğinin üst düzey görünümü için OAuth ana sayfasına bakın. sağlayın.
Bu bölümde, Apigee Edge'de OAuth 2.0'a genel bir bakış sunulmaktadır.
OAuth 2.0 nedir?
OAuth 2.0'a ayrılmış çok sayıda kitap, blog ve site var. Şunu kesinlikle öneririz: inceleyerek başlayın: IETF OAuth 2.0 spesifikasyonlarına göz atın. OAuth 2.0 IETF spesifikasyonundaki OAuth 2.0 tanımı aşağıda verilmiştir. kendisi:
OAuth 2.0 yetkilendirme çerçevesi, bir üçüncü tarafın bir kaynak sahibi adına sınırlı erişim elde etmek için kullanılabilmesini HTTP hizmeti aracılığıyla ya da kaynak sahibi ile HTTP hizmeti arasında bir onay etkileşimi üçüncü taraf uygulamasının kendi adına erişim elde etmesine izin verme."
Bilmeniz gereken en önemli nokta, OAuth 2.0'ın uygulamaların, kullanıcının korunan kaynaklarına sınırlı erişim elde etmesi için bir yol sunduğudur (banka hesabını veya başka herhangi bir bir uygulamadan erişmek isteyebileceği hassas bilgiler içeren veriler) giriş kimlik bilgilerini uygulamaya saklamalıdır.
OAuth 2.0 akışı
OAuth 2.0 güvenlik çerçevesinin genel akışı aşağıda verilmiştir. Bu akıştan sonraki videolarda ayrıntılı olarak inceleyeceğiz. Bu şemada kullanılan terimlere aşina değilseniz hızlı bir şekilde giriş.
Bilmeniz gereken terimler
- İstemci: "Uygulama" olarak da adlandırılır. Mobil cihazda çalışan bir uygulama olabilir. cihaz veya geleneksel bir web uygulaması. Uygulama, korunmak üzere kaynak sunucuya istek gönderiyor temsil eder. Kaynak sahibi, uygulamaya şu izni vermelidir: korunan kaynaklara erişin.
- Kaynak sahibi: "Son kullanıcı" olarak da adlandırılır. Bu genellikle korunan bir kaynağa erişim izni verebilecek bir kişi (veya başka bir tüzel kişi). Örneğin, Örneğin, bir uygulamanın, sosyal medya sitelerinizden birindeki verileri kullanması gerekiyorsa kaynak sahibi: Uygulamanın verilerinize erişmesine izin verebilecek tek kişidir.
- Kaynak sunucusu: Kaynak sunucuyu şuna benzer bir hizmet olarak düşünebilirsiniz: Facebook, Google veya Twitter; ya da intranetinizdeki bir İK hizmetine ihtiyacınız olabilir; veya bir iş ortağı hizmeti, B2B extranet (B2B extranet) Apigee Edge, şu işlemler için OAuth jeton doğrulaması gerektiğinde bir kaynak sunucudur: API isteklerini işler. Kaynak sunucu, hizmet verilebilmesi için bir tür yetkilendirmeye ihtiyaç duyar. korunan kaynakları uygulamaya aktarmanızı sağlar.
- Yetkilendirme sunucusu: Yetkilendirme sunucusu uygulanır. olduğunu ve OAuth 2.0 spesifikasyonuna uygun olduğunu ve yetkilendirme izinlerini doğrulama ve erişimi verme jetonlar ve uygulamanın, kaynak sunucudaki kullanıcı verilerine erişmesine izin verir. Siz "jeton uç noktalarını" yapılandırabilir Apigee Edge'de çalışıyor. Bu durumda Edge Yetkilendirme sunucusu.
- Yetkilendirme izni: Uygulamaya erişim alma izni verir jetonuna sahip olmanız gerekir. OAuth 2.0, dört özel "izin türünü" tanımlar. "OAuth 2.0 izin türleri nelerdir?" bölümüne göz atın.
- Erişim jetonu: Kimlik bilgisi olarak işlev gören uzun bir karakter dizesi korunan kaynaklara erişmek için kullanılır. Ayrıca bkz. "Erişim nedir? anahtarı nedir?" bölümüne göz atı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 yeri
Apigee Edge üzerinden proxy uygulanan tüm API'leri OAuth 2.0 ile koruyabilirsiniz. Edge, bir gerçekleştirebilir ve bu nedenle erişim jetonlarını oluşturup doğrulayabilir. Geliştiriciler, uygulamalarını Apigee Edge'e kaydederek işe koyulmaktadır. Kayıtlı uygulamalar, erişim jetonlarını dört izin verme seçeneğinden herhangi biriyle tür etkileşimleri hakkında bilgi edinin.
Apigee, şunu uygulayan çok yönlü bir OAuthV2 politikası sunar: bu şekilde, Apigee Edge'de OAuth kurulumu nispeten kolay hale gelmiştir. Örneğin, Örneğin, erişim jetonu için istek alan, tüm istekleri değerlendiren ve gereken kimlik bilgilerini döndürür ve kimlik bilgileri geçerliyse bir erişim jetonu döndürür.
Güvenli API proxy çağrılarınızın bulunduğu tüm kaynak sunucularının güvenlik duvarı arkasında olması gerektiğini unutmayın. (yani kaynaklara, API proxy'si veya başka bir yol dışında hiçbir yolla erişilememelidir) güvenli bir API) kullandığınızdan emin olun.
OAuth 2.0 nedir? izin türleri nelerdir?
İzin türlerini, bir uygulamanın erişim elde etmek için izleyebileceği farklı yollar veya etkileşimler olarak düşünebilirsiniz jeton. Her izin türü, bir veya daha fazla kullanım alanını ele alır. uygun olarak seçeceğiz. Genel olarak her hibe türünün avantajları ve dezavantajları vardır ve iş kullanım alanlarınıza göre dengeyi değerlendirmeniz gerekir. Bir "güvenilirlik" olduğundan ne kadar verilerinize erişecek uygulamaları görmenizi sağlar. Genel olarak üçüncü taraf uygulamaları, aynı programda geliştirilen ve kullanılan uygulamalardan daha az güvenilirdir. kurumsal
Apigee Edge, dört ana OAuth 2.0 izin türünü destekler:
- yetkilendirme kodu - En güvenli izin türü olarak kabul edilir. Şu tarihten önce: yetkilendirme sunucusu bir erişim jetonu yayınlar, uygulamanın önce bir yetkilendirme kodu alması gerekir . Uygulamanız kaynak sunucusunun giriş sayfasına yönlendirilir ve gerçek hesabınıza giriş yapmanızı Facebook veya Twitter).
Başarıyla giriş yaparsanız, uygulama bir yetkilendirme alır karar vermek için kullanabileceğiniz kodu içerir. Genellikle bu izin türü, uygulama istemcide değil sunucuda bulunuyorsa kullanılır. Bu izin türü kullanıcı adını veya kullanıcı adını hiçbir zaman işlemediği ya da görmediği için şifresinin çözülmesini sağlar (örneğin, uygulama, şifrenizi hiçbir zaman görmez veya Twitter kimlik bilgileri). Bu izin türü akışı "üç ayaklı" olarak da adlandırılır OAuth
- implicit -- Yetkilendirme kodunun basitleştirilmiş bir sürümü olarak kabul edilir. Bu izin türü genellikle uygulama istemcide yer aldığında kullanılır. Örneğin, uygulamanın kodu, JavaScript veya başka bir kodlama dili ( ayrı bir web sunucusunda ikamet eden ve çalıştırılan) bir web sunucusudur. Bu izin türü akışında, yetkilendirme Kullanıcının kimliği doğrulandığında sunucu, bir erişim jetonu vermek yerine bir yetkilendirme kodunu kullanın. Örtülü bağışlar bazı durumlarda uygulamanın duyarlılığını artırabilir Bu avantajın, IETF spesifikasyonu.
- kaynak sahibi şifre kimlik bilgileri -- Bu akışta, istemciye Kullanıcının kullanıcı adı/şifresi yetkilendirme sunucusu tarafından doğrulandığında bir erişim jetonu. Bu akış ileri düzeyde güvenilir uygulamalar için önerilir. Bu akışın sunduğu bir diğer avantaj ise kullanıcının, kullanıcı adını/şifresini yalnızca bir kez göstermesidir. O zamandan itibaren açık olduğunda erişim jetonu kullanılır.
- client kimlik bilgileri -- İstemcinin uygulama kendi adına hareket ediyor. Diğer bir deyişle, istemci aynı zamanda kaynağın sahibidir. Bu hibe türü, genellikle uygulamanın bir arka uç veri depolama hizmetine erişmesi gerektiğinde ve örneğine bakalım. Uygulamanın işini yapmak için hizmeti kullanması gerekiyor ancak hizmet bunun dışında opak oluyor anlamaya başladım. Bu izin türüyle uygulamalar, istemci kimliği ve istemci gizli anahtarlarını yetkilendirme sunucusuna bağlayabilirsiniz. Başka bir işlem yapılmasına gerek yoktur. Edge, tüm cihazlarınız için kolayca uygulayabileceğiniz, kullanıma hazır bir istemci kimlik bilgisi çözümü sunar. API proxy'si.
Erişim nedir? jeton mu var?
Erişim jetonu, erişim için kullanılan kimlik bilgisi niteliğinde olan uzun bir karakter dizesidir korunuyor. Kaynak jetonları (hamiline ait jetonlar olarak da adlandırılır) Yetkilendirme'de iletilir şuna benzer:
$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \ http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282
Kaynak sunucu, erişim jetonunun "durum" olduğunu anlar gibi kimlik bilgileri için kullanıcı adınız ve şifreniz. Ayrıca, erişim jetonları kısıtlamalarla verilebilir. Bu nedenle Örneğin, uygulama kaynak sunucudaki verileri okuyabilir ancak yazamaz veya silemez. Not: erişim jetonu, örneğin, uygulamanın güvenliği ihlal edilirse iptal edilebilir. Bu durumda, Uygulamayı kullanmaya devam etmek üzere yeni bir erişim jetonu almak için; ancak yine de korunan kaynaklar sunucusundaki kullanıcı adı veya şifre (örneğin, Facebook veya Twitter) ekleyin.
Erişim jetonlarının genellikle bir son kullanma tarihi vardır (güvenlik nedeniyle). Bazı hibe türleri, yetkilendirme sunucusunun, uygulamanın yeni bir erişim jetonu getirmesine olanak tanıyan bir yenileme jetonu vermesini sağlama ve eskisinin geçerliliği sona erdiğinde. Erişim ve yenileme jetonları hakkında daha fazla bilgi için IETF OAuth'a bakın 2.0 spesifikasyonu.
Sınırlı erişim kapsamlar
OAuth 2.0, kapsam mekanizması aracılığıyla bir uygulamaya korumalı kaynaklar. Örneğin, bir uygulama yalnızca belirli kaynaklara erişebiliyor olabilir ve veya yalnızca okuma erişimi verilebilir. “Üç ayaklı” denilenin altında OAuth akışları, Kullanıcı genellikle bir izin sayfası (örneğin, bir web sayfası kullanıcı başka bir mekanizmanın onay kutusuyla kapsamı seçer).
Uygulama kaydetme
Tüm istemciler (uygulamalar), çıktıkları OAuth 2.0 yetkilendirme sunucusuna erişim jetonları istemeyi planlar. Bir uygulamayı kaydettiğinizde bir dizi anahtar alırsınız. Biri istemci kimliği adı verilen bir ortak anahtar, diğeri ise istemci adı verilen bir gizli anahtardır sır. Uygulamalar bu anahtarlar olmadan yetkilendirme kodları veya erişim jetonları için istek gönderemez gönderilmesi gerekir. IETF OAuth spesifikasyonunda bu anahtarların istemcisini çağırdığını unutmayın Kimlik ve istemci gizli anahtarı, Apigee Edge kullanıcı arayüzü tarafından Tüketici Kimliği ve Tüketici sırrı olarak adlandırılır. Bunlar: eşdeğerdir.
OAuth 2.0 kullanım alanlarının özeti
Hangi OAuth 2.0 izin türü akışını uygulamayı seçtiğiniz özel kullanım alanınıza bağlıdır: bazı izin türleri diğerlerinden daha güvenlidir. Hibe türü seçiminiz, güvenilir olduğunu ve aşağıdaki konumda açıklandığı gibi çok dikkatli bir şekilde değerlendirilmesini gerektirir: aşağıdaki tabloda bulabilirsiniz:
| Kullanım Örneği | İtimat | Önerilen OAuth 2.0 Yetkilendirme İzni Türleri | Açıklama |
|---|---|---|---|
| B2B (extranet), intranet, diğer |
Dahili bir geliştirici veya güvenilir bir firmanın geliştirdiği geliştiriciler tarafından yazılmış yüksek düzeyde güvenilir uygulamalar iş ilişkisinden bahsedeceğiz. Kaynaklara kendi adlarına erişmesi gereken uygulamalar. |
|
|
| İntranet siteleri, portallar |
Dahili veya güvenilir üçüncü taraf geliştiriciler tarafından yazılan güvenilir uygulamalar. Sigorta seçimi yapmak için şirketinizin İK sitesine giriş yapmak buna örnek olarak verilebilir. Yorum gönderme veya kişisel bilgileri değiştirme. |
|
|
| Herkese açık uygulamalar | Güvenilir olmayan uygulamalar, güvenilir bir işletmeye sahip olmayan üçüncü taraf geliştiriciler tarafından yazılmıştır Google'ın API sağlayıcısı ile ilişkisi var. Örneğin, herkese açık API için kaydolan geliştiriciler güvenilmemesi gerekir. |
|
|
| B2C | Süreç için bir bireysel son kullanıcı (mobil kullanıcı) söz konusudur ve kullanıcı kimlik bilgileri depolanır mobil cihazda. |
|
|
OAuth 2.0 ve API anahtarı karşılaştırması güvenlik
API anahtarı doğrulama işlemi için bir uygulamanın Edge'e anahtar göndermesi gerekir. Anahtar geçerli bir tüketici anahtarı olmalıdır veya API proxy'si ile ilişkili bir Apigee Edge geliştirici uygulamasından alabilirsiniz. Herhangi bir nedenle proxy'ye çağrı yapması için bir istemci uygulamasının iznini iptal etmeniz gerekiyorsa, bunu tüketici anahtarı. Bu anahtarı kullanan istemci uygulamaları da API proxy'sine erişemez. OAuth jetonu, uygulamanın anahtarları iptal edilmeden istenildiği zaman iptal edilebilir. Uygulama kullanıcı adına yeni bir jeton isteyebilir ve bir jeton verilirse, uygulama ve API proxy'sini kullanmaya devam edebilir.
API anahtarı ile jeton arasındaki başka bir fark da jeton, meta verileri içerebilir. özellikleri hakkında daha fazla bilgi edinin. Örneğin, kullanıcının kimliğini bu API çağrısını yapma ve arka uç hedef hizmetine yapılan çağrıları özelleştirmek için kullanma.
API anahtarı doğrulamayla ilgili ayrıntılar için API'ye bakın. tuşlar. OAuth jetonlarıyla özel özellikler kullanma hakkında bilgi için bkz. Jetonları ve Jetonları Yetkilendirme Kodları bölümüne bakın.
Önerilen kaynaklar
Okuma
OAuth 2.0 hakkında bilgi edinme sayfasına göz atın.