OAuthV2 politikası

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

Ne?

OAuthV2, OAuth 2.0 izin türü işlemlerini gerçekleştirmek için çok yönlü bir politikadır. Bu, Apigee Edge'de OAuth 2.0 uç noktalarını yapılandırmak için kullanılan birincil politikadır.

İpucu: Apigee Edge'de OAuth hakkında daha fazla bilgi edinmek istiyorsanız OAuth ana sayfasına bakın. Kaynaklara, örneklere, videolara ve daha fazlasına bağlantılar sağlar. Bu politikanın çalışan bir uygulamada nasıl kullanıldığını gösteren iyi bir örnek için GitHub'daki gelişmiş OAuth örneğine bakın.

Örnekler

<OAuthV2 async="false" continueOnError="false" enabled="true" name="OAuth-v20-2">
    <DisplayName>OAuth v2.0 2</DisplayName>
    <Operation>VerifyAccessToken</Operation>
    <AccessTokenPrefix>Bearer</AccessTokenPrefix> <!-- Optional, default is Bearer -->
</OAuthV2>

$ curl -H "Authorization: Bearer ylSkZIjbdWybfsUQe9BqP0LH5Z" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282

<OAuthV2 enabled="true" continueOnError="false" async="false" name="generateAccessToken">
    <Operation>GenerateAccessToken</Operation>
    <AppEndUser>Doe</AppEndUser>
    <UserName>jdoe</UserName>
    <PassWord>jdoe</PassWord>
    <GrantType>grant_type</GrantType>
    <ClientId>a_valid_client_id</ClientId>
    <SupportedGrantTypes>
        <GrantType>password</GrantType>
    </SupportedGrantTypes>
</OAuthV2>

var client_id = context.getVariable("local_clientid");
var client_secret = context.getVariable("local_secret");
context.setVariable("request.header.Authorization","Basic "+CryptoJS.enc.Base64.stringify(CryptoJS.enc.Latin1
                                      .parse(client_id + ':' + client_secret)));

Ayrıca bkz. "Temel kimlik doğrulama kimlik bilgilerini kodlama".

Öğe referansı

Politika referansında OAuthV2 politikasının öğeleri ve özellikleri açıklanır.

Aşağıda gösterilen örnek politika, olası birçok yapılandırmadan biridir. Bu örnekte, GenerateAccessToken işlemi için yapılandırılmış bir OAuthV2 politikası gösterilmektedir. Zorunlu ve isteğe bağlı öğeleri içerir. Ayrıntılar için bu bölümdeki öğe açıklamalarına bakın.

<OAuthV2 name="GenerateAccessToken">
  <!-- This policy generates an OAuth 2.0 access token using the client_credentials grant type -->
  <Operation>GenerateAccessToken</Operation>
  <!-- This is in millseconds, so expire in an hour -->
  <ExpiresIn>3600000</ExpiresIn>
  <SupportedGrantTypes>
    <GrantType>client_credentials</GrantType>
  </SupportedGrantTypes>
  <GrantType>request.queryparam.grant_type</GrantType>
  <GenerateResponse/>
</OAuthV2>

<OAuthV2> özellikleri

<OAuthV2 async="false" continueOnError="false" enabled="true" name="MyOAuthPolicy">

Aşağıdaki tabloda tüm politika üst öğelerinde ortak olan özellikler açıklanmaktadır:

&lt;DisplayName&gt; öğe

Politikayı name özelliğine ek olarak farklı bir doğal dil adına sahip yönetim arayüzü proxy düzenleyicisi.

<DisplayName>Policy Display Name</DisplayName>

<AccessToken> öğesi

<AccessToken>request.header.access_token</AccessToken>

Varsayılan olarak VerifyAccessToken, erişim jetonunun Authorization üst bilgisinde gönderilmesini bekler. Bu varsayılan öğeyi kullanarak değiştirebilirsiniz. Örneğin, request.queryparam.access_token, erişim jetonunun access_token adlı bir sorgu parametresi olarak mevcut olması gerektiğini belirtir.

curl https://myorg-myenv.apigee.net/oauth2/validate -H "access_token:Rft3dqrs56Blirls56a"

curl "https://myorg-myenv.apigee.net/oauth2/validate?access_token:Rft3dqrs56Blirls56a"

<AccessTokenPrefix> öğesi

<AccessTokenPrefix>Bearer</AccessTokenPrefix>

Varsayılan olarak VerifyAccessToken, erişim jetonunun bir Yetkilendirme üst bilgisinde Taşıyıcı jetonu olarak gönderilmesini bekler. Örneğin:

-H "Authorization: Bearer Rft3dqrs56Blirls56a"

Şu anda yalnızca Bearer ön eki desteklenmektedir.

<AppEndUser> öğesi

<AppEndUser>request.queryparam.app_enduser</AppEndUser>

Uygulama son kullanıcı kimliğinin yetkilendirme sunucusuna gönderilmesi gerektiğinde bu öğe, Edge'in son kullanıcı kimliğini nerede aradığını belirtmenize olanak tanır. Örneğin, sorgu parametresi veya HTTP başlığı olarak gönderilebilir.

Örneğin request.queryparam.app_enduser, AppEndUser parametresinin sorgu parametresi olarak (ör. ?app_enduser=ntesla@theramin.com) bulunmasını belirtir. Örneğin, bir HTTP üstbilgisinde AppEndUser değerini zorunlu kılmak için bu değeri request.header.app_enduser olarak ayarlayın.

