OAuthV2 politikası

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

Ne

OAuthV2, OAuth 2.0 izin türü işlemlerinin gerçekleştirilmesine yönelik çok yönlü bir politikadır. Bu politika, 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 için OAuth ana sayfasına göz atın. Kaynakların, örneklerin, videoların ve daha fazlasının bağlantılarını içerir. Bu politikanın çalışan bir uygulamada nasıl kullanıldığına dair iyi bir örnek görmek için GitHub'daki gelişmiş OAuth örneğine göz atı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)));

"Temel kimlik doğrulama kimlik bilgilerini kodlama" bölümünü de inceleyin.

Öğe referansı

Politika referansında, OAuthV2 politikasının öğeleri ve özellikleri açıklanmaktadı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:

<DisplayName> öğesi

Politikayı, yönetim kullanıcı arayüzü proxy düzenleyicisinde farklı bir doğal dil adıyla etiketlemek için name özelliğine ek olarak kullanın.

<DisplayName>Policy Display Name</DisplayName>

<AccessToken> öğesi

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

VerificationAccessToken, varsayılan olarak erişim jetonunun Authorization üst bilgisinde gönderilmesini bekler. Bu varsayılanı bu öğ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>

ValidAccessToken, varsayılan olarak erişim jetonunun bir Yetkilendirme üst bilgisi içinde hamiline ait jeton olarak gönderilmesini bekler. Örneğin:

-H "Authorization: Bearer Rft3dqrs56Blirls56a"

Şu anda desteklenen tek ön ek hamiline aittir.

<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 araması gerektiğini belirtmenizi sağlar. Örneğin, bir sorgu parametresi olarak veya bir HTTP üst bilgisi olarak gönderilebilir.

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

Bu ayarın sağlanması, erişim jetonuna uygulama son kullanıcı kimliğini eklemenize olanak tanır. Bu özellik, OAuth 2.0 erişim jetonlarını son kullanıcı kimliğine göre almak veya iptal edebilmek istediğinizde faydalıdır. Daha fazla bilgi için Son kullanıcı kimliği, uygulama kimliği veya her ikisine göre OAuth 2.0 erişim jetonlarının 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>

Bir 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şkenindeki veya değişmez dizedeki bir değeri belirtebilmenizi sağlar. Hem değişken hem de dize belirtirseniz akış değişkeninde belirtilen değer kullanılır. Değişken çözümlenemezse varsayılan olarak dize kullanılır.

Bu öğenin kullanımı hakkında daha fazla bilgi için Jetonları ve Yetkilendirme Kodlarını Özelleştirme bölümüne bakın.

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

Bu politikanın GenerateResponse öğesini true olarak ayarlarsanız ayarladığınız özel özellikler de dahil olmak üzere jetonun tam JSON gösteriminin yanıtta döndürüleceğini unutmayın. Bazı durumlarda, istemci uygulamalarının görmesini önlemek için özel özelliklerinizin bazılarını veya tümünü yanıtta 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ği değeri korunmaz. Oluşturulan yanıtta gizlemek istediğiniz özel özelliklere sahip bir erişim jetonu oluşturduğunuzu varsayalım. display=false ayarlandığında, bu hedefe ulaşılır. 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, 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 yalnızca 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 beklediğiniz 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 görüntülenmelerini "false" (yanlış) değerine 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 çıkarmak için işleme sonrası JavaScript politikası kullanın.

Jetonları ve Yetkilendirme Kodlarını Özelleştirme konusuna da bakın.

<ClientId> öğesi

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

Bazı durumlarda istemci uygulamasının, istemci kimliğini yetkilendirme sunucusuna göndermesi gerekir. Bu öğe, Edge'in istemci kimliğini nerede araması gerektiğini belirtmenizi sağlar. Ayarlayabileceğiniz tek geçerli konum, varsayılan konum olan request.formparam.client_id akış değişkenidir. ClientId değişkeninin başka bir değişkene ayarlanması desteklenmez. Erişim jetonları ve yetkilendirme kodları isteme bölümünü de inceleyin.

