Bu sayfa, Cloud Translation API ile çevrilmiştir.

OAuth2 kapsamlarıyla çalışma

Apigee Edge belgelerini görüntülüyorsunuz.
. Git: Apigee X belgeleri. bilgi

Bu konuda, Apigee Edge'de OAuth 2.0 kapsamlarının nasıl kullanılacağı açıklanmaktadır.

OAuth2 kapsamı nedir?

OAuth 2.0 kapsamları, bir erişime izin verilen erişim miktarını sınırlama yöntemi sunar jeton. Örneğin, bir istemci uygulamasına verilen erişim jetonuna OKUMA ve YAZMA erişimi verilebilir veya yalnızca OKUMA erişimine sahip olursunuz. API'lerinizi kullanarak herhangi bir kapsamı veya seçenekleri belirleyebilirsiniz. Bu nedenle, bir istemci READ kapsamına sahip bir jeton alırsa ve YAZMA erişimi gerektiren bir API uç noktasını çağırmaya çalışırsa çağrı başarısız olur.

Bu konuda, erişim jetonlarına kapsamların nasıl atandığını ve Apigee Edge'in nasıl atanacağını tartışacağız OAuth 2.0 kapsamlarını zorunlu kılar. Bu konuyu okuduktan sonra kapsamları güven.

Kapsamlar erişim jetonlarına nasıl atanır?

Edge bir erişim jetonu oluşturduğunda bu jetona bir kapsam atayabilir. Google Ads'in Bu durumda önce Apigee Edge varlıkları hakkında bilgi sahibi olmanız gerekir: API ürünleri, ve geliştirici uygulamalarından bahsedeceğiz. Tanıtım için Yayıncılığa giriş bölümüne bakın. Önerilerimiz: bu materyali gözden geçirmenizi öneririz.

Erişim jetonu, kullanıcıların giriş yapmak için kullandığı rastgele görünümlü karakterlerden oluşan Edge'in gelen API isteklerini doğrulamasına olanak tanır (bu API'yi tipik ve kullanıcı adı/şifre kimlik bilgileri). Teknik olarak jeton, bir anahtar kelimenin bir araya toplanmış meta verileri içerir:

{
  "issued_at" : "1416962591727",
  "application_name" : "0d3e1d41-a59f-4d74-957e-d4e3275d4781",
  "scope" : "A",
  "status" : "approved",
  "api_product_list" : "[scopecheck1-bs0cSuqS9y]",
  "expires_in" : "1799", //--in seconds
  "developer.email" : "scopecheck1-AdBmANhsag@apigee.com",
  "organization_id" : "0",
  "token_type" : "BearerToken",
  "client_id" : "eTtB7w5lvk3DnOZNGReBlvGvIAeAywun",
  "access_token" : "ODm47ris5AlEty8TDc1itwYPe5MW",
  "organization_name" : "wwitman",
  "refresh_token_expires_in" : "0", //--in seconds
  "refresh_count" : "0"
}

Jetonun meta verileri; gerçek erişim jetonu dizesini, geçerlilik bitiş tarihi bilgilerini, jetonla ilişkili geliştirici uygulaması, geliştirici ve ürünlerin tanımlanması. Bir sonraki meta verinin de "kapsam" bilgilerini içerdiğine dikkat edin.

Jeton, kapsamını nasıl alır?

Kapsamı anlamanın ilk anahtarı, bir geliştirici uygulamasındaki her ürünün veya daha fazla kapsam atanmamış olmalıdır. Bu kapsamlar, ürün şu koşulda atanabilir: veya daha sonra eklenebilir. Bunlar bir ad listesi olarak bulunur ve "meta veriler" bir şablondur.

Bir geliştirici uygulaması oluşturup ona ürün eklediğinizde Edge, Google Play'deki ve bu ürünlere ilişkin tüm kapsamların bir listesini oluşturur (uygulamanın ana kabul edilen tüm kapsamların birleşiminden oluşur).

ziyaret edin.

Bir istemci uygulaması Apigee Edge'den erişim jetonu istediğinde, isteğe bağlı olarak hangi kapsamlarını belirleyebilirsiniz. Örneğin, aşağıdaki istekte sizden "A" kapsamı için yazılmalıdır. Yani istemci, yetkilendirme sunucusunun (Edge) bir "A" kapsamına sahip erişim jetonu ("A" kapsamına sahip API'leri çağırmak için uygulamaya yetki verme). Uygulama şuna benzer bir POST isteği gönderir:

curl -i -X POST -H Authorization: Basic Mg12YTk2UkEIyIBCrtro1QpIG -H content-type:application/x-www-form-urlencoded http://myorg-test.apigee.net/oauth/token?grant_type=client_credentials&scope=A

Süreç

Edge bu isteği aldığında, isteği hangi uygulamanın yaptığını ve hangisinin istediğini bilir. kaydedilen geliştirici uygulaması (istemci kimliği ve istemci gizli anahtarları temel kimlik doğrulama üstbilgisi). scope sorgu parametresi dahil edildiği için Edge'in geliştirici uygulamasıyla ilişkilendirilen API ürünlerinden herhangi birinin "A" kapsamına sahip olup olmadığına karar verir. Varsa ardından "A" kapsamıyla bir erişim jetonu oluşturulur. Buna başka bir bakış da, kapsamın proje kapsamının sorgu parametresi bir tür filtredir. Geliştirici uygulaması "A, B, X" kapsamlarını tanırsa ve sorgu parametresi "scope=X Y Z"yi belirtiyor, ardından yalnızca "X" kapsamını belirtiyor atanacak jeton.

İstemci bir kapsam parametresi eklemezse ne olur? Bu durumda, Edge bir jeton oluşturur Geliştirici uygulaması tarafından tanınan tüm kapsamları içerir. İnsanların Ancak bunun, varsayılan davranışın bütünlüğünü göreceksiniz.

Bir geliştirici uygulamasıyla ilişkilendirilen ürünlerin hiçbiri kapsamları belirtmiyorsa ve bir jeton bu jetonla yapılan çağrılar başarısız olur.

Bir geliştirici uygulamasının şu kapsamları tanıdığını varsayalım: A B C D. Bu, uygulamanın içerdiği kapsamları. Uygulamadaki bir ürün A ve B kapsamına, ikincisi C kapsamına sahip olabilir veya D veya herhangi bir kombinasyonu olabilir. İstemci bir scope parametresi belirtmezse (veya herhangi bir değer içermeyen kapsam parametresini belirttiğinde) jeton dört kapsamın hepsine verilir: A, B, C, ve D. Bu kez de jeton, tanınan tüm kapsamların birleşimini sunan bir dizi kapsam alır. bunu sağlar.

Varsayılan davranışın, tüm eşlemeleri içeren bir erişim jetonu döndürmek izin verilen kapsam dahilindedir. Bu durumda GenerateAccessToken politikası ( erişim jetonları oluşturduğundan) bir <Scope> öğesi belirtmediğinde. Örneğin, <Scope> değerinin geçerli olduğu bir GenerateAccessToken politikası aşağıda verilmiştir. is belirtilmişse. Bu <Scope> öğesi eksikse (veya mevcut ancak boş) varsayılan davranış yürütülür.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<OAuthV2 async="false" continueOnError="false" enabled="true" name="OAuthV2-GenerateAccessToken">
    <DisplayName>OAuthV2 - Generate Access Token</DisplayName>
    <Attributes>
      <Attribute name='hello' ref='system.time' display='false'>value1</Attribute>
    </Attributes>
    <Scope>request.queryparam.scope</Scope> 
    <GrantType>request.formparam.grant_type</GrantType>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>GenerateAccessToken</Operation>
    <SupportedGrantTypes>
      <GrantType>client_credentials</GrantType>
    </SupportedGrantTypes>
  <GenerateResponse enabled="true"/>
</OAuthV2>

Kapsamlar nasıl uygulanır?

Öncelikle, Apigee Edge'de erişim jetonlarının OAuthV2 politikasıyla doğrulandığını unutmayın. (genellikle bir proxy akışının en başına yerleştirilir). Politika, VerifyAccessToken işlemi belirtildi. Bu politikayı inceleyelim:

<OAuthV2 async="false" continueOnError="false" enabled="true" name="OAuthV2-VerifyAccessTokenA">
    <DisplayName>Verify OAuth v2.0 Access Token</DisplayName>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>VerifyAccessToken</Operation>
    <Scope>A</Scope> <!-- Optional: space-separated list of scope names. -->
    <GenerateResponse enabled="true"/>
</OAuthV2>

<Scope> öğesine dikkat edin. Politikanın hangi kapsamları belirtmek için kullanılır? kabul edecek.