Bu ayarı belirtmek, erişim jetonuna bir uygulama son kullanıcı kimliği eklemenizi sağlar. Bu özellik, OAuth 2.0 erişim jetonlarını son kullanıcı kimliğine göre almak veya iptal etmek istiyorsanız kullanışlıdır. Daha fazla bilgi için OAuth 2.0 erişim jetonlarının son kullanıcı kimliğine, uygulama kimliğine veya her ikisine göre alınmasını ve iptal edilmesini etkinleştirme başlıklı makaleyi inceleyin.

<Özellikler/Özellik>

<Attributes>
    <Attribute name="attr_name1" ref="flow.variable" display="true|false">value1</Attribute>
    <Attribute name="attr_name2" ref="flow.variable" display="true|false">value2</Attribute>
</Attributes>

Erişim jetonuna veya yetkilendirme koduna özel özellikler eklemek için bu öğeyi kullanın. Örneğin, bir erişim jetonuna kullanıcı kimliği veya oturum tanımlayıcısı yerleştirmek isteyebilirsiniz. Bu kimlik, çalışma zamanında ayıklanıp kontrol edilebilir.

Bu öğe, bir akış değişkeninde veya değişmez dizedeki bir değeri belirtmenize olanak tanır. Hem bir değişken hem de bir dize belirtirseniz akış değişkeninde belirtilen değer kullanılır. Değişken çözümlenemezse dize varsayılan olur.

Bu öğeyi kullanma hakkında daha fazla bilgi için Jetonları ve Yetkilendirme Kodlarını Özelleştirme başlıklı makaleyi inceleyin.

Yanıtta özel özellikleri görüntüleme veya gizleme

Bu politikanın GenerateResponse öğesini true olarak ayarlarsanız belirlediğiniz tüm özel özellikler dahil olmak üzere jetonun tam JSON temsilinin yanıtta döndürüleceğini unutmayın. Bazı durumlarda, istemci uygulamaları tarafından görülemeyecek şekilde özel özelliklerinizin bir kısmını veya tamamını yanıtta gizlemek isteyebilirsiniz.

Özel özellikler varsayılan olarak yanıtta görünür. Bunları gizlemek isterseniz display parametresini false olarak ayarlayabilirsiniz. Örneğin:

<Attributes>
    <Attribute name="employee_id" ref="employee.id" display="false"/>
    <Attribute name="employee_name" ref="employee.name" display="false"/>
</Attributes>

display özelliğinin değeri kalıcı değildir. Oluşturulan yanıtta gizlemek istediğiniz özel özelliklere sahip bir erişim jetonu oluşturduğunuzu varsayalım. display=false ayarını yaparak bu hedefe ulaşabilirsiniz. Bununla birlikte, daha sonra yenileme jetonu kullanılarak yeni bir erişim jetonu oluşturulursa erişim jetonundaki orijinal özel özellikler, yenileme jetonu yanıtında gösterilir. Bunun nedeni, Edge'in display özelliğinin erişim jetonu oluşturma politikasında başlangıçta false olarak ayarlandığını hatırlamamasıdır. Özel özellik, erişim jetonunun meta verilerinin bir parçasıdır.

Bir yetkilendirme koduna özel özellikler eklerseniz aynı davranışı görürsünüz. Bu kod kullanılarak bir erişim jetonu oluşturulduğunda, bu özel özellikler erişim jetonu yanıtında gösterilir. Bu, amaçladığınız davranış olmayabilir.

Bu durumlarda özel özellikleri gizlemek için aşağıdaki seçeneklerden yararlanabilirsiniz:

• Yenileme jetonu politikasındaki özel özellikleri açıkça sıfırlayın ve bunların görüntülenmesini yanlış olarak ayarlayın. Bu durumda, GetOAuthV2Info politikasını kullanarak orijinal erişim jetonundan orijinal özel değerleri almanız gerekebilir.
• Yanıtta görmek istemediğiniz özel özellikleri manuel olarak ayıklamak için bir son işlem JavaScript politikası kullanın.

Ayrıca Jetonları ve Yetkilendirme Kodlarını Özelleştirme başlıklı makaleyi de inceleyin.

<ClientId> öğesi

<ClientId>request.formparam.client_id</ClientId>

Bazı durumlarda istemci uygulamasının istemci kimliğini yetkilendirme sunucusuna göndermesi gerekir. Bu öğe, Apigee'nin request.formparam.client_id akış değişkeninde müşteri kimliğini araması gerektiğini belirtir. ClientId değerinin başka bir değişkene ayarlanması desteklenmez. Ayrıca Erişim jetonları ve yetkilendirme kodları isteme başlıklı makaleyi de inceleyin.

<Code> öğesi

<Code>request.queryparam.code</Code>

Yetkilendirme bağışı türü akışında istemcinin yetkilendirme sunucusuna (Apigee Edge) bir yetkilendirme kodu göndermesi gerekir. Bu öğe, Edge'in yetkilendirme kodunu nerede araması gerektiğini belirtmenize olanak tanır. Örneğin, sorgu parametresi, HTTP başlığı veya form parametresi (varsayılan) olarak gönderilebilir.

request.queryparam.auth_code değişkeni, yetkilendirme kodunun sorgu parametresi olarak (ör. ?auth_code=AfGlvs9) mevcut olması gerektiğini belirtir. Örneğin, bir HTTP başlığında yetkilendirme kodunu zorunlu kılmak için bu değeri request.header.auth_code olarak ayarlayın. Ayrıca Erişim jetonları ve yetkilendirme kodları isteme başlıklı makaleyi de inceleyin.

<ExpiresIn> öğesi

<ExpiresIn>10000</ExpiresIn> 