<Code> öğesi

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

Yetkilendirme izni 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 belirlemenizi sağlar. Örneğin, sorgu parametresi, HTTP üst bilgisi veya form parametresi (varsayılan) olarak gönderilebilir.

request.queryparam.auth_code değişkeni, yetkilendirme kodunun bir sorgu parametresi olarak (örneğin, ?auth_code=AfGlvs9) olması gerektiğini belirtir. Örneğin, bir HTTP üst bilgisinde yetkilendirme kodunu zorunlu kılmak için bu değeri request.header.auth_code olarak ayarlayın. Erişim jetonları ve yetkilendirme kodları isteme bölümünü de inceleyin.

<expirationIn> öğesi

<ExpiresIn>10000</ExpiresIn> 

Erişim jetonlarının ve yetkilendirme kodlarının süre sonunu milisaniye cinsinden zorunlu kılar. (Yenileme jetonları için <RefreshTokenExpiresIn> kullanın.) Geçerlilik süresi değeri, sistem tarafından oluşturulan bir değere ek olarak <ExpiresIn> değeridir. <ExpiresIn>, -1 olarak ayarlanırsa jetonun veya kodun süresi maksimum OAuth erişim jetonunun sona ermesine göre dolar. <ExpiresIn> belirtilmezse sistem, sistem düzeyinde yapılandırılmış varsayılan bir değeri uygular.

Geçerlilik süresi, çalışma zamanında sabit kodlanmış bir varsayılan değer kullanılarak veya bir akış değişkenine referans vererek de ayarlanabilir. Örneğin, anahtar/değer eşlemesinde jeton geçerlilik bitiş değerini depolayabilir, jetonu alabilir, bir değişkene atayabilir ve politikada bu değere referans verebilirsiniz. Örneğin, kvm.oauth.expires_in.

Herkese Açık Bulut İçin Apigee Edge sayesinde Edge, varlıklara erişildikten sonra aşağıdaki varlıkları en az 180 saniye boyunca önbellekte tutar.

• OAuth erişim jetonları. Bu, iptal edilen bir jetonun önbellek sınırının süresi dolana kadar üç dakika kadar daha 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ındaki özel özellikler.

Aşağıdaki dize, bir akış değişkeni ve varsayılan değer 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 bir jetonun süresinin dolmasının zorunlu kılınacağı bir yöntem desteklemez. Jetonun geçerlilik süresinin sona ermesini zorunlu kılmanız gerekiyorsa (örneğin, bir koşul doğrultusunda) olası bir çözüm bu Apigee Topluluk gönderisinde açıklanmıştır.

Varsayılan olarak, süresi dolmuş erişim jetonları geçerlilik süresi dolduktan 3 gün sonra otomatik olarak Apigee Edge sisteminden silinir. Erişim jetonlarını kalıcı olarak silme konusuna da bakın

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

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

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

2. Mülkü istediğiniz gibi ayarlayın:

   conf_keymanagement_oauth_auth_code_expiry_time_in_millis=3600000

3. Özellikler dosyasının "Apigee" kullanıcısına ait olduğundan emin olun:

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

4. Message Processor'ı 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ı bildirir.

request.queryparam.external_access_token değişkeni, harici erişim jetonunun bir sorgu parametresi olarak (örneğin, ?external_access_token=12345678) olması 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 başlıklı makaleyi de inceleyin.

<ExternalAuthorization> öğesi

<ExternalAuthorization>true</ExternalAuthorization>

Bu öğe false (yanlış) değerine ayarlanırsa veya mevcut değilse Edge, client_id ve client_secret değerlerini normalde Apigee Edge yetkilendirme deposuna göre doğrular. Üçüncü taraf OAuth jetonlarıyla çalışmak istediğinizde bu öğeyi kullanın. Bu öğenin kullanımıyla ilgili ayrıntılar için Üçüncü Taraf OAuth Jetonlarını Kullanma bölümüne bakın.

<ExternalAuthorizationCode> öğesi

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

