OAuthV2 politikası

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

Ne?

OAuthV2, OAuth 2.0 erişim izni türü işlemlerini gerçekleştirmek için kullanılan ç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ını inceleyin. Kaynaklara, örneklere, videolara ve daha fazlasına bağlantılar sağlar. Bu politikanın çalışan bir uygulamada nasıl kullanıldığını iyi bir şekilde gösteren GitHub'daki gelişmiş OAuth örneğini inceleyin.

Ö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 "Temel kimlik doğrulama kimlik bilgilerini kodlama" bölümüne bakın.

Öğe referansı

Politika referansı, OAuthV2 politikasının öğelerini ve özelliklerini açıklar.

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. Gerekli 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>

VerifyAccessToken, varsayılan olarak erişim jetonunun Authorization üstbilgisinde gönderilmesini bekler. Bu öğeyi kullanarak varsayılanı değiştirebilirsiniz. Örneğin, request.queryparam.access_token, erişim jetonunun access_token adlı bir sorgu parametresi olarak bulunması 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 taşıyıcı jeton olarak Yetkilendirme üstbilgisinde gönderilmesini bekler. Örneğin:

-H "Authorization: Bearer Rft3dqrs56Blirls56a"

Şu anda yalnızca Bearer öneki desteklenmektedir.

<AppEndUser> öğesi

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

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

Örneğin request.queryparam.app_enduser, AppEndUser'ın sorgu parametresi olarak bulunması gerektiğini belirtir (ör. ?app_enduser=ntesla@theramin.com). Örneğin, bir HTTP üstbilgisinde AppEndUser'ın zorunlu olmasını sağlamak için bu değeri request.header.app_enduser olarak ayarlayın.

Bu ayarı sağladığınızda erişim jetonuna bir uygulama son kullanıcı kimliği ekleyebilirsiniz. Bu özellik, OAuth 2.0 erişim jetonlarını son kullanıcı kimliğine göre alabilmek veya iptal edebilmek istediğinizde 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.

<Attributes/Attribute>

<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, çalışma zamanında çıkarılıp kontrol edilebilen bir erişim jetonuna kullanıcı kimliği veya oturum tanımlayıcısı yerleştirmek isteyebilirsiniz.

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

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

Yanıt içinde özel özellikleri gösterme veya gizleme

Bu politikanın GenerateResponse öğesini true olarak ayarlarsanız belirlediğiniz özel özellikler de dahil olmak üzere jetonun tam JSON gösteriminin yanıtta döndürüleceğini unutmayın. Bazı durumlarda, istemci uygulamalarına görünmemeleri için yanıtınızdaki özel özelliklerinizin bir kısmını veya tamamını gizlemek isteyebilirsiniz.

Varsayılan olarak, özel özellikler 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ı olarak saklanmıyor. Oluşturulan yanıtta gizlemek istediğiniz özel özelliklere sahip bir erişim jetonu oluşturduğunuzu varsayalım. display=false ayarı bu hedefi gerçekleştirir. Ancak 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 erişim jetonu oluşturma politikasında display özelliğinin 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 de aynı davranışla karşılaşırsınız. Bu kod kullanılarak bir erişim jetonu oluşturulduğunda, özel özellikler erişim jetonu yanıtında gösterilir. Bu, yine de amaçladığınız davranış olmayabilir.

Bu durumlarda özel özellikleri gizlemek için şu seçenekleri kullanabilirsiniz:

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

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

<ClientId> öğesi

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

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

<Code> öğesi

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

Yetkilendirme izni türü akışında istemci, yetkilendirme sunucusuna (Apigee Edge) bir yetkilendirme kodu göndermelidir. Bu öğe, Edge'in yetkilendirme kodunu nerede arayacağını 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 bulunması gerektiğini belirtir. Örneğin, ?auth_code=AfGlvs9. Örneğin, bir HTTP başlığında yetkilendirme kodunun zorunlu tutulması 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 süresini milisaniye cinsinden zorunlu kılar. (Yenileme jetonları için <RefreshTokenExpiresIn> değerini kullanın.) Geçerlilik bitiş saati değeri, sistem tarafından oluşturulan bir değerin yanı sıra <ExpiresIn> değeridir. <ExpiresIn>, -1 olarak ayarlanırsa jetonun veya kodun geçerlilik süresi, maksimum OAuth erişim jetonu geçerlilik süresine göre dolar. <ExpiresIn> belirtilmezse sistem, sistem düzeyinde yapılandırılmış bir varsayılan değer uygular.

