Halaman ini diterjemahkan oleh Cloud Translation API.

Menggunakan Token OAuth Pihak Ketiga

Anda sedang melihat dokumentasi Apigee Edge.
Buka Dokumentasi Apigee X. info

Dalam topik ini, kita akan membahas cara mengimpor token akses yang dibuat secara eksternal, token refresh, atau kode otentikasi ke penyimpanan token Edge. Anda dapat menggunakan teknik ini jika Anda ingin konfigurasikan Apigee Edge untuk memvalidasi token yang dihasilkan di luar Apigee Edge.

Dalam kasus biasa, Apigee Edge akan membuat dan menyimpan token OAuth, dan mengembalikannya ke aplikasi telepon. Kemudian, aplikasi panggilan menampilkan token tersebut ke Apigee Edge saat meminta dan Apigee Edge - melalui kebijakan OAuthV2 dengan Operation = VerifyAccessToken - akan dan memastikan bahwa token valid. Topik ini menjelaskan bagaimana Anda dapat mengonfigurasi Apigee Edge untuk menyimpan token OAuth yang dihasilkan di tempat lain, sambil tetap menjaga bagian verifikasi token tetap sama, seolah-olah token itu dibuat oleh Edge.

Contoh

Jika Anda ingin melihat contoh yang berfungsi yang menggambarkan teknik tersebut yang dijelaskan dalam topik ini, lihat dokumentasi Apigee Contoh Pengelolaan Token yang Didelegasikan.

Apa ini?

Misalkan Anda memiliki sistem otorisasi yang ada, dan Anda ingin menggunakan token atau nilai kode yang dihasilkan oleh sistem tersebut sebagai pengganti nilai token atau kode OAuth2 yang Menghasilkan edge. Anda kemudian bisa membuat permintaan {i>proxy<i} API yang aman dengan token atau kode yang diganti, dan Edge akan memvalidasinya seolah-olah dibuat oleh Edge.

Latar Belakang

Pada kasus yang biasa, Apigee Edge membuat token dengan menghasilkan string huruf dan angka. Apigee Edge terkait dengan token tersebut, data lain seperti waktu penerbitan token, masa berlaku, daftar Produk API dengan token yang valid, dan cakupannya. Semua ini informasi dapat ditampilkan dalam respons yang otomatis dibuat oleh kebijakan OAuthV2 dikonfigurasi dengan Operation = GenerateAccessToken. Responsnya akan terlihat seperti ini:

{
  "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"
}

Nilai atribut access_token sebenarnya adalah kunci pencarian untuk data respons. Sebuah aplikasi dapat membuat permintaan ke {i>proxy<i} API yang di-{i>host<i} di Edge, membawa token pemilik zBC90HhCGmGlaMBWeZAai2s3za5j, dan Edge - dengan OAuthV2 kebijakan dengan Operation = VerifyAccessToken - akan mencari token, mengambil semua informasi, dan menggunakan informasi tersebut untuk menentukan apakah token valid atau tidak, untuk Proxy API yang diminta. Langkah ini disebut Validasi token. Semua informasi di atas membentuk token tersebut. Tujuan nilai access_token hanyalah cara untuk mencari informasi tersebut.

Di sisi lain, dengan mengikuti langkah-langkah yang dijelaskan di sini, Anda dapat mengonfigurasi Edge untuk menyimpan token sehingga nilai access_token-nya adalah sesuatu yang dihasilkan oleh layanan. Semua {i>metadata<i} lainnya mungkin sama. Misalnya, Anda memiliki sebuah sistem eksternal ke Apigee Edge yang menghasilkan token berbentuk "TOKEN-<16 acak angka>" kami. Dalam hal ini, metadata token lengkap yang disimpan oleh Apigee Edge mungkin:

{
  "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"
}

Dalam hal ini, aplikasi dapat membuat permintaan ke proxy API yang dihosting di Edge, yang membawa pembawa token TOKEN-1092837373654221, dan Edge - melalui kebijakan OAuthV2 dengan Operasi = VerifyAccessToken - dapat memvalidasinya. Anda dapat menerapkan pola impor yang serupa untuk kode otorisasi dan token refresh.