Apigee Edge'e harici kimlik doğrulama kodunun (Apigee Edge tarafından oluşturulmayan kimlik doğrulama kodu) nerede bulunacağını bildirir.

request.queryparam.external_auth_code değişkeni, harici yetkilendirme kodunun bir sorgu parametresi olarak (örneğin, ?external_auth_code=12345678) olması gerektiğini belirtir. Örneğin, bir HTTP üst bilgisinde 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 başlıklı makaleyi de inceleyin.

<ExternalYenileToken> öğesi

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

Apigee Edge'e harici 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) olması 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 değerine ayarlanırsa politika bir yanıt oluşturur ve döndürür. Örneğin, GenerateAccessToken için yanıt şöyle 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 dizi akış değişkeni 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 olarak ifade edildiğini unutmayın.

<GenerateErrorResponse> öğesi

<GenerateErrorResponse enabled='true'/>

true değerine ayarlanırsa ContinueOnError özelliği doğru değerine ayarlanırsa politika bir yanıt oluşturur ve döndürür. false ise (varsayılan) 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, bir istekte iletilen izin türü parametresinin nerede bulunacağını bildirir. OAuth 2.0 spesifikasyonu uyarınca, 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, Şifre'nin bir sorgu parametresi olarak mevcut olması gerektiğini belirtir (örneğin, ?grant_type=password). Örneğin, bir HTTP başlığında izin türünü zorunlu kılmak için bu değeri request.header.grant_type olarak ayarlayın. Erişim jetonları ve yetkilendirme kodları isteme bölümünü de inceleyin.

<İşlem> öğ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ü ile kullanılır. Şifre erişim türü, kullanıcı kimlik bilgilerinin (şifre ve kullanıcı adı) OAuthV2 politikası için kullanılabilir hale getirilmesi 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, sorgu parametresi kullanarak bir jeton isteği içinde şifreyi iletebilir ve öğeyi şu şekilde ayarlayabilirsiniz: <PassWord>request.queryparam.password</PassWord>. Bir HTTP üst bilgisinde şifre kullanımını zorunlu kılmak için bu değeri request.header.password olarak ayarlayın.

OAuthV2 politikası, bu kimlik bilgisi değerleriyle başka bir şey yapmaz. Edge yalnızca mevcut değerleri doğrular. Jeton oluşturma politikası uygulanmadan önce değerler isteğinin alınması ve bir kimlik sağlayıcıya gönderilmesi API geliştiricisinin sorumluluğundadır.

Erişim jetonları ve yetkilendirme kodları isteme bölümünü de inceleyin.

<RedirectUri> öğesi

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

Edge'in istekte redirect_uri parametresini nerede araması gerektiğini 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 kodunun (yetkilendirme kodu izin türü için) veya erişim jetonunun (örtülü izin türü için) gönderileceği yeri bildirir. Bu parametrenin ne zaman gerekli olduğunu, ne zaman isteğe bağlı olduğunu ve nasıl kullanıldığını anlamak önemlidir:

• (gerekli) İsteğin istemci anahtarlarıyla ilişkili geliştirici uygulamasında bir Geri Çağırma URL'si kayıtlıysa ve istekte redirect_uri mevcutsa ikisi tam olarak eşleşmelidir. Eşleşmezlerse bir hata döndürülür. Edge'de geliştirici uygulamalarını kaydetme ve Geri Çağırma URL'si belirtme hakkında bilgi için Uygulamaları kaydetme ve API anahtarlarını yönetme konusuna bakın.