Erişim jetonlarının ve yetkilendirme kodlarının geçerlilik bitiş zamanını milisaniye cinsinden zorunlu kılar. (Yenileme jetonları için <RefreshTokenExpiresIn> kullanın.) Süre sonu değeri, sistem tarafından oluşturulan bir değere <ExpiresIn> değeri eklenerek hesaplanır. <ExpiresIn> -1 olarak ayarlanırsa jeton veya kodun geçerlilik süresi maksimum OAuth erişim jetonu geçerlilik süresi'ne göre sona erer. <ExpiresIn> belirtilmezse sistem, sistem düzeyinde yapılandırılan bir varsayılan değer uygular.

Geçerlilik süresi ayrıca çalışma zamanında sabit kodlu bir varsayılan değer veya bir akış değişkenine referans vererek de ayarlanabilir. Örneğin, bir jetonun geçerlilik bitiş tarihini anahtar/değer çiftinde saklayabilir, alabilir, bir değişkene atayabilir ve politikada referans verebilirsiniz. Örneğin, kvm.oauth.expires_in.

Herkese Açık Bulut için Apigee Edge ile Edge, aşağıdaki varlıklara erişim sağlandıktan sonra bu varlıkları en az 180 saniye boyunca önbellekte tutar.

• OAuth erişim jetonları. Bu da iptal edilen bir jetonun, önbellek sınırı sona erene kadar üç dakika kadar başarılı olmaya devam edebileceği anlamına gelir.
• Anahtar Yönetim Hizmeti (KMS) varlıkları (Uygulamalar, Geliştiriciler, API Ürünleri).
• OAuth jetonları ve KMS varlıkları üzerindeki özel özellikler.

Aşağıdaki dörtlükte bir akış değişkeni ve varsayılan değer de belirtilmiştir. Akış değişkeni değerinin, belirtilen varsayılan değere göre öncelikli olduğunu unutmayın.

<ExpiresIn ref="kvm.oauth.expires_in">
    3600000 <!--default value in milliseconds-->
</ExpiresIn>

Edge, oluşturulduktan sonra jetonun süresinin dolmasını zorunlu kılmayı desteklemez. Jeton geçerlilik süresini zorunlu kılmanız gerekiyorsa (örneğin, bir koşula göre) bu Apigee topluluk gönderisinde olası bir çözümden yararlanabilirsiniz.

Varsayılan olarak, süresi dolan erişim jetonları, geçerlilik bitiş tarihinden 3 gün sonra Apigee Edge sisteminden otomatik olarak temizlenir. Ayrıca bkz. Erişim jetonlarını silme

Private Cloud: Private Cloud için Edge kurulumunda varsayılan değer conf_keymanagement_oauth_auth_code_expiry_time_in_millis mülkü tarafından belirlenir. Bu özelliği ayarlamak için:

1. message-processor.properties dosyasını bir düzenleyicide açın. Dosya yoksa oluşturun:

   vi /opt/apigee/customer/application/message-processor.properties

2. Tesisi istediğiniz gibi ayarlayın:

   conf_keymanagement_oauth_auth_code_expiry_time_in_millis=3600000

3. properties dosyasının sahibinin "apigee" kullanıcısı olduğundan emin olun:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. Mesaj işleyiciyi yeniden başlatın.

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

<ExternalAccessToken> öğesi

<ExternalAccessToken>request.queryparam.external_access_token</ExternalAccessToken>

Apigee Edge'e harici erişim jetonunu (Apigee Edge tarafından oluşturulmayan bir erişim jetonu) nerede bulacağını söyler.

request.queryparam.external_access_token değişkeni, harici erişim jetonunun bir sorgu parametresi olarak (örneğin, ?external_access_token=12345678) bulunması gerektiğini belirtir. Örneğin, bir HTTP üst bilgisinde harici erişim jetonunu zorunlu kılmak için bu değeri request.header.external_access_token olarak ayarlayın. Üçüncü Taraf OAuth Jetonlarını Kullanma bölümüne de göz atın.

<ExternalAuthorization> öğesi

<ExternalAuthorization>true</ExternalAuthorization>

Bu öğe yanlışsa veya mevcut değilse Edge, client_id ve client_secret öğelerini normalde Apigee Edge yetkilendirme deposuna göre doğrular. Üçüncü taraf OAuth jetonlarıyla çalışmak istediğinizde bu öğeyi kullanın. Bu öğeyi kullanmayla ilgili ayrıntılar için Üçüncü Taraf OAuth Jetonlarını Kullanma başlıklı makaleyi inceleyin.

<ExternalAuthorizationCode> öğesi

<ExternalAuthorizationCode>request.queryparam.external_auth_code</ExternalAuthorizationCode>

Apigee Edge'e harici kimlik doğrulama kodunu (Apigee Edge tarafından oluşturulmayan bir kimlik doğrulama kodu) nerede bulacağını söyler.

request.queryparam.external_auth_code değişkeni, harici yetkilendirme kodunun bir sorgu parametresi olarak (örneğin, ?external_auth_code=12345678) bulunması gerektiğini belirtir. HTTP başlığında harici kimlik doğrulama kodunu zorunlu kılmak için bu değeri request.header.external_auth_code olarak ayarlayın. Üçüncü Taraf OAuth Jetonlarını Kullanma bölümüne de göz atın.

<ExternalRefreshToken> öğesi

<ExternalRefreshToken>request.queryparam.external_refresh_token</ExternalRefreshToken>

Apigee Edge'e harici bir yenileme jetonunu (Apigee Edge tarafından oluşturulmayan bir yenileme jetonu) nerede bulacağını bildirir.