Son kullanma süresi, çalışma zamanında sabit kodlanmış bir varsayılan değer kullanılarak veya bir akış değişkenine referans verilerek de ayarlanabilir. Örneğin, bir jeton geçerlilik bitimi değerini anahtar/değer çifti haritasında saklayabilir, alabilir, bir değişkene atayabilir ve politikada buna referans verebilirsiniz. Örneğin, kvm.oauth.expires_in.

Apigee Edge for Public Cloud ile Edge, erişildikten sonra en az 180 saniye boyunca aşağıdaki öğeleri önbellekte tutar.

• OAuth erişim jetonları. Bu, iptal edilen bir jetonun, önbellek sınırı sona erene kadar üç dakikaya kadar başarılı olabileceği anlamına gelir.
• Key Management Service (KMS) varlıkları (Uygulamalar, Geliştiriciler, API Ürünleri).
• OAuth jetonları ve KMS varlıklarındaki özel özellikler.

Aşağıdaki kıta, bir akış değişkenini ve varsayılan değeri de belirtir. 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ı zorlamayı desteklemez. Jetonun süresinin dolmasını zorlamanız gerekiyorsa (örneğin, bir koşula bağlı olarak) olası bir çözüm bu Apigee Topluluğu gönderisinde açıklanmıştır.

Varsayılan olarak, süresi dolmuş erişim jetonları, geçerlilik süresi dolduktan 3 gün sonra Apigee Edge sisteminden otomatik olarak temizlenir. Ayrıca Erişim jetonlarını temizleme başlıklı makaleyi de inceleyin.

Private Cloud: Private Cloud için Edge yüklemesinde varsayılan değer, conf_keymanagement_oauth_auth_code_expiry_time_in_millis özelliği tarafından ayarlanır. 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. Özelliği istediğiniz gibi ayarlayın:

   conf_keymanagement_oauth_auth_code_expiry_time_in_millis=3600000

3. Özellikler dosyasının sahibi "apigee" kullanıcısı olmalıdır:

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

4. Mesaj İşleyici'yi 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 bir erişim jetonunun (Apigee Edge tarafından oluşturulmayan bir erişim jetonu) nerede bulunacağını bildirir.

request.queryparam.external_access_token değişkeni, harici erişim jetonunun sorgu parametresi olarak bulunması gerektiğini gösterir. Örneğin, ?external_access_token=12345678. Harici erişim jetonunun bir HTTP üst bilgisinde zorunlu kılınması için örneğin bu değeri request.header.external_access_token olarak ayarlayın. Üçüncü Taraf OAuth Jetonlarını Kullanma başlıklı makaleyi de inceleyin.

<ExternalAuthorization> öğesi

<ExternalAuthorization>true</ExternalAuthorization>

Bu öğe yanlışsa veya mevcut değilse Edge, client_id ve client_secret'i 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 bir yetkilendirme kodunun (Apigee Edge tarafından oluşturulmayan bir yetkilendirme kodu) nerede bulunacağını bildirir.

request.queryparam.external_auth_code değişkeni, harici yetkilendirme kodunun sorgu parametresi olarak bulunması gerektiğini gösterir. Örneğin, ?external_auth_code=12345678. Harici kimlik doğrulama kodunun bir HTTP üstbilgisinde zorunlu olmasını sağlamak için örneğin bu değeri request.header.external_auth_code olarak ayarlayın. Üçüncü Taraf OAuth Jetonlarını Kullanma başlıklı makaleyi de inceleyin.

<ExternalRefreshToken> öğesi

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

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

request.queryparam.external_refresh_token değişkeni, harici yenileme jetonunun sorgu parametresi olarak bulunması gerektiğini gösterir. Örneğin, ?external_refresh_token=12345678. Harici yenileme jetonunun bir HTTP üstbilgisinde zorunlu kılınması için örneğ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şturup 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, politika işleviyle ilgili değerlerle bir dizi akış değişkeni doldurulur. Örneğin, oauthv2authcode.OAuthV2-GenerateAuthorizationCode.code adlı bir akış değişkeni, yeni oluşturulan yetkilendirme koduyla doldurulur. Yanıtın expires_in değerinin saniye cinsinden ifade edildiğini unutmayın.

<GenerateErrorResponse> öğesi

<GenerateErrorResponse enabled='true'/>

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

<GrantType>

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

