Google, içerikleri tercih ettiğiniz dile çevirmek için yapay zeka teknolojisini kullanır. Yapay zeka çevirilerinde hata olabilir.

Üçüncü Taraf OAuth Jetonlarını Kullanma

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

Bu konuda, harici olarak oluşturulan erişim jetonlarının, yenileme jetonlarının veya kimlik doğrulama kodlarının Edge jeton deposuna nasıl aktarılacağı açıklanmaktadır. Apigee Edge dışında oluşturulan jetonları doğrulamak için Apigee Edge'i yapılandırmak istiyorsanız bu tekniği kullanabilirsiniz.

Normalde Apigee Edge, bir OAuth jetonu oluşturup depolar ve bunu çağıran uygulamaya döndürür. Ardından, hizmet isteğinde bulunurken çağıran uygulama bu jetonu Apigee Edge'e geri sunar ve Apigee Edge, Operation = VerifyAccessToken ile OAuthV2 politikası aracılığıyla jetonun geçerli olduğunu doğrular. Bu konuda, jeton doğrulama bölümünü aynı tutarak, jeton Edge tarafından oluşturulmuş gibi, başka bir yerde oluşturulan bir OAuth jetonunu saklamak için Apigee Edge'i nasıl yapılandırabileceğiniz açıklanmaktadır.

Örnek

Bu konuda açıklanan tekniği gösteren çalışan bir örnek görmek istiyorsanız Apigee Delegated Token Management örneğine göz atın.

Bu nedir?

Mevcut bir yetkilendirme sisteminiz olduğunu ve Edge'in oluşturduğu OAuth2 jetonu veya kodu değerleri yerine bu sistem tarafından oluşturulan jeton ya da kod değerlerini kullanmak istediğinizi varsayalım. Ardından, değiştirilen jeton veya kodla güvenli API proxy'si istekleri gönderebilirsiniz. Edge, bu istekleri Edge tarafından oluşturulmuş gibi doğrular.

Biraz Arka Plan Bilgisi

Normalde Apigee Edge, rastgele harf ve rakam dizisi oluşturarak jeton üretir. Apigee Edge, bu jetonla ilişkilendirilen diğer verileri (ör. jetonun düzenlenme zamanı, geçerlilik süresi, jetonun geçerli olduğu API ürünlerinin listesi ve kapsam) de saklar. Bu bilgilerin tümü, Operation = GenerateAccessToken ile yapılandırılmış OAuthV2 politikası tarafından otomatik olarak oluşturulan bir yanıtta döndürülebilir. Yanıt şu şekilde görünür:

{
  "issued_at": "1469735625687",
  "application_name": "06947a86-919e-4ca3-ac72-036723b18231",
  "scope": "urn://example.com/read",
  "status": "approved",
  "api_product_list": "[implicit-test]",
  "api_product_list_json": ["implicit-test"],
  "expires_in": "1799", //--in seconds
  "developer.email": "joe@weathersample.com",
  "token_type": "BearerToken",
  "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk",
  "access_token": "zBC90HhCGmGlaMBWeZAai2s3za5j",
  "organization_name": "wwitman",
  "refresh_token_expires_in": "0", //--in seconds
  "refresh_count": "0"
}

access_token özelliğinin değeri, yanıt verileri için arama anahtarıdır. Bir uygulama, Edge'de barındırılan bir API proxy'sine taşıyıcı jetonu zBC90HhCGmGlaMBWeZAai2s3za5j ile birlikte istekte bulunabilir. Edge, Operation = VerifyAccessToken ile OAuthV2 politikasıyla jetonu arar, tüm bilgileri alır ve bu bilgileri kullanarak istenen API proxy'si için jetonun geçerli olup olmadığını belirler. Buna Jeton doğrulaması adı verilir. Yukarıdaki bilgilerin tümü jetonu oluşturur. access_token değeri yalnızca bu bilgileri aramanın bir yoludur.

Diğer yandan, burada açıklanan adımları uygulayarak Edge'i bir jeton depolayacak şekilde yapılandırabilirsiniz. Böylece access_token değeri, harici bir hizmet tarafından oluşturulur. Diğer tüm meta veriler aynı olabilir. Örneğin, Apigee Edge'in dışında, "TOKEN-<16 rastgele sayı>" biçiminde jetonlar oluşturan bir sisteminiz olduğunu varsayalım. Bu durumda, Apigee Edge tarafından depolanan tam jeton meta verileri şu şekilde olabilir:

{
  "issued_at": "1469735625687",
  "application_name": "06947a86-919e-4ca3-ac72-036723b18231",
  "scope": "urn://example.com/read",
  "status": "approved",
  "api_product_list": "[implicit-test]",
  "api_product_list_json": ["implicit-test"],
  "expires_in": "1799", //--in seconds
  "developer.email": "joe@weathersample.com",
  "token_type": "BearerToken",
  "client_id": "U9AC66e9YFyI1yqaXgUF8H6b9wUN1TLk",
  "access_token": "TOKEN-1092837373654221",
  "organization_name": "wwitman",
  "refresh_token_expires_in": "0", //--in seconds
  "refresh_count": "0"
}