request.queryparam.external_refresh_token değişkeni, harici yenileme jetonunun bir sorgu parametresi olarak (örneğin, ?external_refresh_token=12345678) bulunması gerektiğini belirtir. Örneğin, bir HTTP başlığında harici yenileme jetonunu zorunlu kılmak için bu değeri request.header.external_refresh_token olarak ayarlayın. Üçüncü Taraf OAuth Jetonlarını Kullanma başlıklı makaleyi de inceleyin.

<GenerateResponse> öğesi

<GenerateResponse enabled='true'/>

true olarak ayarlanırsa politika bir yanıt oluşturur ve döndürür. Örneğin, GenerateAccessToken için yanıt şu şekilde olabilir:

{
  "issued_at" : "1467841035013",
  "scope" : "read",
  "application_name" : "e31b8d06-d538-4f6b-9fe3-8796c11dc930",
  "refresh_token_issued_at" : "1467841035013",
  "status" : "approved",
  "refresh_token_status" : "approved",
  "api_product_list" : "[Product1, nhl_product]",
  "expires_in" : "1799",
  "developer.email" : "edward@slalom.org",
  "token_type" : "BearerToken",
  "refresh_token" : "rVSmm3QaNa0xBVFbUISz1NZI15akvgLJ",
  "client_id" : "Adfsdvoc7KX5Gezz9le745UEql5dDmj",
  "access_token" : "AnoHsh2oZ6EFWF4h0KrA0gC5og3a",
  "organization_name" : "cerruti",
  "refresh_token_expires_in" : "0",
  "refresh_count" : "0"
}

false ise yanıt gönderilmez. Bunun yerine, bir akış değişkeni grubu, politikanın işleviyle ilgili değerlerle doldurulur. Örneğin, oauthv2authcode.OAuthV2-GenerateAuthorizationCode.code adlı bir akış değişkeni, yeni oluşturulan yetkilendirme koduyla doldurulur. expires_in değerinin yanıtta saniye cinsinden ifade edildiğini unutmayın.

<GenerateErrorResponse> öğesi

<GenerateErrorResponse enabled='true'/>

true olarak ayarlanırsa politika, ContinueOnError özniteliği doğru olarak ayarlanırsa bir yanıt oluşturur ve döndürür. false (varsayılan) ise yanıt gönderilmez. Bunun yerine, bir akış değişkeni grubu, politikanın işleviyle ilgili değerlerle doldurulur.

<GrantType>

<GrantType>request.queryparam.grant_type</GrantType>

Politikaya, bir istekte iletilen grant type parametresini nerede bulacağını bildirir. OAuth 2.0 spesifikasyonuna göre, erişim jetonu ve yetkilendirme kodu istekleriyle birlikte izin türü sağlanmalıdır. Değişken bir başlık, sorgu parametresi veya form parametresi (varsayılan) olabilir.

Örneğin request.queryparam.grant_type, Password'ün bir sorgu parametresi olarak (örneğin, ?grant_type=password) sunulması gerektiğini belirtir. Bir HTTP başlığında izin türünü zorunlu kılmak için bu değeri request.header.grant_type olarak ayarlayın. Ayrıca, Erişim jetonları ve yetkilendirme kodları isteme konusuna da bakın.

<Operation> öğesi

<Operation>GenerateAuthorizationCode</Operation>

Politika tarafından yürütülen OAuth 2.0 işlemi.

<PassWord> öğesi

<PassWord>request.queryparam.password</PassWord>

Bu öğe yalnızca şifre izin türüyle kullanılır. Şifre verme türünde, kullanıcı kimlik bilgileri (şifre ve kullanıcı adı) OAuthV2 politikasına sunulmalıdır. <PassWord> ve <UserName> öğeleri, Edge'in bu değerleri bulabileceği değişkenleri belirtmek için kullanılır. Bu öğeler belirtilmezse politika, değerleri (varsayılan olarak) username ve password adlı form parametrelerinde bulmayı bekler. Değerler bulunamazsa politika bir hata verir. Kimlik bilgilerini içeren herhangi bir akış değişkenine referans vermek için <PassWord> ve <UserName> öğelerini kullanabilirsiniz.

Örneğin, bir sorgu parametresi kullanarak şifreyi jeton isteğinde iletebilir ve öğeyi şu şekilde ayarlayabilirsiniz: <PassWord>request.queryparam.password</PassWord>. HTTP üst bilgisinde şifrenin zorunlu kılınmasını istiyorsanız bu değeri request.header.password olarak ayarlayın.

OAuthV2 politikası bu kimlik bilgisi değerleriyle başka bir işlem yapmaz. Edge yalnızca bunların mevcut olduğunu doğrular. Değer isteğini almak ve jeton oluşturma politikası yürütülmeden önce bunları bir kimlik sağlayıcıya göndermek API geliştiricisine bağlıdır.

Ayrıca Erişim jetonları ve yetkilendirme kodları isteme başlıklı makaleyi de inceleyin.

<RedirectUri> öğesi

<RedirectUri>request.queryparam.redirect_uri</RedirectUri>

Edge'in istekteki redirect_uri parametresini nerede araması gerektiğini belirtir.

Yönlendirme URI'leri hakkında

Yönlendirme URI'leri, yetkilendirme kodu ve gizli izin türleriyle kullanılır. Yönlendirme URI'si, yetkilendirme sunucusuna (Edge) yetkilendirme kodunun (yetkilendirme kodu izin türü için) veya erişim jetonunun (örtülü izin türü için) nereye gönderileceğini bildirir. Bu parametrenin ne zaman gerekli olduğunu, ne zaman isteğe bağlı olduğunu ve nasıl kullanıldığını anlamak önemlidir:

• (zorunlu) Geliştirici uygulamasına, istek istemci anahtarlarıyla ilişkili bir Geri Çağırma URL'si kaydedilmişse ve istekte redirect_uri varsa bu iki URL tam olarak eşleşmelidir. Eşleşmezlerse hata döndürülür. Geliştirici uygulamalarını Edge'de kaydetme ve geri çağırma URL'si belirtme hakkında bilgi edinmek için Uygulama kaydetme ve API anahtarlarını yönetme başlıklı makaleyi inceleyin.

• (isteğe bağlı) Geri çağırma URL'si kaydedilmişse ve istekte redirect_uri yoksa Edge, kaydedilen geri çağırma URL'sine yönlendirir.
• (zorunlu) Geri çağırma URL'si kaydedilmemişse redirect_uri gereklidir. Bu durumda Edge'in HERHANGİ bir URL'yi kabul edeceğini unutmayın. Bu durum güvenlik sorunu oluşturabileceğinden yalnızca güvenilir istemci uygulamalarıyla kullanılmalıdır. İstemci uygulamalarına güvenilmiyorsa en iyi uygulama, her zaman bir Geri Çağırma URL'sinin kaydedilmesini zorunlu kılmaktır.

Bu parametreyi bir sorgu parametresinde veya başlıkta gönderebilirsiniz. request.queryparam.redirect_uri değişkeni, RedirectUri parametresinin bir sorgu parametresi olarak (ör. ?redirect_uri=login.myapp.com) bulunmasını belirtir. HTTP başlığında RedirectUri değerinin zorunlu kılınmasını istiyorsanız bu değeri request.header.redirect_uri olarak ayarlayın. Erişim jetonları ve yetkilendirme kodları isteme başlıklı makaleyi de inceleyin.

<RefreshToken> öğesi

<RefreshToken>request.queryparam.refreshtoken</RefreshToken>

Yenileme jetonu kullanarak erişim jetonu istediğinizde istekte yenileme jetonunu sağlamanız gerekir. Bu öğe, Edge'in yenileme jetonunu nerede araması gerektiğini belirtmenize olanak tanır. Örneğin; sorgu parametresi, HTTP üst bilgisi veya form parametresi (varsayılan) olarak gönderilebilir.

request.queryparam.refreshtoken değişkeni, yenileme jetonunun bir sorgu parametresi olarak (örneğin, ?refresh_token=login.myapp.com) bulunması gerektiğini belirtir. Örneğin, bir HTTP üstbilgisinde RefreshToken'ı zorunlu kılmak için bu değeri request.header.refresh_token olarak ayarlayın. Erişim jetonları ve yetkilendirme kodları isteme başlıklı makaleyi de inceleyin.

<RefreshTokenExpirationIn> öğesi

<RefreshTokenExpiresIn>1000</RefreshTokenExpiresIn>

Yenileme jetonlarının geçerlilik süresini milisaniye cinsinden zorlar. Süre sonu değeri, sistem tarafından oluşturulan bir değere <RefreshTokenExpiresIn> değeri eklenerek hesaplanır. <RefreshTokenExpiresIn> -1 olarak ayarlanırsa yenileme jetonunun süresi maksimum OAuth yenileme jetonu son kullanma tarihine göre dolar. <RefreshTokenExpiresIn> belirtilmezse sistem, sistem düzeyinde yapılandırılan varsayılan bir değeri uygular. Varsayılan sistem ayarları hakkında daha fazla bilgi için Apigee Edge Destek ile iletişime geçin.

Süre sonu, kodlanmış bir varsayılan değer kullanılarak veya bir akış değişkenine referans verilerek çalışma zamanında da ayarlanabilir. Örneğin, bir jetonun geçerlilik bitiş tarihini anahtar/değer çiftinde saklayabilir, alabilir, bir değişkene atayabilir ve politikada referans verebilirsiniz. Örneğin, kvm.oauth.expires_in.

Aşağıdaki dörtlükte bir akış değişkeni ve varsayılan değer de belirtilmiştir. Akış değişkeni değerinin, belirtilen varsayılan değere göre öncelikli olduğunu unutmayın.

<RefreshTokenExpiresIn ref="kvm.oauth.expires_in">
    3600000 <!--default value in milliseconds-->
</RefreshTokenExpiresIn>

Private Cloud: Private Cloud için Edge kurulumunda varsayılan değer conf_keymanagement_oauth_refresh_token_expiry_time_in_millis mülkü tarafından belirlenir. Bu özelliği ayarlamak için:

1. message-processor.properties dosyasını bir düzenleyicide açın. Dosya yoksa oluşturun:

   vi /opt/apigee/customer/application/message-processor.properties

2. Tesisi istediğiniz gibi ayarlayın:

   conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000

3. properties dosyasının sahibinin "apigee" kullanıcısı olduğundan emin olun:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. Mesaj işleyiciyi yeniden başlatın.

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

<ResponseType> öğesi

<ResponseType>request.queryparam.response_type</ResponseType>

Bu öğe, Edge'e istemci uygulamasının hangi izin türünü istediğini bildirir. Yalnızca yetkilendirme kodu ve örtülü izin türü akışlarıyla kullanılır.

Edge, varsayılan olarak yanıt türü değerini response_type sorgu parametresinde arar. Bu varsayılan davranışı geçersiz kılmak istiyorsanız yanıt türü değerini içeren bir akış değişkeni yapılandırmak için <ResponseType> öğesini kullanın. Örneğin, bu öğeyi request.header.response_type olarak ayarlarsanız Edge, istek başlığında iletilecek yanıt türünü arar. Ayrıca Erişim jetonları ve yetkilendirme kodları isteme başlıklı makaleyi de inceleyin.

<ReuseRefreshToken> öğesi