Politikaya, istekte iletilen izin türü parametresinin nerede bulunacağını bildirir. OAuth 2.0 spesifikasyonuna göre, erişim jetonları ve yetkilendirme kodları için yapılan isteklerde izin türü sağlanmalıdır. Değişken bir üstbilgi, sorgu parametresi veya form parametresi (varsayılan) olabilir.

Örneğin request.queryparam.grant_type, şifrenin sorgu parametresi olarak bulunması gerektiğini belirtir (ör. ?grant_type=password). HTTP üstbilgisinde yetki türünün zorunlu olmasını sağlamak için örneğin bu değeri request.header.grant_type olarak ayarlayın. Ayrıca Erişim jetonları ve yetkilendirme kodları isteme başlıklı makaleyi de inceleyin.

<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 bilgilerinin (şifre ve kullanıcı adı) OAuthV2 politikasına sunulması gerekir. <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 hata verir. Kimlik bilgilerini içeren herhangi bir akış değişkenine referans vermek için <PassWord> ve <UserName> öğelerini kullanabilirsiniz.

Örneğin, şifreyi bir sorgu parametresi kullanarak jeton isteğinde iletebilir ve öğeyi şu şekilde ayarlayabilirsiniz: <PassWord>request.queryparam.password</PassWord>. Şifrenin HTTP üstbilgisinde zorunlu olması için 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. Jeton oluşturma politikası yürütülmeden önce değer isteğini alıp bir kimlik sağlayıcıya göndermek API geliştiricisinin sorumluluğundadı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, istekte redirect_uri parametresini nerede arayacağını belirtir.

Yönlendirme URI'leri hakkında

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

• (zorunlu) İstekle ilişkili geliştirici uygulamasına bir geri çağırma URL'si kaydedilmişse ve istekte redirect_uri varsa ikisi tam olarak eşleşmelidir. Eşleşmemeleri durumunda hata döndürülür. Edge'de geliştirici uygulamalarını kaydetme ve geri çağırma URL'si belirtme hakkında bilgi edinmek için Uygulamaları 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 eksikse Edge, kaydedilen geri çağırma URL'sine yönlendirir.
• (zorunlu) Geri arama URL'si kaydedilmemişse redirect_uri gereklidir. Bu durumda Edge'in HERHANGİ BİR URL'yi kabul edeceğini unutmayın. Bu durum güvenlik sorununa yol açabilir ve bu nedenle yalnızca güvenilir istemci uygulamalarıyla kullanılmalıdır. İstemci uygulamalarına güvenilmiyorsa en iyi uygulama, geri çağırma URL'sinin her zaman kaydedilmesini zorunlu kılmaktır.

Bu parametreyi bir sorgu parametresinde veya bir üstbilgide gönderebilirsiniz. request.queryparam.redirect_uri değişkeni, RedirectUri'nin ?redirect_uri=login.myapp.com gibi bir sorgu parametresi olarak bulunması gerektiğini gösterir. Örneğin, bir HTTP üstbilgisinde RedirectUri'nin zorunlu olmasını sağlamak için bu değeri request.header.redirect_uri olarak ayarlayın. Ayrıca 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 isterken isteğe yenileme jetonunu eklemeniz gerekir. Bu öğe, Edge'in yenileme jetonunu nerede arayacağını belirtmenize olanak tanır. Örneğin, sorgu parametresi, HTTP başlığı veya form parametresi (varsayılan) olarak gönderilebilir.

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

<RefreshTokenExpiresIn> öğesi

<RefreshTokenExpiresIn>1000</RefreshTokenExpiresIn>

Yenileme jetonlarının geçerlilik süresini milisaniye cinsinden zorunlu kılar. Geçerlilik bitiş saati değeri, sistem tarafından oluşturulan değer ile <RefreshTokenExpiresIn> değerinin toplamıdır. <RefreshTokenExpiresIn>, -1 olarak ayarlanırsa yenileme jetonunun süresi maksimum OAuth yenileme jetonu son kullanma tarihi'ne göre dolar. <RefreshTokenExpiresIn> belirtilmemişse sistem, sistem düzeyinde yapılandırılmış bir varsayılan değer uygular. Varsayılan sistem ayarları hakkında daha fazla bilgi için Apigee Edge Destek Ekibi ile iletişime geçin.