Bu durumda, bir uygulama Edge'de barındırılan bir API proxy'sine taşıyıcı jetonu TOKEN-1092837373654221 ile birlikte istekte bulunabilir ve Edge, Operation = VerifyAccessToken ile OAuthV2 politikası aracılığıyla bunu doğrulayabilir. Yetkilendirme kodları ve yenileme jetonları için benzer bir içe aktarma kalıbı uygulayabilirsiniz.

İstemci kimlik bilgilerini doğrulama hakkında

Jeton oluşturmanın ön koşullarından biri, istekte bulunan istemcinin doğrulanmasıdır. Apigee Edge'deki OAuthV2/GenerateAccessToken politikası, varsayılan olarak istemci kimlik bilgilerini örtülü bir şekilde doğrular. Normalde bir OAuthV2 jetonu isteğinde client_id ve client_secret, HTTP Basic Authorization (iki nokta üst üste ile birleştirilmiş, ardından base64 kodlamalı) aracılığıyla kodlanarak Authorization üstbilgisinde iletilir. Apigee Edge'deki OAuthV2/GenerateAccessToken politikası bu başlığı kodunu çözer, client_id'yi arar ve iletilen client_secret'ın bu client_id için geçerli olduğunu doğrular. Bu, kimlik bilgilerinin Apigee Edge tarafından bilindiği durumlarda çalışır. Başka bir deyişle, Apigee Edge'de kimlik bilgisi içeren bir geliştirici uygulaması depolanır. Bu kimlik bilgisi, belirtilen client_id ve client_secret değerlerini içerir.

İstemci kimlik bilgilerinin Apigee Edge tarafından doğrulanmaması durumunda, API proxy'nizi jeton oluşturmadan önce istemciyi başka bir yöntemle açıkça doğrulayacak şekilde tasarlamanız gerekir. Bu işlem genellikle ağınızdaki uzak bir uç noktaya bağlanan bir ServiceCallout politikası aracılığıyla yapılır.

Jeton oluşturan API proxy'sinin, istemci kimlik bilgilerini önce doğruladığından örtülü veya açık bir şekilde emin olmanız gerekir. İstemcinin doğrulanmasının, erişim jetonunun oluşturulmasından bağımsız olduğunu unutmayın. Apigee Edge'i her ikisini de yapacak, yalnızca birini yapacak veya hiçbirini yapmayacak şekilde yapılandırabilirsiniz.

Apigee Edge'deki OAuthV2/GenerateAccessToken politikasının, istemci kimlik bilgilerini Edge deposuna göre doğrulamasını istiyorsanız politika yapılandırmasında <ExternalAuthorization> öğesini false olarak ayarlayın veya tamamen atlayın. İstemci kimlik bilgilerini açıkça doğrulamak için harici bir yetkilendirme hizmeti kullanmak istiyorsanız <ExternalAuthorization> değerini true olarak ayarlayın.

Apigee Edge, istemci kimlik bilgilerini doğrulamayabilir ancak yine de client_id'nin Apigee Edge tarafından bilinmesi ve yönetilmesi gerekir. Apigee Edge tarafından oluşturulan veya harici bir sistem tarafından oluşturulup Apigee Edge'e aktarılan tüm Apigee Edge erişim jetonları, client_id ile belirtilen bir istemci uygulamasıyla ilişkilendirilmelidir. Bu nedenle, Apigee Edge'deki OAuthV2/GenerateAccessToken politikası client_id ve client_secret eşleşmesini doğrulamasa bile politika, client_id'nin geçerli, mevcut ve iptal edilmemiş olduğunu doğrular. Bu nedenle, ön koşul kurulum adımı olarak client_id'leri Edge yönetim API'si üzerinden içe aktarmanız gerekebilir.

Apigee'de üçüncü taraf OAuth için politika akışı

Apigee Edge'de üçüncü taraf OAuth sistemlerinden gelen jetonları kullanmak için erişim jetonları oluşturma akışı aşağıdaki kalıplardan birini izlemelidir.

Harici İstemci Kimlik Bilgilerinin Doğrulanması

Gelen istemci kimlik bilgilerini doğrulamak ve harici bir jeton edinmek için ServiceCallout.
Yanıtı dışarıdan oluşturulan jetonu çıkarmak için ExtractVariables veya JavaScript adımı.
AssignMessage, oauth_external_authorization_status adlı özel, iyi bilinen değişkeni ayarlamak için kullanılır. İstemci kimlik bilgilerinin geçerli olduğunu belirtmek için değer doğru olmalıdır.
<ExternalAuthorization> öğesi true olarak ayarlanmış ve <ExternalAccessToken>, <ExternalRefreshToken> veya <ExternalAuthorizationCode> öğelerinden en az biriyle OAuthV2/GenerateAccessToken.

Dahili İstemci Kimlik Bilgilerinin Doğrulanması