<ReuseRefreshToken>true</ReuseRefreshToken>

true olarak ayarlandığında mevcut yenileme jetonu, süresi dolana kadar yeniden kullanılır. false ise geçerli bir yenileme jetonu sunulduğunda Apigee Edge tarafından yeni bir yenileme jetonu verilir.

<Scope> öğesi

<Scope>request.queryparam.scope</Scope>

Bu öğe, GenerateAccessToken veya GenerateAuthorizationCode politikalarından birinde varsa jetonun veya kodun hangi kapsamlarda verileceğini belirtmek için kullanılır. Bu değerler genellikle istemci uygulamasından gelen istekte politikaya iletilir. Öğeyi bir akış değişkeni alacak şekilde yapılandırarak kapsamların bir istekte nasıl iletileceğini seçme seçeneği elde edebilirsiniz. Aşağıdaki örnekte request.queryparam.scope, alanın ?scope=READ gibi bir sorgu parametresi olarak mevcut olması gerektiğini gösterir. Bir HTTP üstbilgisinde kapsamın zorunlu kılınmasını istiyorsanız bu değeri request.header.scope olarak ayarlayın.

Bu öğe bir "VerifyAccessToken" politikasında görünüyorsa politikanın hangi kapsamları zorunlu kılması gerektiğini belirtmek için kullanılır. Bu tür politikalarda değer, "sabit kodlanmış" bir kapsam adı olmalıdır. Değişken kullanamazsınız. Örneğin:

<Scope>A B</Scope>

OAuth2 kapsamlarıyla çalışma ve Erişim jetonları ve yetkilendirme kodları isteme başlıklı makaleleri de inceleyin.

<State> öğesi

<State>request.queryparam.state</State>

İstemci uygulamasının durum bilgilerini yetkilendirme sunucusuna göndermesi gerektiği durumlarda bu öğe, Edge'in durum değerlerini nerede araması gerektiğini belirtmenize olanak tanır. Örneğin, bir sorgu parametresi veya HTTP başlığı olarak gönderilebilir. Durum değeri, genellikle CSRF saldırılarını önlemek için bir güvenlik önlemi olarak kullanılır.

Örneğin request.queryparam.state, durumun ?state=HjoiuKJH32 gibi bir sorgu parametresi olarak belirtilmesi gerektiğini gösterir. HTTP başlığında eyaletin zorunlu tutulmasını istiyorsanız bu değeri request.header.state olarak ayarlayın. Ayrıca bkz. Erişim jetonları ve yetkilendirme kodları isteme.

<StoreToken> öğesi

 <StoreToken>true</StoreToken> 

<ExternalAuthorization> öğesi true olduğunda bu öğeyi true olarak ayarlayın. <StoreToken> öğesi, Apigee Edge'e harici erişim jetonunu kaydetmesini söyler. Aksi takdirde kalıcı hale getirilmez.

<SupportedGrantTypes>/<GrantType> öğesi

<SupportedGrantTypes>
    <GrantType>authorization_code</GrantType>
    <GrantType>client_credentials</GrantType>
    <GrantType>implicit</GrantType>
    <GrantType>password</GrantType>
</SupportedGrantTypes>

Apigee Edge'de bir OAuth jeton uç noktası tarafından desteklenen izin türlerini belirtir. Bir uç nokta birden fazla izin türünü destekleyebilir (yani tek bir uç nokta, birden fazla izin türü için erişim jetonları dağıtacak şekilde yapılandırılabilir). Uç noktalar hakkında daha fazla bilgi için OAuth uç noktalarını anlama başlıklı makaleyi inceleyin. Grant türü, jeton isteklerinde grant_type parametresinde iletilir.