Bu örnekte, politika yalnızca erişim jetonu "A" kapsamını içeriyorsa başarılı olur. Bu <Scope> öğesi atlanırsa veya herhangi bir değer yoksa politika erişim jetonu.

Erişim jetonlarını kapsama göre doğrulama özelliği sayesinde artık API'lerinizi belirli kapsamları zorunlu kılmaktır. Bunu, kapsama duyarlı VerifyAccessToken ile özel akışlar tasarlayarak yapabilirsiniz. politikalar.

API'nizde /resourceA uç noktası için tanımlanmış bir akış olduğunu varsayalım:

<Flow name="resourceA">
            <Condition>(proxy.pathsuffix MatchesPath "/resourceA") and (request.verb = "GET")</Condition>
            <Description>Get a resource A</Description>
            <Request>
                <Step>
                    <Name>OAuthV2-VerifyAccessTokenA</Name>
                </Step>
            </Request>
            <Response>
                <Step>
                    <Name>AssignMessage-CreateResponse</Name>
                </Step>
            </Response>
        </Flow>

Bu akış tetiklendiğinde (bir istek, yolda /resourceA ile gelir) soneki) OAuthV2-VerifyAccessTokenA politikası hemen çağrılır. Bu politika, erişim jetonunun geçerli olduğunu ve jetonun hangi kapsamları desteklediğini kontrol eder. Politika aşağıdaki örnekte görüldüğü gibi <Scope>A</Scope> ile yapılandırıldığında politika yalnızca başarılı olur erişim jetonunun "A" kapsamı olup olmadığına bakın. Aksi takdirde bir hata döndürür.

<OAuthV2 async="false" continueOnError="false" enabled="true" name="OAuthV2-VerifyAccessTokenA">
    <DisplayName>Verify OAuth v2.0 Access Token</DisplayName>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>VerifyAccessToken</Operation>
    <Scope>A</Scope>
    <GenerateResponse enabled="true"/>
</OAuthV2>

Özetle, API'lerinde kapsam yaptırımı tasarlamak API geliştiricilerinin sorumluluğundadır. Bunu, belirli kapsamları yönetmek için özel akışlar oluşturarak ve VerifyAccessToken'ı ekleyerek yaparlar. politikaların uygulanmasını sağlamanız gerekir.

Kod örnekleri

Son olarak, jetonların nasıl alındığını göstermek için bazı örnek API çağrılarına bakalım. ve kapsamların nasıl uygulandığıyla ilgili bilgi edineceksiniz.

Varsayılan büyük/küçük harf

Ürünleri içeren bir geliştirici uygulamanız olduğunu ve bu ürünlerin birliğinin kapsamlar şunlardır: A, B ve C. Bu API çağrısı, erişim jetonu istiyor ancak kapsam sorgusu belirtmiyor parametresinden sonra bir değer girin.

curl -X POST -H content-type:application/x-www-form-urlencoded http://wwitman-test.apigee.net/scopecheck1/token?grant_type=client_credentials

Bu durumda, oluşturulan jetona A, B ve C kapsamları (varsayılan davranış) verilir. İlgili içeriği oluşturmak için kullanılan jetonun meta verileri aşağıdaki gibi görünür:

{
  "issued_at" : "1417016208588",
  "application_name" : "eb1a0333-5775-4116-9eb2-c36075ddc360",
  "scope" : "A B C",
  "status" : "approved",
  "api_product_list" : "[scopecheck1-yEgQbQqjRR]",
  "expires_in" : "1799", //--in seconds
  "developer.email" : "scopecheck1-yxiuHuZcDW@apigee.com",
  "organization_id" : "0",
  "token_type" : "BearerToken",
  "client_id" : "atGFvl3jgA0pJd05rXKHeNAC69naDmpW",
  "access_token" : "MveXpj4UYXol38thNoJYIa8fBGlI",
  "organization_name" : "wwitman",
  "refresh_token_expires_in" : "0", //--in seconds
  "refresh_count" : "0"
}