Mari Kita Bahas tentang Memvalidasi Klien Kredensial

Salah satu prasyarat untuk membuat token adalah memvalidasi klien yang meminta. Secara default, Kebijakan OAuthV2/GenerateAccessToken di Apigee Edge secara implisit memverifikasi kredensial klien. Biasanya dalam permintaan token OAuthV2, client_id dan client_secret diteruskan di Header otorisasi, yang dienkode melalui Otorisasi Dasar HTTP (digabungkan titik dua, lalu berenkode base64). Kebijakan OAuthV2/GenerateAccessToken di Apigee Edge mendekode header dan mencari client_id, dan memverifikasi bahwa client_secret yang diteruskan valid untuk itu client_id. Ini berfungsi jika kredensial diketahui oleh Apigee Edge - dengan kata lain ada Aplikasi Developer yang disimpan dalam Apigee Edge yang berisi kredensial, yang berisi kredensial diberi client_id dan client_secret.

Jika kredensial klien tidak dapat divalidasi oleh Apigee Edge, Anda harus merancang Proxy API Anda, sebelum menghasilkan token, untuk memvalidasi klien secara eksplisit melalui sarana lain. Sering kali hal ini dilakukan melalui kebijakan ServiceInfo yang terhubung ke titik akhir jarak jauh di jaringan Anda.

Baik secara implisit maupun eksplisit, Anda perlu memastikan bahwa yang menghasilkan token, terlebih dahulu memvalidasi kredensial klien. Perlu diingat bahwa memvalidasi klien tidak bergantung pada pembuatan token akses. Anda dapat mengonfigurasi Apigee Edge untuk melakukan keduanya, atau melakukan salah satunya, atau tidak keduanya.

Jika Anda ingin kebijakan OAuthV2/GenerateAccessToken di Apigee Edge untuk memvalidasi klien kredensial terhadap penyimpanan Edge, setel elemen <ExternalAuthorization> menjadi false di dalam konfigurasi kebijakan, atau hapus sepenuhnya. Jika Anda ingin menggunakan layanan otorisasi eksternal untuk memvalidasi kredensial klien secara eksplisit, menetapkan <ExternalAuthorization> hingga true.

Meskipun Apigee Edge mungkin tidak memvalidasi kredensial klien, Apigee tetap diperlukan client_id dikenal dan dikelola oleh Apigee Edge. Setiap access_token di Apigee Edge, baik dihasilkan oleh Apigee Edge atau dihasilkan oleh sistem eksternal, lalu diimpor ke Apigee Edge, harus dikaitkan dengan aplikasi klien - yang ditunjukkan oleh client_id. Jadi, bahkan dalam kasus di mana kebijakan OAuthV2/GenerateAccessToken di Apigee Edge tidak akan memvalidasi bahwa client_id dan client_secret cocok, kebijakan akan memvalidasi bahwa client_id valid, ada, dan tidak dicabut. Jadi sebagai langkah pengaturan prasyarat, Anda mungkin harus mengimpor client_id melalui Edge API administratif.

Alur Kebijakan untuk OAuth pihak ketiga di Apigee

Untuk menggunakan token dari sistem OAuth pihak ketiga di Apigee Edge, alur untuk menghasilkan akses token harus mengikuti salah satu pola berikut.

Eksternal Validasi Kredensial Klien

ServiceCallout untuk memverifikasi kredensial klien masuk, dan memperoleh token eksternal.
ExtractVariables atau Langkah JavaScript untuk ekstrak token yang dibuat secara eksternal dari respons.
AssignMessage ke menetapkan variabel khusus terkenal yang disebut oauth_external_authorization_status. Nilai harus benar untuk menunjukkan bahwa kredensial klien valid.
OAuthV2/GenerateAccessToken dengan Elemen <ExternalAuthorization> disetel ke true, dan setidaknya satu dari <ExternalAccessToken>, <ExternalRefreshToken>, atau <ExternalAuthorizationCode>.