Son kullanma süresi, çalışma zamanında sabit kodlanmış bir varsayılan değer kullanılarak veya bir akış değişkenine referans verilerek de ayarlanabilir. Örneğin, bir jeton geçerlilik bitimi değerini anahtar/değer çifti haritasında saklayabilir, alabilir, bir değişkene atayabilir ve politikada buna referans verebilirsiniz. Örneğin, kvm.oauth.expires_in.

Aşağıdaki kıta, bir akış değişkenini ve varsayılan değeri de belirtir. 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 yüklemesinde varsayılan değer, conf_keymanagement_oauth_refresh_token_expiry_time_in_millis özelliği tarafından ayarlanır. 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. Özelliği istediğiniz gibi ayarlayın:

   conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000

3. Özellikler dosyasının sahibi "apigee" kullanıcısı olmalıdır:

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

4. Mesaj İşleyici'yi 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, istemci uygulamasının hangi izin türünü istediği konusunda Edge'i bilgilendirir. Yalnızca yetkilendirme kodu ve implicit izin türü akışlarıyla kullanılır.

Edge, varsayılan olarak response_type sorgu parametresinde yanıt türü değerini 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 gönderildiğinde 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 jetona ya da koda hangi kapsamların verileceğini belirtmek için kullanılır. Bu değerler genellikle bir istemci uygulamasından gelen istekte politikaya iletilir. Öğeyi bir akış değişkeni alacak şekilde yapılandırabilirsiniz. Böylece, kapsamların istekte nasıl iletileceğini seçebilirsiniz. Aşağıdaki örnekte request.queryparam.scope, kapsamın sorgu parametresi olarak bulunması gerektiğini gösterir (örneğin, ?scope=READ). Örneğin, bir HTTP üstbilgisinde kapsamın zorunlu olmasını sağlamak için bu değeri request.header.scope olarak ayarlayın.

Bu öğe bir "VerifyAccessToken" politikasında görünüyorsa politika tarafından hangi kapsamların zorunlu kılınacağını 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>

Ayrıca 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 gereken durumlarda bu öğe, Edge'in durum değerlerini nerede arayacağını belirtmenize olanak tanır. Örneğin, 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 sorgu parametresi olarak mevcut olması gerektiğini gösterir (örneğin, ?state=HjoiuKJH32). Bir HTTP başlığında eyaletin zorunlu olmasını sağlamak için örneğin bu değeri request.header.state olarak ayarlayın. Ayrıca Erişim jetonları ve yetkilendirme kodları isteme başlıklı makaleyi de inceleyin.

<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 depolamasını söyler. Aksi takdirde, bu veriler kalıcı olmaz.

<SupportedGrantTypes>/<GrantType> öğesi

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

Apigee Edge'deki bir OAuth jetonu 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ı makaleye bakın. İzin türü, jeton isteklerinde grant_type parametresinde iletilir.

Desteklenen hibe türleri belirtilmezse yalnızca authorization_code ve implicit hibe türlerine izin verilir. Ayrıca, Apigee Edge'in bir istemci isteğinde iletilen grant_type parametresini nerede arayacağını belirtmek için kullanılan daha üst düzey bir öğe olan <GrantType> öğesine de bakın. Edge, grant_type parametresinin değerinin desteklenen yetkilendirme türlerinden biriyle eşleşmesini sağlar.