Desteklenen hibe türü belirtilmezse yalnızca authorization_code ve implicit hibe türlerine izin verilir. Ayrıca bkz. <GrantType> öğesi (Apigee Edge'in istemci isteğinde iletilen grant_type parametresini nerede araması gerektiğini belirtmek için kullanılan üst seviye bir öğe). Edge, grant_type parametresinin değerinin desteklenen izin türlerinden biriyle eşleştiğinden emin olur.

<Tokens>/<Token> öğesi

ValidateToken ve InvalidateToken işlemleriyle kullanılır. Ayrıca Erişim jetonlarını onaylama ve iptal etme başlıklı makaleyi inceleyin. <Token> öğesi, iptal edilecek jetonun kaynağını tanımlayan akış değişkenini tanımlar. Geliştiricilerin erişim jetonlarını access_token adlı sorgu parametreleri olarak göndermesi bekleniyorsa request.queryparam.access_token kullanın.

<UserName> öğesi

<UserName>request.queryparam.user_name</UserName>

Bu öğe yalnızca şifre izin türüyle kullanılır. Şifre verme türünde, kullanıcı kimlik bilgileri (şifre ve kullanıcı adı) OAuthV2 politikasına sunulmalıdır. <PassWord> ve <UserName> öğeleri, Edge'in bu değerleri bulabileceği değişkenleri belirtmek için kullanılır. Bu öğeler belirtilmezse politika, değerleri (varsayılan olarak) username ve password adlı form parametrelerinde bulmayı bekler. Değerler bulunamazsa politika bir hata verir. Kimlik bilgilerini içeren herhangi bir akış değişkenine referans vermek için <PassWord> ve <UserName> öğelerini kullanabilirsiniz.

Örneğin, kullanıcı adını bir sorgu parametresinde iletebilir ve <UserName> öğesini şu şekilde ayarlayabilirsiniz: <UserName>request.queryparam.username</UserName>.HTTP başlığında kullanıcı adını zorunlu kılmak için bu değeri request.header.username olarak ayarlayın.

OAuthV2 politikası, bu kimlik bilgisi değerleriyle başka bir işlem yapmaz. Edge, bunların mevcut olduğunu doğrular. Jeton oluşturma politikası uygulanmadan önce API geliştiricisinin, değerler isteğini alıp bir kimlik sağlayıcıya göndermesi gerekir.

Ayrıca Erişim jetonları ve yetkilendirme kodları isteme başlıklı makaleyi de inceleyin.

Erişim jetonlarını doğrulama

Bir API proxy'si için jeton uç noktası oluşturulduktan sonra, VerifyAccessToken işlemini belirten ilgili OAuthV2 politikası, korunan kaynağı gösteren akışa eklenir.

Örneğin, bir API'ye yapılan tüm isteklerin yetkilendirildiğinden emin olmak için aşağıdaki politika, erişim jetonu doğrulamasını zorunlu kılar:

<OAuthV2 name="VerifyOAuthAccessToken">
  <Operation>VerifyAccessToken</Operation>
</OAuthV2>

Politika, korunacak API kaynağına eklenir. Bir API'ye yapılan tüm isteklerin doğrulanmasını sağlamak için politikayı ProxyEndpoint istek ön akışına aşağıdaki gibi ekleyin:

<PreFlow>
  <Request>
    <Step><Name>VerifyOAuthAccessToken</Name></Step>
  </Request>
</PreFlow>

VerifyAccessToken işleminin varsayılan ayarlarını geçersiz kılmak için aşağıdaki isteğe bağlı öğeler kullanılabilir.

<OAuthV2 name="ValidateOauthScopePolicy">
  <Operation>VerifyAccessToken</Operation>
  <Scope>READ WRITE</Scope>
</OAuthV2>

Erişim jetonlarını doğrulama ve Erişim jetonları ile yetkilendirme kodları isteme başlıklı makaleleri de inceleyin.

İstek değişkeni konumlarını belirtme

Her izin türü için politika, istek mesajlarında konum veya gerekli bilgiler hakkında varsayımlarda bulunur. Bu varsayımlar OAuth 2.0 spesifikasyonuna dayanır. Uygulamalarınızın OAuth 2.0 spesifikasyonundan sapması gerekiyorsa her parametre için beklenen konumları belirtebilirsiniz. Örneğin, bir yetkilendirme kodunu işlerken yetkilendirme kodunun konumunu, istemci kimliğini, yönlendirme URI'sini ve kapsamı belirtebilirsiniz. Bunlar HTTP üst bilgileri, sorgu parametreleri veya form parametreleri olarak belirtilebilir.

Aşağıdaki örnekte, gerekli yetkilendirme kodu parametrelerinin yerini HTTP üstbilgileri olarak nasıl belirtebileceğiniz gösterilmektedir:

  ...
  <GrantType>request.header.grant_type</GrantType>
  <Code>request.header.code</Code>
  <ClientId>request.header.client_id</ClientId>
  <RedirectUri>request.header.redirect_uri</RedirectUri>
  <Scope>request.header.scope</Scope>
  ...

Alternatif olarak, müşterinizin uygulama tabanını desteklemek için gerekirse başlıklarla sorgu parametrelerini birlikte kullanabilirsiniz:

  ...
  <GrantType>request.header.grant_type</GrantType>
  <Code>request.header.code</Code>
  <ClientId>request.queryparam.client_id</ClientId>
  <RedirectUri>request.queryparam.redirect_uri</RedirectUri>
  <Scope>request.queryparam.scope</Scope>
  ...

Parametre başına yalnızca bir konum yapılandırılabilir.

Akış değişkenleri

Bu tabloda tanımlanan akış değişkenleri, ilgili OAuth politikaları yürütüldüğünde doldurulur ve bu nedenle API proxy akışında yürütülen diğer politikalar veya uygulamalar tarafından kullanılabilir.

VerifyAccessToken işlemi

VerifyAccessToken işlemi yürütülür ve proxy'nin yürütme bağlamında çok sayıda akış değişkeni doldurulur. Bu değişkenler, erişim jetonu, geliştirici uygulaması, geliştirici ve şirketle ilgili özellikleri sağlar. Örneğin, bu değişkenlerden herhangi birini okumak ve daha sonra akışta gerektiği gibi kullanmak için bir AssignMessage veya JavaScript politikası kullanabilirsiniz. Bu değişkenler, hata ayıklama amacıyla da faydalı olabilir.

Jetona özgü değişkenler

Uygulamaya özel değişkenler

Bu değişkenler, jetonla ilişkilendirilmiş Geliştirici Uygulaması ile ilgilidir.

Geliştiriciye özgü değişkenler

app.appType "Company" ise şirket özellikleri doldurulur ve app.appType "Developer" ise geliştirici özellikleri doldurulur.

Şirkete özgü değişkenler

app.appType "Company" ise şirket özellikleri doldurulur. app.appType ise "Developer" ise geliştirici özellikleri doldurulur.

GenerateAuthorizationCode işlemi

GenerateAuthorizationCode işlemi başarıyla yürütüldüğünde aşağıdaki değişkenler ayarlanır:

Ön ek: oauthv2authcode.{policy_name}.{variable_name}

Örnek: oauthv2authcode.GenerateCodePolicy.code

GenerateAccessToken ve RefreshAccessToken işlemleri

Bu değişkenler, GenerateAccessToken ve RefreshAccessToken işlemleri başarıyla yürütüldüğünde ayarlanır. Yenileme jetonu değişkenlerinin, istemci kimlik bilgileri izin türü akışı için geçerli olmadığını unutmayın.

Ön ek: oauthv2accesstoken.{policy_name}.{variable_name}

Örnek: oauthv2accesstoken.GenerateTokenPolicy.access_token

GenerateAccessTokenImplicitGrant

Bu değişkenler, örtülü izin türü akışı için GenerateAccessTokenImplicit işlemi başarıyla yürütüldüğünde ayarlanır.

Ön ek: oauthv2accesstoken.{policy_name}.{variable_name}

Örnek: oauthv2accesstoken.RefreshTokenPolicy.access_token

Hata referansı

Bu bölümde, bu politika bir hatayı tetiklediğinde döndürülen hata kodları ve hata mesajlarının yanı sıra Edge tarafından ayarlanan hata değişkenleri açıklanmaktadır. Hata kuralları geliştirirken bu bilgilerin farkında olmanız önemlidir. hoşuma gitmesi için bir fırsattır. Daha fazla bilgi için Bilmeniz gerekenler Politika hataları ve Kullanım sorun.

Çalışma zamanı hataları

Bu hatalar, politika yürütüldüğünde ortaya çıkabilir.

Dağıtım hataları

Bu politikayı içeren bir proxy dağıttığınızda bu hatalar oluşabilir.

Hata değişkenleri

Bu değişkenler, politika çalışma zamanında bir hatayı tetiklediğinde ayarlanır.

Örnek hata yanıtı

<GenerateResponse>, bu yanıtları istemciye geri gönderir. öğesi true olarak ayarlanır.

<GenerateResponse> değeri true ise politika hata döndürür jeton ve kod oluşturan işlemler için bu biçimde sunulur. Tam liste için bkz. OAuth HTTP hatası yanıt referansı.

{"ErrorCode" : "invalid_client", "Error" :"ClientId is Invalid"}

<GenerateResponse> değeri true ise politika hata döndürür kullanabilirsiniz. Tam liste için bkz. OAuth HTTP hatası yanıt referansı.

{  
   {  
      "fault":{  
         "faultstring":"Invalid Access Token",
         "detail":{  
            "errorcode":"keymanagement.service.invalid_access_token"
         }
      }
   }

Örnek hata kuralı

<FaultRule name=OAuthV2 Faults">
    <Step>
        <Name>AM-InvalidClientResponse</Name>
        <Condition>(fault.name = "invalid_client") OR (fault.name = "InvalidClientIdentifier")</Condition>
    </Step>
    <Step>
        <Name>AM-InvalidTokenResponse</Name>
        <Condition>(fault.name = "invalid_access_token")</Condition>
    </Step>
    <Condition>(oauthV2.failed = true) </Condition>
</FaultRule>

Politika şeması

Her politika türü bir XML şemasıyla (.xsd) tanımlanır. Referans olarak kullanabileceğiniz politika şemalarını GitHub'da bulabilirsiniz.

Varsayılan OAuth yapılandırmasıyla çalışma

Apigee Edge'deki her kuruluş (ücretsiz deneme kuruluşları dahil) bir OAuth jetonu uç noktasıyla temel hazırlığa sahiptir. Uç nokta, API proxy'sindeki oauth adlı politikalarla önceden yapılandırılmıştır. Apigee Edge'de bir hesap oluşturur oluşturmaz jeton uç noktasını kullanmaya başlayabilirsiniz. Ayrıntılı bilgi için OAuth uç noktalarını anlama başlıklı makaleyi inceleyin.

Erişim jetonlarını temizleme

Varsayılan olarak OAuth2 jetonları, hem erişim jetonunun hem de yenileme jetonunun (varsa) süresi dolduktan 3 gün (259.200 saniye) sonra Apigee Edge sisteminden temizlenir. Bazı durumlarda bu varsayılan ayarı değiştirmek isteyebilirsiniz. Örneğin, çok sayıda jeton oluşturuluyorsa disk alanından tasarruf etmek için tamamen silme süresini kısaltmak isteyebilirsiniz.

Edge for Private Cloud kullanıyorsanız bu varsayılan ayarı, bu bölümde açıklandığı şekilde kuruluş özelliklerini ayarlayarak değiştirebilirsiniz. (Süresi dolan jetonların 3 gün içinde tamamen silinmesi, Edge for Private Cloud'un 4.19.01 ve sonraki sürümleri için geçerlidir. Önceki sürümlerde varsayılan temizleme aralığı 180 gündür.)

Edge Private Cloud 4.16.01 ve sonraki sürümler için temizleme ayarlarını güncelleme

Not: Bu ayarların uygulanmasından sonra oluşturulan jetonlar etkilenir. Ayarlar, daha önce oluşturulan jetonlar için geçerli değildir.

Edge Private Cloud 4.15.07 için temizleme ayarlarını güncelleme

Not: Bu ayarlar yalnızca bu ayarların uygulanmasından sonra oluşturulan jetonları etkiler. Ayarlar, daha önce oluşturulan jetonlar için geçerli değildir.

RFC'ye uygun olmayan davranış

OAuthV2 politikası, RFC uyumlu olmayan belirli özellikleri içeren bir jeton yanıtı döndürüyor. Aşağıdaki tabloda OAuthV2 politikası tarafından döndürülen uyumlu olmayan özellikler ve ilgili uyumlu özellikler gösterilmektedir.

Ayrıca, grant_type = refresh_token olduğunda süresi dolmuş yenileme jetonu için hata yanıtı:

{"ErrorCode" : "invalid_request", "Error" :"Refresh Token expired"}

Ancak RFC'ye uygun yanıt şudur:

{"error" : "invalid_grant", "error_description" :"refresh token expired"}

İlgili konular

• OAuth 2.0'a giriş