Internal Validasi Kredensial Klien

ServiceCallout untuk memperoleh token eksternal.
ExtractVariables atau Langkah JavaScript untuk ekstrak token yang dibuat secara eksternal dari respons.
OAuthV2/GenerateAccessToken dengan Elemen <ExternalAuthorization> disetel ke false, dan setidaknya satu dari <ExternalAccessToken>, <ExternalRefreshToken>, atau <ExternalAuthorizationCode>.

Catatan tentang alur dan konfigurasi kebijakan

Jika Anda ingin menggunakan sistem eksternal untuk memvalidasi kredensial klien, Anda dapat mengembangkan alur kebijakan yang melakukan apa yang diperlukan. Biasanya Anda akan menggunakan Kebijakan ServiceInfo untuk mengirim kredensial yang dikenali secara eksternal ke eksternal layanan otentikasi. Layanan otentikasi eksternal biasanya akan mengembalikan respons dan jika kredensial valid, juga token akses.
Setelah ServiceKeterangan, proxy API perlu mengurai respons untuk mengekstrak status validitas, serta access_token yang dihasilkan secara eksternal dan mungkin refresh_token.
Pada kebijakan OAuthV2/GenerateAccessToken, tetapkan elemen <StoreToken> ke true, dan setel elemen <ExternalAuthorization> ke true atau false yang sesuai.

Saat kebijakan OAuthV2/GenerateAccessToken dijalankan, kebijakan akan membaca variabel oauth_external_authorization_status. Jika variabel ditetapkan dan nilainya true, maka Apigee Edge tidak mencoba memvalidasi kredensial klien. Jika variabel tidak ditetapkan atau nilainya salah, maka Apigee Edge akan mencoba memvalidasi klien memiliki kredensial yang lengkap.
Ada tiga elemen untuk kebijakan OAuthV2 yang memungkinkan Anda menentukan data yang akan diimpor: <ExternalAccessToken>, <ExternalRefreshToken>, dan <ExternalAuthorizationCode>. Masing-masing elemen ini menerima sebuah variabel flow. Kebijakan Edge akan membaca variabel tersebut untuk menemukan token akses yang dibuat secara eksternal, token pembaruan, atau kode otorisasi. Terserah Anda untuk terapkan kebijakan dan logika untuk menempatkan token atau kode eksternal di variabel.

Misalnya, konfigurasi dalam kebijakan OAuthV2 berikut memberi tahu Edge untuk mencari token dalam variabel konteks bernama external_token.
```
<ExternalAccessToken>external_token</ExternalAccessToken>
```
Anda juga harus memiliki langkah sebelumnya yang menetapkan variabel tersebut.

Terkait penetapan variabel oauth_external_authorization_status, untuk menetapkan variabel ini adalah menggunakan kebijakan MenetapkanMessage dengan elemen TetapkanVariable, seperti ini:

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

Ingat, kebijakan ini harus ditetapkan sebelum kebijakan OAuthV2 dengan Operation = GenerateAccessToken.

Contoh kebijakan OAuthV2

Kebijakan OAuthV2 berikut membuat token akses Apigee Edge mengingat Edge menemukan nilai token di variabel flow external_access_token.

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

Biasanya, dengan klien jenis pemberian kredensial, Anda harus menyediakan header Autentikasi Dasar dengan ID, dan Rahasia Klien. Namun, dalam kasus ini, Anda tidak perlu memberikan {i>header<i}. Kebijakan ini tetap mengharapkan client_id ada dalam permintaan, dan kebijakan kami akan memvalidasinya. Edge mengharapkan client_id dikirim sebagai bagian data formulir permintaan, misalnya, dalam request.formparam.client_id.

Secara teori, Anda dapat menerapkan pola ini dengan otorisasi OAuth2 pihak ketiga apa pun layanan.