<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 de inceleyin. <Token> öğesi, iptal edilecek jetonun kaynağını tanımlayan akış değişkenini belirler. Geliştiricilerin erişim jetonlarını access_token adlı sorgu parametreleri olarak göndermesi bekleniyorsa (ör. 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 bilgilerinin (şifre ve kullanıcı adı) OAuthV2 politikasına sunulması gerekir. <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 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>.Kullanıcı adının bir HTTP üstbilgisinde zorunlu olması 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 yalnızca bunların mevcut olduğunu doğrular. Jeton oluşturma politikası yürütülmeden önce değer isteğini alıp bir kimlik sağlayıcıya göndermek API geliştiricisinin sorumluluğundadır.

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ı ayarlandıktan sonra, VerifyAccessToken işlemini belirten ilgili bir OAuthV2 politikası, korunan kaynağı kullanıma sunan akışa eklenir.

Örneğin, bir API'ye yapılan tüm isteklerin yetkilendirilmesini sağlamak için aşağıdaki politika, erişim jetonu doğrulamayı 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 isteği PreFlow'a aşağıdaki şekilde ekleyin:

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

Aşağıdaki isteğe bağlı öğeler, VerifyAccessToken işlemi için varsayılan ayarları geçersiz kılmak üzere kullanılabilir.

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

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

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

Politika, her izin türü için istek mesajlarındaki konum veya gerekli bilgilerle ilgili varsayımlarda bulunur. Bu varsayımlar, OAuth 2.0 spesifikasyonuna dayanmaktadı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, istemci kimliğinin, yönlendirme URI'sinin ve kapsamın konumunu belirtebilirsiniz. Bunlar HTTP üstbilgileri, sorgu parametreleri veya form parametreleri olarak belirtilebilir.

Aşağıdaki örnekte, gerekli yetkilendirme kodu parametrelerinin konumunu 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, istemci uygulamanızın tabanını desteklemek için gerekirse başlıkları ve sorgu parametrelerini karıştırıp eşleştirebilirsiniz:

  ...
  <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 özellikler sağlar. Örneğin, bu değişkenlerden herhangi birini okumak ve akışta daha sonra gerektiği şekilde kullanmak için AssignMessage veya JavaScript politikası kullanabilirsiniz. Bu değişkenler hata ayıklama amacıyla da kullanılabilir.

Jetonla ilgili değişkenler

Uygulamaya özel değişkenler

Bu değişkenler, jetonla ilişkili geliştirici uygulamasıyla ilgilidir.

Geliştiriciye özel değişkenler

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

Şirkete özgü değişkenler

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

GenerateAuthorizationCode işlemi

Bu değişkenler, GenerateAuthorizationCode işlemi başarıyla yürütüldüğünde 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 bilgisi verme 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, döndürülen hata kodları ve hata mesajları ile bu politika bir hata tetiklediğinde Edge tarafından ayarlanan hata değişkenleri açıklanmaktadır. Hataları ele almak için hata kuralları geliştiriyorsanız bu bilgileri bilmeniz önemlidir. Daha fazla bilgi edinmek için Politika hataları hakkında bilmeniz gerekenler ve Hataları ele alma başlıklı makaleleri inceleyin.

Çalışma zamanı hataları

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

Dağıtım hataları

Bu hatalar, bu politikayı içeren bir proxy dağıttığınızda ortaya çıkabilir.

Hata değişkenleri

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

Örnek hata yanıtı

<GenerateResponse> öğesi true ise bu yanıtlar istemciye geri gönderilir.

<GenerateResponse> true ise politika, jeton ve kod oluşturan işlemler için bu biçimde hata döndürür. Tam liste için OAuth HTTP hata yanıtı referansı başlıklı makaleyi inceleyin.

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

<GenerateResponse> doğru ise politika, doğrulama ve doğrulama işlemleri için hataları bu biçimde döndürür. Tam liste için OAuth HTTP hata yanıtı referansı başlıklı makaleyi inceleyin.

{  
   {  
      "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ı (.xsd) ile tanımlanır. Referans olarak politika şemaları GitHub'da mevcuttur.

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

Apigee Edge'deki her kuruluş (ücretsiz deneme kuruluşu bile) bir OAuth jetonu uç noktasıyla sağlanır. Uç nokta, oauth adlı API proxy'sindeki politikalarla önceden yapılandırılmıştır. Apigee Edge'de 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, hem erişim jetonunun hem de yenileme jetonunun (varsa) süresi dolduktan 3 gün (259.200 saniye) sonra OAuth2 jetonları 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 temizleme süresini kısaltmak isteyebilirsiniz.

Edge for Private Cloud kullanıyorsanız bu bölümde açıklandığı gibi kuruluş özelliklerini ayarlayarak bu varsayılanı değiştirebilirsiniz. (Süresi dolmuş jetonların 3 gün içinde temizlenmesi, Edge for Private Cloud 4.19.01 ve sonraki sürümler için geçerlidir. (Daha ö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: Yalnızca bu ayarlar uygulandıktan 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: Yalnızca bu ayarlar uygulandıktan sonra oluşturulan jetonlar etkilenir. Ayarlar, daha önce oluşturulan jetonlar için geçerli değildir.

RFC'ye uygun olmayan davranış

OAuthV2 politikası, belirli RFC uyumlu olmayan özellikler 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 karşılık gelen uyumlu özellikler gösterilmektedir.

Ayrıca, grant_type = refresh_token olduğunda süresi dolmuş bir yenileme jetonunun hata yanıtı şöyledir:

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

Ancak RFC'ye uygun yanıt şöyledir:

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

İlgili konular

• OAuth 2.0'a giriş