Harici jeton almak için ServiceCallout kullanın.
Yanıtı dışarıdan oluşturulan jetonun çıkarılması için ExtractVariables veya JavaScript adımı.
<ExternalAuthorization> öğesi false olarak ayarlanmış ve <ExternalAccessToken>, <ExternalRefreshToken> veya <ExternalAuthorizationCode> öğelerinden en az biriyle OAuthV2/GenerateAccessToken.

Akış ve politika yapılandırmasıyla ilgili notlar

İstemci kimlik bilgilerini doğrulamak için harici bir sistem kullanmak istiyorsanız gerekli işlemleri yapan bir politika akışı geliştirmeniz gerekir. Normalde, harici olarak tanınan kimlik bilgilerini harici kimlik doğrulama hizmetine göndermek için ServiceCallout politikasını kullanırsınız. Harici kimlik doğrulama hizmeti genellikle bir yanıt ve kimlik bilgileri geçerliyse bir erişim jetonu döndürür.
ServiceCallout'tan sonra API proxy'sinin, geçerlilik durumunu, harici olarak oluşturulan access_token'ı ve muhtemelen refresh_token'ı ayıklamak için yanıtı ayrıştırması gerekir.
OAuthV2/GenerateAccessToken politikasında <StoreToken> öğesini true olarak, <ExternalAuthorization> öğesini ise uygun şekilde true veya false olarak ayarlayın.

OAuthV2/GenerateAccessToken politikası yürütüldüğünde oauth_external_authorization_status değişkenini okur. Değişken ayarlanmışsa ve değeri doğruysa Apigee Edge, istemci kimlik bilgilerini doğrulamaya çalışmaz. Değişken ayarlanmamışsa veya değer doğru değilse Apigee Edge, istemci kimlik bilgilerini doğrulamaya çalışır.
OAuthV2 politikası için, içe aktarılacak harici verileri belirtmenize olanak tanıyan üç öğe vardır: <ExternalAccessToken>, <ExternalRefreshToken> ve <ExternalAuthorizationCode>. Bu öğelerin her biri bir akış değişkeni kabul eder. Edge politikası, harici olarak oluşturulan erişim jetonunu, yenileme jetonunu veya yetkilendirme kodunu bulmak için bu değişkeni okur. Harici jetonları veya kodları uygun değişkenlere yerleştirmek için politikalar ve mantık uygulamak sizin sorumluluğunuzdadır.

Örneğin, OAuthV2 politikasındaki aşağıdaki yapılandırma, Edge'e jetonu external_token adlı bir bağlam değişkeninde aramasını söyler.
```
<ExternalAccessToken>external_token</ExternalAccessToken>
```
Ayrıca bu değişkeni ayarlayan önceki bir adımınızın da olması gerekir.
oauth_external_authorization_status değişkeninin ayarlanmasıyla ilgili olarak, bu değişkeni ayarlamak için yaygın bir teknik, AssignVariable öğesiyle birlikte AssignMessage politikası kullanmaktır. Örneğin:
```
<AssignMessage name="AssignMessage-SetVariable">
    <DisplayName>Assign Message - Set Variable</DisplayName>
    <AssignVariable>
        <Name>oauth_external_authorization_status</Name>
        <Value>true</Value>
    </AssignVariable>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</AssignMessage>
```
Bu politikanın, Operation = GenerateAccessToken olan OAuthV2 politikasından önce gelmesi gerektiğini unutmayın.

Örnek OAuthV2 politikası

Aşağıdaki OAuthV2 politikası, Edge'in akış değişkeninde external_access_token bir jeton değeri bulması durumunda bir Apigee Edge erişim jetonu oluşturur.

<OAuthV2 name="OAuth-v20-Store-External-Token">
    <ExternalAccessToken>external_access_token</ExternalAccessToken>
    <ExternalAuthorization>true</ExternalAuthorization>
    <Operation>GenerateAccessToken</Operation>
    <GenerateResponse enabled="true">
        <Format>FORM_PARAM</Format>
    </GenerateResponse>
    <ReuseRefreshToken>false</ReuseRefreshToken>
    <StoreToken>true</StoreToken>
    <SupportedGrantTypes>
        <GrantType>client_credentials</GrantType>
    </SupportedGrantTypes>
    <ExpiresIn ref='flow.variable'>2400000</ExpiresIn>
</OAuthV2>

Normalde, istemci kimlik bilgileri atama türünde, kodlanmış istemci kimliği ve istemci gizli anahtarı ile birlikte bir temel kimlik doğrulama üstbilgisi sağlamanız gerekir. Ancak bu durumda söz konusu başlığı sağlamanız gerekmez. Politika, istekte client_id öğesinin bulunmasını beklemeye devam eder ve politikada bu öğe doğrulanır. Edge, client_id değerinin istek formu verilerinin bir parçası olarak gönderilmesini bekler (ör. request.formparam.client_id içinde).

Teorik olarak, bu kalıbı herhangi bir üçüncü taraf OAuth2 yetkilendirme hizmetiyle uygulayabilirsiniz.