Şimdi, "A" kapsamına sahip bir API uç noktanızın olduğunu varsayalım (yani, VerifyAccessToken URL'sidir.) "A" kapsamını gerektirir. VerifyAccessToken politikası şöyledir:

<OAuthV2 async="false" continueOnError="false" enabled="true" name="OAuthV2-VerifyAccessTokenA">
    <DisplayName>Verify OAuth v2.0 Access Token</DisplayName>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>VerifyAccessToken</Operation>
    <Scope>A</Scope>
    <GenerateResponse enabled="true"/>
</OAuthV2>

Aşağıda, A kapsamını zorunlu kılan bir örnek çağrı ve uç nokta görebilirsiniz:

curl -X GET -H Authorization: Bearer MveXpj4UYXol38thNoJYIa8fBGlI http://wwitman-test.apigee.net/scopecheck1/resourceA

Bu GET çağrısı başarılı olur:

 {
   "hello" : "Tue, 25 Nov 2014 01:35:53 UTC"
 }

Uç nokta çağrıldığında tetiklenen VerifyAccessToken politikası nedeniyle başarılıdır. erişim A, B ve C kapsamlarına (varsayılan olarak) göre gösterir.

Filtreleme durumu

A, B, C ve X kapsamlarına sahip ürünlere sahip bir geliştirici uygulamanız olduğunu varsayalım. Talebiniz bir erişim jetonu ekleyin ve scope sorgu parametresini aşağıdaki gibi ekleyin:

curl -i -X POST -H content-type:application/x-www-form-urlencoded 'http://myorg-test.apigee.net/oauth/token?grant_type=client_credentials&scope=A X'

Bu durumda, oluşturulan jeton A ve X kapsamları verilir, çünkü hem A hem de X bir geçerlidir. Geliştirici uygulamasının A, B, C ve X kapsamlarını tanıdığını unutmayın. Böyle durumlarda API ürünleri listesini bu kapsamlara göre filtreliyorsunuz. Bir ürün A veya X kapsamına sahipse bu kapsamları zorunlu kılacak API uç noktaları yapılandırabilirsiniz. Bir ürünün kapsamı yoksa A veya X (B, C ve Z olduğunu varsayalım) A veya X kapsamlarını uygulayan API'ler çağrılamaz bunu da belirtelim.

API'yi yeni jetonla çağırdığınızda:

curl -X GET -H Authorization: Bearer Rkmqo2UkEIyIBCrtro1QpIG http://wwitman-test.apigee.net/scopecheck1/resourceX

Erişim jetonu, API proxy'si tarafından doğrulanır. Örneğin:

<OAuthV2 async="false" continueOnError="false" enabled="true" name="OAuthV2-VerifyAccessTokenX">
    <DisplayName>Verify OAuth v2.0 Access Token</DisplayName>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>VerifyAccessToken</Operation>
    <Scope>A X</Scope>
    <GenerateResponse enabled="true"/>
</OAuthV2>

GET çağrısı başarılı şekilde tetiklenir ve yanıt döndürür. Örneğin:

 {
   "hello" : "Tue, 25 Nov 2014 01:35:53 UTC"
 }

VerifyAccessToken politikası A veya X kapsamı ve erişim jetonu gerektirdiğinden başarılıdır. A ve X kapsamlarını içerir. Tabii ki <Scope> öğesi "B" olarak ayarlanırsa bu çağrı başarısız olur.

Özet

Apigee Edge'in OAuth 2.0 kapsamlarını nasıl ele aldığını anlamak önemlidir. Temel çıkarımlar puan:

Geliştirici uygulaması tüm ürünleri için tanımlanmış bütün kapsamların birleşimini ortaya çıkarır.
Bir uygulama erişim jetonu istediğinde hangi kapsamları isteyeceğini belirtebilir. çok heyecanlıyım. İzin verilen kapsamları, Apigee Edge (yetkilendirme sunucusu) belirler erişim jetonuna şuna göre atar: (a) istenen kapsamlar ve (b) uygulama tarafından tanınır.
Apigee Edge, kapsamı (<Scope> öğesi) kontrol edecek şekilde yapılandırılmamışsa VerifyAccessToken politikasında yoksa veya boşsa API çağrısı şu şekilde başarılı olur: erişim jetonuna yerleştirilmiş kapsam, kayıtlı geliştirici uygulaması (uygulamanın "ana" kapsam listesindeki kapsamlardan biri).
Bir erişim jetonu, kendisiyle ilişkilendirilmiş kapsamlara sahip değilse yalnızca başarılı olur. Edge'in kapsamı dikkate almadığı (<Scope> öğesi eksik) durumlarda VerifyAccessToken politikasından kaldırmanız gerekir veya alan boştur).