• (İsteğe bağlı) Bir Geri Çağırma URL'si kayıtlıysa ve redirect_uri istekte bulunmuyorsa Edge, kayıtlı Geri Çağırma URL'sine yönlendirme yapar.
• (gerekli) Bir Geri Çağırma URL'si kayıtlı değilse redirect_uri gereklidir. Bu durumda, Edge'in HERHANGİ BİR URL'yi kabul edeceğini unutmayın. Bu durum güvenlik sorunu oluşturabilir, ve bu nedenle yalnızca güvenilir istemci uygulamalarıyla kullanılmalıdır. İstemci uygulamaları güvenilir değilse en iyi uygulama her zaman bir Geri Arama 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'nin bir sorgu parametresi olarak (örneğin, ?redirect_uri=login.myapp.com) olması gerektiğini belirtir. Örneğin, bir HTTP üst bilgisinde RedirectUri'yi zorunlu kılmak için bu değeri request.header.redirect_uri olarak ayarlayın. Erişim jetonları ve yetkilendirme kodları isteme bölümünü de inceleyin.

<YenileToken> öğesi

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

Yenileme jetonu kullanarak erişim jetonu isterken istekte yenileme jetonunu sağlamanız gerekir. Bu öğe, Edge'in yenileme jetonunu nerede araması gerektiğini belirlemenizi sağlar. Ö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) olması gerektiğini belirtir. Örneğin, HTTP başlığında YenileToken özelliğini zorunlu kılmak için bu değeri request.header.refresh_token olarak ayarlayın. Erişim jetonları ve yetkilendirme kodları isteme bölümünü de inceleyin.

<YenileTokenExpirationIn> öğesi

<RefreshTokenExpiresIn>1000</RefreshTokenExpiresIn>

Yenileme jetonlarının süre sonunu milisaniye cinsinden zorunlu kılar. Geçerlilik süresi değeri, sistem tarafından oluşturulan değer ile <RefreshTokenExpiresIn> değeridir. <RefreshTokenExpiresIn>, -1 olarak ayarlanırsa yenileme jetonunun süresi, maksimum OAuth yenileme jetonunun sona ermesinden sonra sona erer. <RefreshTokenExpiresIn> belirtilmezse varsayılan olarak süre sonu süresiz olur.

Geçerlilik süresi, çalışma zamanında sabit kodlanmış bir varsayılan değer kullanılarak veya bir akış değişkenine referans vererek de ayarlanabilir. Örneğin, anahtar/değer eşlemesinde jeton geçerlilik bitiş değerini depolayabilir, jetonu alabilir, bir değişkene atayabilir ve politikada bu değere referans verebilirsiniz. Örneğin, kvm.oauth.expires_in.

Aşağıdaki dize, bir akış değişkeni ve varsayılan değer 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 kurulumunda varsayılan değer conf_keymanagement_oauth_refresh_token_expiry_time_in_millis özelliği tarafından belirlenir. Bu özelliği ayarlamak için:

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

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

2. Mülkü istediğiniz gibi ayarlayın:

   conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000

3. Özellikler dosyasının "Apigee" kullanıcısına ait olduğundan emin olun:

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

4. Message Processor'ı 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 dolaylı izin türü akışlarla kullanılır.

Varsayılan olarak Edge, response_type sorgu parametresinde yanıt türü değerini arar. Bu varsayılan davranışı geçersiz kılmak isterseniz 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. Erişim jetonları ve yetkilendirme kodları isteme bölümünü 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 bulunuyorsa jetonu veya kodu verecek kapsamları belirtmek için kullanılır. Bu değerler genellikle bir istemci uygulamasından yapılan istekte politikaya iletilir. Öğeyi bir akış değişkeni alacak şekilde yapılandırabilirsiniz. Bu sayede kapsamların istekte nasıl iletileceğini seçebilirsiniz. Aşağıdaki örnekte request.queryparam.scope, kapsamın bir sorgu parametresi olarak (örneğin, ?scope=READ) olması gerektiğini belirtir. Örneğin, bir HTTP başlığında kapsamı zorunlu kılmak için bu değeri request.header.scope olarak ayarlayın.

Bu öğe bir "VerifyAccessToken" politikasında görünüyorsa politikanın hangi kapsamları uygulaması gerektiğini belirtmek için kullanılır. Bu politika türünde, değerin "sabit kodlu" bir kapsam adı olması gerekir. Değişkenler kullanamazsınız. Örneğin:

<Scope>A B</Scope>

Ayrıca, OAuth2 kapsamlarıyla çalışma ve Erişim jetonları ve yetkilendirme kodları isteme bölümlerine de göz atın.

<State> öğesi

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

İstemci uygulamasının durum bilgilerini yetkilendirme sunucusuna göndermesi gerektiğinde bu öğe, Edge'in durum değerlerini nerede araması gerektiğini belirtmenizi sağlar. Örneğin, bir sorgu parametresi olarak veya bir HTTP üst bilgisi 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 bir sorgu parametresi olarak mevcut olması gerektiğini belirtir (örneğin, ?state=HjoiuKJH32). Örneğin, bir HTTP üst bilgisinde durumu zorunlu kılmak için bu değeri request.header.state olarak ayarlayın. Erişim jetonları ve yetkilendirme kodları isteme bölümünü 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ı bildirir. Aksi takdirde ayarlanmaz.

<SupportedGrantTypes>/<GrantType> öğesi

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

Apigee Edge'de OAuth jetonu uç noktasının desteklediği 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ğıtmak üzere yapılandırılabilir. Uç noktalar hakkında daha fazla bilgi için OAuth uç noktalarını anlama başlıklı makaleyi inceleyin. İzin türü, jeton isteklerinde bir grant_type parametresinde iletilir.

Desteklenen bir izin türü belirtilmemişse yalnızca authorization_code ve implicit izin türleri kullanılabilir. <GrantType> öğesine de bakın (bu üst düzey öğe, Apigee Edge'in istemci isteğinde geçirilen grant_type parametresini nasıl araması gerektiğini belirtmek için kullanılır.) Edge, grant_type parametre değerinin desteklenen izin türlerinden biriyle eşleştiğinden emin olur).

<Tokens>/<Token> öğesi

ValidateToken ve InValidateToken işlemleriyle birlikte kullanılır. Erişim jetonlarını onaylama ve iptal etme konusuna da bakın. <Token> öğesi, iptal edilecek jetonun kaynağını tanımlayan akış değişkenini tanımlar. Örneğin, geliştiricilerin erişim jetonlarını access_token adlı sorgu parametreleri olarak göndermeleri bekleniyorsa request.queryparam.access_token parametresini kullanın.

<UserName> öğesi

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

Bu öğe, yalnızca şifre izin türü ile kullanılır. Şifre erişim türü, kullanıcı kimlik bilgilerinin (şifre ve kullanıcı adı) OAuthV2 politikası için kullanılabilir hale getirilmesi 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 HTTP başlığında zorunlu kılınması için bu değeri request.header.username olarak ayarlayın.

OAuthV2 politikası, bu kimlik bilgisi değerleriyle başka bir şey yapmaz. Edge yalnızca mevcut değerleri doğrular. Jeton oluşturma politikası uygulanmadan önce değerler isteğinin alınması ve bir kimlik sağlayıcıya gönderilmesi API geliştiricisinin sorumluluğundadır.

Erişim jetonları ve yetkilendirme kodları isteme bölümünü de inceleyin.

Erişim jetonlarını doğrulama

API proxy'si için jeton uç noktası oluşturulduktan sonra, korunan kaynağı gösteren Akışa VerifyAccessToken işlemini belirten ilgili bir OAuthV2 politikası 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 eklenmiş. Bir API'ye yapılan tüm isteklerin doğrulandığından emin olmak için politikayı aşağıdaki şekilde ProxyEndpoint isteği PreFlow'a ekleyin:

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

Aşağıdaki isteğe bağlı öğeler, VerificationAccessToken işleminin varsayılan ayarlarını geçersiz kılmak için 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 bölümlerine de göz atın.

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

Politika, her bir izin türü için konum veya istek mesajlarında gerekli bilgiler hakkında varsayımlarda bulunur. Bu varsayımlar OAuth 2.0 spesifikasyonunu temel almaktadı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 konumunu HTTP üst bilgileri 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>
  ...

Müşteri uygulama tabanınızı 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 çalışan diğer politikalar veya uygulamalar tarafından kullanılabilir.

DoğrulamaErişim Jetonu işlemi

VerificationAccessToken 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 size erişim jetonu, geliştirici uygulaması, geliştirici ve şirket ile ilgili özellikler sunar. Örneğin, bu değişkenlerden herhangi birini okumak ve akışın sonraki aşamalarında gerekli olduğunda kullanmak için bir AtaticMessage veya JavaScript politikası kullanabilirsiniz. Bu değişkenler, hata ayıklama amacıyla da yararlı olabilir.

Jetona özel değişkenler

Uygulamaya özel değişkenler

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

Geliştiriciye özel değişkenler

app.appType için "Şirket" değeri belirlenirse şirket özellikleri doldurulur. app.appType değeri "Geliştirici" ise geliştirici özellikleri doldurulur.

Şirkete özel değişkenler

app.appType için "Şirket" değeri belirlenirse şirket özellikleri doldurulur. app.appType değeri "Geliştirici" 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:

Önek: 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.

Önek: 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.

Önek: oauthv2accesstoken.{policy_name}.{variable_name}

Örnek: oauthv2accesstoken.RefreshTokenPolicy.access_token

Hata referansı

Bu bölümde, bu politika bir hatayı tetiklediğinde Edge tarafından ayarlanan hata kodları ile hata mesajları ve döndürülen hata mesajları ile Edge tarafından ayarlanan hata değişkenleri açıklanmaktadır. Bu bilgiyi, hataları ele almak için hata kuralları geliştirip geliştirmediğinizi bilmeniz önemlidir. Daha fazla bilgi için Politika hataları hakkında bilmeniz gerekenler ve Hataları işleme bölümlerine bakın.

Çalışma zamanı hataları

Politika yürütüldüğünde bu hatalar 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> değeri true (doğru) değerine ayarlanırsa jeton ve kod oluşturan işlemler için politika bu biçimde hatalar döndürür. Tam liste için OAuth HTTP hatası yanıtı referansı bölümüne bakın.

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

<GenerateResponse> değeri true (doğru) değerine ayarlanırsa politika, doğrulama ve doğrulama işlemleri için bu biçimde hatalar döndürür. Tam liste için OAuth HTTP hatası yanıtı referansı başlıklı makaleye bakın.

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

Hata kuralı örneği

<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 olması için GitHub'da politika şemaları mevcuttur.

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

Apigee Edge'deki her kuruluş (ücretsiz deneme sürümü kuruluşu bile) bir OAuth jeton uç noktası ile sağlanır. Uç nokta, API proxy'sindeki oauth adı verilen 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ılar için OAuth uç noktalarını anlama başlıklı makaleyi inceleyin.

Erişim jetonlarını kalıcı olarak silme

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 kalıcı olarak silinir. Bazı durumlarda bu varsayılan değeri 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.

Private Cloud için Edge kullanıyorsanız kuruluş özelliklerini bu bölümde açıklandığı şekilde ayarlayarak bu varsayılan değeri değiştirebilirsiniz. (Süresi dolan jetonların 3 gün boyunca kalıcı olarak silinmesi, Private Cloud için Edge 4.19.01 ve sonraki sürümlerinde geçerli olur. Önceki sürümler için varsayılan kalıcı olarak silme aralığı 180 gündür.)

Edge Private Cloud 4.16.01 ve sonraki sürümleri için tamamen silme 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 olmaz.

Edge Private Cloud 4.15.07 için tamamen silme ayarları güncelleniyor

Not: Yalnızca bu ayarlar uygulandıktan sonra oluşturulan jetonlar etkilenir. Ayarlar, daha önce oluşturulan jetonlar için geçerli olmaz.

RFC ile uyumlu olmayan davranış

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

Ayrıca, grant_type = refresh_token aşağıdaki durumlarda süresi dolmuş bir yenileme jetonu için verilen hata yanıtıdır:

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

Ancak RFC uyumlu yanıt:

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

İlgili konular

• OAuth 2.0'a giriş