Kebijakan OAuthV2

Halaman ini berlaku untuk Apigee dan Apigee hybrid.

Lihat Dokumentasi Apigee Edge.

ikon kebijakan

Apa

OAuthV2 adalah kebijakan multifaset untuk menjalankan operasi jenis pemberian izin OAuth 2.0. Ini adalah kebijakan utama yang digunakan untuk mengonfigurasi endpoint OAuth 2.0 di Apigee.

Kebijakan ini merupakan Kebijakan yang dapat diperluas dan penggunaan kebijakan ini mungkin menimbulkan biaya atau implikasi penggunaan, bergantung pada lisensi Apigee Anda. Untuk mengetahui informasi tentang jenis kebijakan dan implikasi penggunaan, lihat Jenis kebijakan.

Tips: Jika ingin mempelajari OAuth di Apigee lebih lanjut, lihat halaman beranda OAuth. Menyediakan link ke referensi, sampel, video, dan lain-lain.

Contoh

VerifyAccessToken

VerifyAccessToken

Konfigurasi kebijakan OAuthV2 ini (dengan operasi VerifyAccessToken) memverifikasi bahwa token akses yang dikirimkan ke Apigee valid. Saat operasi kebijakan ini dipicu, Apigee mencari token akses yang valid dalam permintaan. Jika token akses valid, permintaannya akan diizinkan untuk melanjutkan. Jika tidak valid, semua pemrosesan berhenti dan error akan ditampilkan dalam yang dihasilkan. 

<OAuthV2 name="OAuthV2-Verify-Access-Token">
    <Operation>VerifyAccessToken</Operation>
</OAuthV2>

Aplikasi klien perlu mengirim permintaan dengan token. Contoh penggunaan curl mungkin:

$ curl https://API_ENDPOINT/weather/forecastrss?w=12797282 \
  -H "Authorization: Bearer ylSkZIjbdWybfsUQe9BqP0LH5Z"

Dengan API_ENDPOINT adalah domain yang digunakan untuk mengakses API Anda, seperti yang dikonfigurasi di sistem Apigee Anda.

Secara default, kebijakan OAuthV2 mengekstrak token akses dari header Authorization, menghapus awalan Bearer. Anda dapat mengubah perilaku default ini dengan elemen konfigurasi AccessToken.

GenerateAccessToken

Membuat token akses

Misalnya yang menunjukkan cara meminta token akses untuk setiap jenis pemberian yang didukung, lihat Mendapatkan token OAuth 2.0. Topik ini mencakup contoh operasi berikut:

GenerateAuthorizationCode

Buat kode otorisasi

Untuk contoh yang menunjukkan cara meminta kode otorisasi, lihat Meminta kode otorisasi Anda.

RefreshAccessToken

Memuat ulang token akses

Untuk contoh yang menunjukkan cara meminta token akses menggunakan token refresh, lihat Memuat ulang token akses.

Token akses JWT

Token akses JWT

Untuk contoh yang menunjukkan cara membuat, memverifikasi, dan memperbarui token akses JWT, lihat Menggunakan token akses JWT.

Token alur respons

Membuat token akses di alur respons

Terkadang Anda mungkin perlu membuat token akses di alur respons. Sebagai contoh, Anda dapat melakukannya sebagai respons terhadap validasi kustom yang dilakukan di layanan backend. Dalam contoh ini, kasus penggunaan memerlukan token akses dan token refresh, mengesampingkan pemberian implisit . Dalam hal ini, kita akan menggunakan tipe pemberian {i>password<i} untuk membuat token. Seperti yang akan Anda lihat, Trik untuk melakukan pekerjaan ini adalah dengan meneruskan header permintaan Otorisasi dengan JavaScript lebih lanjut.

Pertama, mari kita lihat contoh kebijakan:

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

Jika kebijakan ini ditempatkan di alur respons, kebijakan akan gagal dengan pesan error 401 UnAuthorized meskipun parameter login yang benar telah ditetapkan dalam kebijakan. Untuk mengatasi masalah ini, Anda perlu menetapkan header permintaan Otorisasi.

Header Authorization harus berisi skema Akses dasar dengan enkode Base64 client_id:client_secret.

Anda dapat menambahkan {i>header<i} ini dengan kebijakan JavaScript yang ditempatkan tepat sebelum kebijakan OAuthV2, seperti ini. Kolom "local_clientid" dan "local_secret" variabel konteks harus sudah ditetapkan sebelumnya dan yang tersedia dalam alur:

var clientId = context.getVariable("local_clientid");
var clientSecret = context.getVariable("local_secret");
context.setVariable("request.header.Authorization","Basic "+ CryptoJS.enc.Base64.stringify(CryptoJS.enc.Latin1
                                      .parse(clientId + ':' + clientSecret)));

Lihat juga Dasar encoding kredensial autentikasi.

Referensi elemen

Referensi kebijakan menjelaskan elemen dan atribut kebijakan OAuthV2.

Kebijakan contoh yang ditampilkan di bawah adalah salah satu dari banyak kemungkinan konfigurasi. Sampel ini menunjukkan Kebijakan OAuthV2 yang dikonfigurasi untuk operasi GenerateAccessToken. Hal ini mencakup persyaratan yang diperlukan dan elemen opsional. Lihat deskripsi elemen di bagian ini untuk detailnya.

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

<OAuthV2 async="false" continueOnError="false" enabled="true" name="MyOAuthPolicy">

Tabel berikut menjelaskan atribut yang sama untuk semua elemen induk kebijakan:

Atribut Deskripsi Default Kehadiran
name

Nama internal kebijakan. Nilai atribut name dapat berisi huruf, angka, spasi, tanda hubung, garis bawah, dan titik. Nilai ini tidak boleh melebihi 255 karakter.

Atau, gunakan elemen <DisplayName> untuk memberi label kebijakan di editor proxy UI pengelolaan dengan nama natural-language yang berbeda.

 T/A Diperlukan
continueOnError

Setel ke false untuk menampilkan error jika kebijakan gagal. Ini adalah perilaku yang wajar untuk sebagian besar kebijakan.

Setel ke true agar eksekusi alur tetap berlanjut bahkan setelah kebijakan gagal. Lihat juga:

 false Opsional
enabled

Setel ke true untuk menerapkan kebijakan.

Setel ke false untuk menonaktifkan kebijakan. Kebijakan tidak akan diterapkan meskipun tetap melekat pada alur.

 true Opsional
async

Atribut ini sudah tidak digunakan lagi.

 false Tidak digunakan lagi

Elemen <DisplayName>

Gunakan selain atribut name untuk memberi label kebijakan di editor proxy UI pengelolaan dengan nama natural-language yang berbeda.

<DisplayName>Policy Display Name</DisplayName>
Default

T/A

Jika Anda menghapus elemen ini, nilai atribut name kebijakan akan digunakan.
Kehadiran Opsional
Jenis String

&lt;AccessToken&gt; elemen

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

Secara default, jika Operation adalah VerifyAccessToken, kebijakan tersebut mengharapkan token akses dikirim di Authorization header sebagai token pembawa; yaitu, dengan awalan "Bearer", diikuti dengan satu spasi kosong. Anda dapat mengubah {i>default<i} tersebut menggunakan elemen ini, dengan menentukan nama variabel yang berisi token akses untuk diverifikasi. Ketika Anda menggunakan elemen ini, kebijakan secara {i>default<i} tidak cari awalan dalam isi variabel tersebut. Jika Anda ingin menentukan bahwa kebijakan harus mencari awalan, gunakan Elemen AccessTokenPrefix juga.

Contoh:

  • Saat konfigurasi kebijakan:

      <OAuthV2 name="OAuthV2-Verify-Access-Token-in-Header">
      <Operation>VerifyAccessToken</Operation>
      <AccessToken>request.header.access_token</AccessToken>
  </OAuthV2>

    Untuk meneruskan token menggunakan curl, Anda dapat menggunakan:

      curl https://API_ENDPOINT/oauth2/validate -H "access_token:Rft3dqrs56Blirls56a"

  • Saat konfigurasi kebijakan:

      <OAuthV2 name="OAuthV2-Verify-Access-Token-in-QueryParam">
      <Operation>VerifyAccessToken</Operation>
      <AccessToken>request.queryparam.token</AccessToken>
  </OAuthV2>

    Untuk meneruskan token menggunakan curl, Anda dapat menggunakan:

      curl "https://API_ENDPOINT/oauth2/validate?token=Rft3dqrs56Blirls56a"

Jika API_ENDPOINT adalah domain yang digunakan untuk mengakses API Anda, seperti yang dikonfigurasi di sistem Apigee Anda.

Default:

T/A

Kehadiran:

Opsional
Jenis: String
Nilai yang valid:

nama variabel apa pun
Digunakan dengan operasi:
  • VerifyAccessToken

&lt;AccessTokenPrefix&gt; elemen

<AccessTokenPrefix>Prefix</AccessTokenPrefix>

Secara default, jika Operation adalah VerifyAccessToken, kebijakan tersebut mengharapkan token akses dikirim di Authorization header sebagai token pembawa; yaitu, dengan awalan "Bearer", diikuti dengan satu spasi kosong. Jika Anda menggunakan elemen AccessToken untuk menentukan lokasi yang berbeda untuk token akses yang masuk, Anda juga bisa menggunakan elemen ini, AccessTokenPrefix, untuk menentukan awalan non-standar yang berbeda.

Misalnya, jika Anda menentukan:

<OAuthV2 name="OAuthV2-Verify-Access-Token-Alternative-Header">
    <Operation>VerifyAccessToken</Operation>
    <AccessToken>request.header.token</AccessToken>
    <AccessTokenPrefix>KEY</AccessTokenPrefix>
</OAuthV2>

Kemudian, kebijakan tersebut akan mengekstrak token akses masuk dari header permintaan token, dengan cara ini: jika {i>header<i} diawali dengan kata "KEY" diikuti dengan spasi, maka kebijakan itu akan menghapus awalan dan spasi, kemudian tafsirkan nilai yang tersisa sebagai token akses. Jika awalan yang ditentukan tidak ada di {i>header<i}, maka kebijakan akan menampilkan kesalahan.

Jika Anda menetapkan elemen AccessToken, dan tidak menetapkan elemen AccessTokenPrefix, kebijakan tersebut akan menafsirkan seluruh nilai variabel yang ditentukan dalam elemen AccessToken sebagai token akses.

Elemen ini hanya efektif jika elemen AccessToken juga digunakan.

Default:

-tidak ada-

Kehadiran:

Opsional
Jenis: String
Nilai yang valid:

string apa pun
Digunakan dengan operasi:
  • VerifyAccessToken

&lt;Algorithm&gt;

<Algorithm>algorithm-here</Algorithm>

Menentukan algoritma enkripsi yang digunakan untuk menandatangani token akses JWT. Algoritma RSA (RS*) menggunakan pasangan kunci publik/rahasia, sementara algoritma HMAC (HS*) menggunakan rahasia bersama. Elemen ini wajib diisi untuk operasi GenerateJWTAccessToken, VerifyJWTAccessToken, dan RefreshJWTAccessToken.

Default T/A
Kehadiran Diperlukan saat menggunakan GenerateJWTAccessToken, VerifyJWTAccessToken, dan RefreshJWTAccessToken operasional bisnis.
Jenis String
Nilai yang valid HS256, HS384, HS512, RS256, RS384, RS512

&lt;AppEndUser&gt; elemen

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

Dalam hal di mana ID pengguna akhir aplikasi harus dikirim ke server otorisasi, elemen ini memungkinkan tentukan di mana Apigee akan mencari ID pengguna akhir. Misalnya, dapat dikirim sebagai kueri atau di header HTTP.

Misalnya, request.queryparam.app_enduser menunjukkan bahwa AppEndUser harus ada sebagai parameter kueri, sebagaimana, untuk contoh, ?app_enduser=ntesla@theramin.com. Untuk mewajibkan AppEndUser di HTTP misalnya, tetapkan nilai ini ke request.header.app_enduser.

Menyediakan setelan ini memungkinkan Anda menyertakan ID pengguna akhir aplikasi dalam token akses. Ini berguna jika Anda ingin dapat mengambil atau mencabut token akses OAuth 2.0 pada akhir ID pengguna. Untuk informasi selengkapnya, lihat Mengaktifkan pengambilan dan pencabutan token akses OAuth 2.0 berdasarkan ID pengguna akhir, ID aplikasi, atau keduanya.

Default:

T/A

Kehadiran:

Opsional
Jenis: String
Nilai yang valid:

Variabel alur apa pun yang dapat diakses oleh kebijakan saat runtime.
Digunakan dengan jenis pemberian izin:
  • authorization_code
  • implisit
  • sandi
  • client_credentials

&lt;Attributes/Attribute&gt;

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

Gunakan elemen ini untuk menambahkan atribut khusus ke token akses atau kode otorisasi. Sebagai misalnya, Anda mungkin ingin menyematkan ID pengguna atau pengenal sesi dalam token akses yang dapat diekstrak dan diperiksa pada saat runtime.

Elemen ini memungkinkan Anda menentukan nilai dalam variabel alur atau dari string literal. Jika Anda menentukan variabel dan string, nilai yang ditetapkan dalam variabel flow akan digunakan. Jika variabel tidak dapat di-resolve, maka stringnya adalah default-nya.

Untuk informasi selengkapnya tentang penggunaan elemen ini, lihat Menyesuaikan Token dan Kode Otorisasi.

Menampilkan atau menyembunyikan atribut khusus di respons

Perlu diingat bahwa jika Anda menetapkan elemen GenerateResponse kebijakan ini ke true, representasi JSON token yang lengkap akan ditampilkan dalam respons, termasuk respons yang Anda tetapkan. Pada beberapa kasus, Anda mungkin ingin menyembunyikan beberapa atau semua dalam respons sehingga tidak terlihat oleh aplikasi klien.

Secara default, atribut khusus muncul dalam respons. Jika Anda ingin menyembunyikannya, Anda dapat mengatur parameter display ke false. Contoh:

<Attributes>
    <Attribute name="employee_id" ref="employee.id" display="false"/>
    <Attribute name="employee_name" ref="employee.name" display="false"/>
</Attributes>

Nilai atribut display bukan dipertahankan. Katakanlah Anda membuat token akses dengan atribut khusus yang ingin Anda sembunyikan di respons yang dihasilkan. Menetapkan display=false akan mencapai sasaran tersebut. Namun, jika model token akses dibuat nanti menggunakan token refresh, atribut khusus asli dari token akses akan muncul di respons token refresh. Hal ini karena Apigee tidak mengingat bahwa Atribut display awalnya ditetapkan ke false dalam kebijakan pembuatan token akses, hanya merupakan bagian dari metadata token akses.

Anda akan melihat perilaku yang sama jika menambahkan atribut khusus ke kode otorisasi--saat token akses dibuat menggunakan kode tersebut, atribut khusus tersebut akan muncul di token akses yang dihasilkan. Sekali lagi, ini mungkin bukan perilaku yang Anda inginkan.

Untuk menyembunyikan opsi kustom, dalam kasus ini, Anda memiliki pilihan berikut:

  • Reset atribut khusus secara eksplisit dalam kebijakan token refresh dan tetapkan tampilannya ke {i>false<i}. Dalam hal ini, Anda mungkin perlu mengambil nilai kustom asli dari versi aslinya token akses menggunakan kebijakan GetOAuthV2Info.
  • Gunakan kebijakan JavaScript pascapemrosesan untuk mengekstrak atribut khusus yang tidak Anda miliki secara manual kita lihat dalam respons.

Lihat juga Menyesuaikan Token dan Kode Otorisasi.

Default:

N/A

Kehadiran:

Opsional
Nilai yang valid:
  • name -Nama atribut
  • ref - Nilai atribut. Dapat berasal dari variabel flow.
  • display - (Opsional) Memungkinkan Anda menentukan apakah atribut khusus akan muncul dalam respons. Jika true, atribut khusus muncul dalam respons (Jika GenerateResponse juga diaktifkan). Jika false, kustom tidak disertakan dalam respons. Nilai defaultnya adalah true. Lihat Menampilkan atau menyembunyikan atribut khusus dalam respons.
Digunakan dengan jenis pemberian izin:
  • authorization_code
  • implisit
  • sandi
  • client_credentials
  • refresh_token
  • Juga dapat digunakan dengan operasi GenerateAuthorizationCode.

&lt;CacheExpiryInSeconds&gt; elemen

<CacheExpiryInSeconds ref="request.queryparam.cache_expiry">Value 1</CacheExpiryInSeconds>

Elemen ini menerapkan TTL pada cache, yang memungkinkan penyesuaian jangka waktu untuk masa berlaku token akses yang di-cache. Rentang yang didukung adalah antara 1 dan 180 detik. Anda dapat menyediakan variabel alur dan variabel default. Jika disediakan, nilai variabel flow akan diprioritaskan daripada nilai default yang ditentukan.

Elemen ini hanya dapat digunakan dengan operasi VerifyAccessToken.

Default T/A

Jika Anda menghapus elemen ini, periode habis masa berlaku default untuk token akses yang di-cache adalah 180 detik.
Kehadiran Opsional
Jenis Bilangan bulat
Nilai valid Bilangan bulat positif apa pun, bukan nol. Menentukan waktu habis masa berlaku dalam detik.

Atribut

Tabel berikut menjelaskan atribut elemen <CacheExpiryInSeconds>

Atribut Deskripsi Default Kehadiran
referensi

Referensi ke variabel alur yang berisi nilai untuk masa berlaku cache, yang dinyatakan dalam detik.

Jika disediakan, nilai variabel flow akan diprioritaskan daripada nilai default yang ditentukan.

 T/A Opsional

&lt;ClientId&gt; elemen

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

Dalam beberapa kasus, aplikasi klien harus mengirim ID klien ke server otorisasi. Ini memungkinkan Anda menentukan di mana Apigee harus mencari client ID. Satu-satunya yang valid yang dapat Anda tetapkan adalah variabel flow request.formparam.client_id. Menyetel ClientId ke variabel lain tidak didukung. Lihat juga Mendapatkan token OAuth 2.0.

Default:

request.formparam.client_id (x-www-form-urlencoding dan ditentukan dalam permintaan isi)

Kehadiran:

Opsional
Jenis: String
Nilai yang valid: Variabel flow: request.formparam.client_id
Digunakan dengan jenis pemberian izin:
  • authorization_code
  • sandi
  • implisit
  • client_credentials

Juga dapat digunakan dengan operasi GenerateAuthorizationCode.

&lt;Code&gt; elemen

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

Di alur jenis pemberian otorisasi, klien harus mengirimkan kode otorisasi ke server otorisasi (Apigee). Elemen ini memungkinkan Anda menentukan di mana Apigee harus mencari kode otorisasi Anda. Misalnya, URL dapat dikirim sebagai parameter kueri, header HTTP, atau formulir (default).

Variabel, request.queryparam.auth_code menunjukkan bahwa kode otorisasi harus ada sebagai parameter kueri, misalnya untuk contoh, ?auth_code=AfGlvs9. Untuk mewajibkan kode otorisasi dalam misalnya, tetapkan nilai ini ke request.header.auth_code. Lihat juga Dapatkan token OAuth 2.0.

Default:

request.formparam.code (x-www-form-urlencoding dan ditentukan dalam isi permintaan)

Kehadiran:

opsional
Jenis: String
Nilai yang valid: Variabel alur apa pun yang dapat diakses oleh kebijakan saat runtime
Digunakan dengan jenis pemberian izin: authorization_code

&lt;ExpiresIn&gt; elemen

<ExpiresIn>10000</ExpiresIn>

Menerapkan waktu habis masa berlaku token akses dan kode otorisasi dalam milidetik. (Untuk token refresh, gunakan <RefreshTokenExpiresIn>.) Nilai waktu masa berlaku adalah nilai yang dihasilkan sistem ditambah nilai <ExpiresIn>. Jika <ExpiresIn> disetel ke -1, masa berlaku token atau kode akan berakhir sesuai masa berlaku token akses OAuth maksimum. Jika <ExpiresIn> tidak ditentukan, sistem akan menerapkan untuk nilai default yang dikonfigurasi di tingkat sistem.

Waktu habis masa berlaku juga dapat disetel saat runtime menggunakan nilai default hard code atau dengan yang merujuk ke variabel flow. Misalnya, Anda dapat menyimpan nilai habis masa berlaku token di nilai kunci memetakan, mengambilnya, menetapkan variabel, dan mereferensikannya dalam kebijakan. Contoh, kvm.oauth.expires_in.

Apigee menjaga entity berikut dalam cache minimal selama 180 detik setelah entity diakses.

  • Token akses OAuth. Ini berarti Elemen ExpiresIn di kebijakan OAuth v2 tidak dapat digunakan masa berlaku token akses berakhir dalam waktu kurang dari 180 detik.
  • Entitas Key Management Service (KMS) (Aplikasi, Developer, Produk API).
  • Atribut khusus pada token OAuth dan entity KMS.

Stanza berikut menentukan variabel alur dan nilai default juga. Perhatikan bahwa alur nilai variabel lebih diprioritaskan daripada nilai default yang ditentukan.

<ExpiresIn ref="kvm.oauth.expires_in">
    3600000 <!--default value in milliseconds-->
</ExpiresIn>

Apigee tidak mendukung cara memaksa habis masa berlaku token setelah token tersebut dibuat. Jika Anda perlu memaksakan akhir masa berlaku token (misalnya, berdasarkan suatu kondisi), solusi yang dapat dilakukan adalah dijelaskan di postingan Komunitas Apigee ini.

Secara default, token akses yang sudah tidak berlaku akan dihapus dari Apigee Sistem Apigee secara otomatis 3 hari setelah masa berlaku habis. Lihat juga Menghapus akses token

Default:

Jika tidak ditentukan, sistem akan menerapkan nilai default yang dikonfigurasi pada sistem level organisasi.

Kehadiran:

Opsional
Jenis: Bilangan bulat
Nilai yang valid:
  • Bilangan bulat positif apa pun, bukan nol. Tentukan waktu masa berlaku dalam milidetik. Meskipun nilai elemen ini dalam milidetik, nilai yang ditetapkan dalam expires_in token dan variabel flow expires_in dinyatakan dalam detik.
  • -1 akan habis masa berlakunya sesuai masa berlaku token akses OAuth maksimum.

    Catatan: Menentukan bilangan bulat negatif lainnya atau nol akan menyebabkan error deployment.
Digunakan dengan jenis pemberian izin:
  • authorization_code
  • implisit
  • sandi
  • client_credentials
  • refresh_token

Juga digunakan dengan operasi GenerateAuthorizationCode.

&lt;ExternalAccessToken&gt; elemen

<ExternalAccessToken>request.queryparam.external_access_token</ExternalAccessToken>

Memberi tahu Apigee tempat menemukan token akses eksternal (token akses yang tidak dibuat oleh Apigee).

Variabel request.queryparam.external_access_token menunjukkan bahwa token akses eksternal harus ada sebagai parameter kueri, seperti untuk contoh, ?external_access_token=12345678. Untuk mewajibkan token akses eksternal di header HTTP, misalnya, tetapkan nilai ini ke request.header.external_access_token. Lihat juga Menggunakan OAuth Pihak Ketiga Token.

&lt;ExternalAuthorization&gt; elemen

<ExternalAuthorization>true</ExternalAuthorization>

Jika elemen ini salah atau tidak ada, Apigee akan memvalidasi client_id dan client_secret biasanya terhadap penyimpanan otorisasi Apigee. Gunakan elemen ini ketika Anda ingin bekerja dengan token OAuth pihak ketiga. Untuk detail tentang cara menggunakan elemen ini, lihat Menggunakan OAuth Pihak Ketiga Token.

Default:

salah

Kehadiran:

Opsional
Jenis: Boolean
Nilai yang valid: benar atau salah
Digunakan dengan jenis pemberian izin:
  • authorization_code
  • sandi
  • client_credentials

&lt;ExternalAuthorizationCode&gt; elemen

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

Memberi tahu Apigee tempat menemukan kode autentikasi eksternal (kode autentikasi yang tidak dibuat oleh Apigee).

Variabel request.queryparam.external_auth_code menunjukkan bahwa kode autentikasi eksternal harus ada sebagai parameter kueri, sebagaimana, contoh, ?external_auth_code=12345678. Untuk mewajibkan autentikasi eksternal kode di header HTTP, misalnya, tetapkan nilai ini ke request.header.external_auth_code. Lihat juga Menggunakan OAuth Pihak Ketiga Token.

&lt;ExternalRefreshToken&gt; elemen

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

Memberi tahu Apigee tempat menemukan token refresh eksternal (token refresh yang tidak dibuat oleh Apigee).

Variabel request.queryparam.external_refresh_token menunjukkan bahwa token refresh eksternal harus ada sebagai parameter kueri, misalnya contoh, ?external_refresh_token=12345678. Untuk mewajibkan token refresh eksternal di header HTTP, misalnya, tetapkan nilai ini ke request.header.external_refresh_token. Lihat juga Menggunakan OAuth Pihak Ketiga Token.

&lt;GenerateResponse&gt; elemen

<GenerateResponse enabled='true'/>

Jika ditetapkan ke true atau jika atribut enabled dihapus, kebijakan menghasilkan dan menampilkan respons. Misalnya, untuk GenerateAccessToken, responsnya mungkin seperti berikut:

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

Jika ditetapkan ke false atau jika elemen <GenerateResponse> dihilangkan, tidak ada respons yang dikirim. Sebagai gantinya, kumpulan variabel alur diisi dengan nilai yang terkait dengan fungsi kebijakan. Misalnya, variabel {i>flow<i} yang disebut oauthv2authcode.OAuthV2-GenerateAuthorizationCode.code akan diisi dengan kode auth yang dicetak. Perhatikan bahwa expires_in dinyatakan dalam detik dalam yang dihasilkan.

Default:

benar

Kehadiran:

Opsional
Jenis: string
Nilai yang valid: benar atau salah
Digunakan dengan jenis pemberian izin:
  • implisit
  • sandi
  • client_credentials
  • refresh_token
  • Juga dapat digunakan dengan operasi GenerateAuthorizationCode.

&lt;GenerateErrorResponse&gt; elemen

<GenerateErrorResponse enabled='true'/>

Jika disetel ke true, kebijakan akan membuat dan menampilkan respons jika Atribut ContinueOnError disetel ke benar (true). Jika false (default), tidak respons dikirim. Sebagai gantinya, kumpulan variabel alur diisi dengan nilai yang terkait dengan fungsi kebijakan.

Default:

salah

Kehadiran:

Opsional
Jenis: string
Nilai yang valid: benar atau salah
Digunakan dengan jenis pemberian izin:
  • implisit
  • sandi
  • client_credentials
  • refresh_token
  • Juga dapat digunakan dengan operasi GenerateAuthorizationCode.

&lt;GrantType&gt;

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

Memberi tahu kebijakan tempat parameter jenis pemberian izin yang diteruskan dalam permintaan. Sesuai dengan spesifikasi OAuth 2.0, jenis pemberian harus dilengkapi dengan permintaan untuk token akses dan kode otorisasi Anda. Variabel dapat berupa header, parameter kueri, atau parameter formulir (default).

Misalnya, request.queryparam.grant_type menunjukkan bahwa Sandi harus ada sebagai parameter kueri, misalnya, ?grant_type=password. Untuk mewajibkan jenis pemberian izin di header HTTP, misalnya, tetapkan nilai ini ke request.header.grant_type. Lihat juga Mendapatkan token OAuth 2.0.

Default:

request.formparam.grant_type (x-www-form-url berandadienkode dan ditentukan dalam permintaan isi)

Kehadiran:

Opsional
Jenis: string
Nilai yang valid: Variabel, seperti yang dijelaskan di atas.
Digunakan dengan jenis pemberian izin:
  • authorization_code
  • sandi
  • implisit
  • client_credentials
  • refresh_token

&lt;Operation&gt; elemen

<Operation>GenerateAuthorizationCode</Operation>

Operasi OAuth 2.0 yang dijalankan oleh kebijakan.

Default:

Jika <Operation> tidak ditentukan, Apigee akan melihat daftar <SupportedGrantTypes>. Hanya operasi pada jenis pemberian tersebut yang akan berhasil. Dengan kata lain, Anda dapat menghilangkan <Operation> jika menentukan <GrantType> dalam daftar <SupportedGrantTypes>. Jika <Operation> atau <SupportedGrantTypes> bukan jenis pemberian {i>default-<i}nya adalah authorization_code. Yaitu, authorization_code permintaan jenis hibah akan berhasil, tetapi yang lainnya akan gagal.

Kehadiran:

Opsional
Jenis: String
Nilai yang valid:
  • GenerateAccessToken - Menghasilkan token akses. Lihat juga Mendapatkan token OAuth 2.0.
  • GenerateAccessTokenImplicitGrant - Menghasilkan token akses untuk jenis pemberian implisit. Lihat juga Mendapatkan token OAuth 2.0.
  • GenerateAuthorizationCode - Menghasilkan kode autentikasi. Digunakan dengan jenis pemberian kode otorisasi. Lihat juga Mendapatkan token OAuth 2.0.
  • RefreshAccessToken - Menukarkan token refresh dengan token akses baru. Lihat juga Mendapatkan token OAuth 2.0.
  • VerifyAccessToken - Memverifikasi bahwa token akses yang dikirim dalam permintaan valid. Lihat contoh VerifyAccessToken di atas dan Memverifikasi token akses.
  • InvalidateToken - Mencabut token akses. Setelah token dicabut, klien tidak dapat menggunakan token tersebut untuk memanggil API yang dilindungi. Lihat juga Menyetujui dan mencabut token akses.
  • ValidateToken - Mengaktifkan kembali atau "menyetujui" token akses yang sebelumnya dicabut. Lihat juga Menyetujui dan mencabut token akses.

Operasi token akses JWT tambahan

Jika Anda lebih suka menggunakan token akses JWT daripada token string buram, operasi berikut juga tersedia untuk menghasilkan dan memvalidasi token JWT. Untuk mengetahui detailnya, lihat Menggunakan operasi token OAuth JWT:

&lt;PassWord&gt; elemen

<PassWord>request.queryparam.password</PassWord>

Elemen ini digunakan dengan jenis pemberian sandi saja. Dengan jenis pemberian sandi, kredensial pengguna (sandi dan nama pengguna) harus disediakan untuk kebijakan OAuthV2. Elemen <PassWord> dan <UserName> digunakan untuk menentukan variabel di mana Apigee dapat menemukan nilai ini. Jika elemen-elemen ini tidak ditentukan, kebijakan akan menemukan nilai (secara default) dalam parameter formulir bernama username dan password. Jika nilai tidak ditemukan, kebijakan akan menampilkan error. Anda dapat menggunakan elemen <PassWord> dan <UserName> untuk mereferensikan variabel flow yang berisi kredensial.

Misalnya, Anda dapat meneruskan sandi dalam permintaan token menggunakan parameter kueri dan menyetel atribut seperti ini: <PassWord>request.queryparam.password</PassWord>. Hingga memerlukan sandi di header HTTP, tetapkan nilai ini ke request.header.password.

Kebijakan OAuthV2 tidak melakukan apa pun terhadap nilai kredensial ini; Apigee adalah yang memverifikasi keberadaan mereka. Terserah pengembang API untuk mengambil permintaan nilai dan mengirimkannya ke penyedia identitas sebelum kebijakan pembuatan token dijalankan.

Lihat juga Mendapatkan token OAuth 2.0.

Default:

request.formparam.password (x-www-form-urlencoding dan ditentukan dalam permintaan isi)

Kehadiran:

Opsional
Jenis: String
Nilai yang valid: Variabel alur apa pun yang tersedia untuk kebijakan saat runtime.
Digunakan dengan jenis pemberian izin: sandi

&lt;PrivateKey&gt;/&lt;Value&gt;

<PrivateKey>
  <Value ref="variable-name-here"/>
</PrivateKey>

Menyediakan kunci pribadi yang digunakan untuk memverifikasi atau menandatangani token akses berformat JWT dengan algoritma RSA. Gunakan atribut ref untuk meneruskan kunci dalam variabel flow. Gunakan hanya bila Nilai elemen Algorithm adalah salah satu dari RS256, RS384, atau RS512. Untuk informasi selengkapnya, lihat Menggunakan operasi token OAuth JWT.

Default T/A
Kehadiran Wajib jika nilai elemen Algorithm adalah salah satu dari HS256, HS384, atau HS512.
Jenis String
Nilai yang valid Variabel flow yang berisi string yang mewakili nilai kunci pribadi RSA berenkode PEM.

&lt;PublicKey&gt;/&lt;Value&gt;

<PublicKey>
   <Value ref="variable-name-here"/>
</PublicKey>

Menentukan kunci publik atau sertifikat publik yang digunakan untuk memverifikasi tanda tangan pada token akses berformat JWT yang ditandatangani dengan algoritma RSA. Gunakan atribut ref untuk meneruskan kunci/sertifikat dalam variabel flow. Gunakan hanya bila Nilai elemen Algorithm adalah salah satu dari RS256, RS384, atau RS512.

Default T/A
Kehadiran Untuk memverifikasi JWT yang ditandatangani dengan algoritma RSA, Anda harus menggunakan Sertifikat, JWKS, atau Elemen nilai.
Jenis String
Nilai yang valid Variabel aliran atau string.

&lt;RedirectUri&gt; elemen

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

Menentukan tempat Apigee harus mencari parameter redirect_uri di permintaan.

Tentang URI pengalihan

URI pengalihan digunakan dengan kode otorisasi dan jenis pemberian implisit. Pengalihan URI memberi tahu server otorisasi (Apigee) tujuan pengiriman kode otorisasi (untuk kode autentikasi jenis pemberian) atau token akses (untuk jenis pemberian implisit). Penting untuk dipahami kapan ini dilakukan parameter wajib diisi, kapan opsional, dan bagaimana parameter tersebut digunakan:

  • (wajib) Jika URL Callback terdaftar dengan aplikasi developer yang dikaitkan dengan kunci klien permintaan, dan jika redirect_uri ada dalam permintaan, maka keduanya harus sama persis. Jika tidak cocok, pesan error akan muncul. Untuk informasi tentang cara mendaftarkan aplikasi developer di Apigee dan menentukan URL Callback, lihat Mendaftarkan aplikasi dan mengelola API .

  • (opsional) Jika URL Callback terdaftar, dan redirect_uri tidak ada dari permintaan, kemudian Apigee mengalihkan ke URL Callback yang terdaftar.
  • (wajib) Jika URL Callback tidak terdaftar, berarti redirect_uri tidak diperlukan. Perlu diperhatikan bahwa dalam hal ini, Apigee akan menerima URL APA PUN. Kasus ini dapat menyajikan masalah keamanan, sehingga sebaiknya hanya gunakan dengan klien tepercaya aplikasi. Jika aplikasi klien tidak dipercaya, praktik terbaiknya adalah selalu mewajibkan pendaftaran URL Panggilan Balik.

Anda dapat mengirim parameter ini dalam parameter kueri atau dalam header. Tujuan variabel request.queryparam.redirect_uri menunjukkan bahwa RedirectUri harus ada sebagai parameter kueri, sebagaimana, untuk contoh, ?redirect_uri=login.myapp.com. Untuk mewajibkan RedirectUri di HTTP misalnya, tetapkan nilai ini ke request.header.redirect_uri. Lihat Dapatkan token OAuth 2.0.

Default:

request.formparam.redirect_uri (x-www-form-urlencoding dan ditentukan dalam permintaan isi)

Kehadiran:

Opsional
Jenis: String
Nilai yang valid: Variabel alur apa pun yang dapat diakses dalam kebijakan saat runtime
Digunakan dengan jenis pemberian izin:
  • authorization_code
  • implisit

Juga digunakan dengan operasi GenerateAuthorizationCode.

&lt;RefreshToken&gt; elemen

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

Saat meminta token akses menggunakan token refresh, Anda harus memberikan token refresh di terhadap permintaan. Elemen ini memungkinkan Anda menentukan tempat Apigee harus mencari token refresh. Sebagai misalnya, dapat dikirim sebagai parameter kueri, header HTTP, atau parameter formulir (default).

Variabel request.queryparam.refreshtoken menunjukkan bahwa pemuatan ulang token harus tersedia sebagai parameter kueri, misalnya untuk contoh, ?refresh_token=login.myapp.com. Untuk mewajibkan RefreshToken dalam HTTP misalnya, tetapkan nilai ini ke request.header.refresh_token. Lihat Dapatkan token OAuth 2.0.

Default:

request.formparam.refresh_token (x-www-form-urlencoding dan ditentukan dalam permintaan isi)

Kehadiran:

Opsional
Jenis: String
Nilai yang valid: Variabel alur apa pun yang dapat diakses dalam kebijakan saat runtime
Digunakan dengan jenis pemberian izin:
  • refresh_token

&lt;RefreshTokenExpiresIn&gt; elemen

<RefreshTokenExpiresIn>1000</RefreshTokenExpiresIn>

Menerapkan waktu habis masa berlaku token refresh dalam milidetik. Nilai waktu habis masa berlaku adalah nilai yang dihasilkan sistem ditambah nilai <RefreshTokenExpiresIn>. Jika <RefreshTokenExpiresIn> disetel ke -1, token refresh kedaluwarsa sesuai dengan OAuth maksimum akhir masa berlaku token refresh. Jika <RefreshTokenExpiresIn> tidak ditentukan, sistem akan menerapkan nilai {i>default<i}.

Waktu habis masa berlaku juga dapat disetel saat runtime menggunakan nilai default hard code atau dengan yang merujuk ke variabel flow. Misalnya, Anda dapat menyimpan nilai habis masa berlaku token di nilai kunci memetakan, mengambilnya, menetapkan variabel, dan mereferensikannya dalam kebijakan. Sebagai contoh, kvm.oauth.expires_in.

Stanza berikut menentukan variabel alur dan nilai default juga. Perhatikan bahwa alur nilai variabel lebih diprioritaskan daripada nilai default yang ditentukan.

<RefreshTokenExpiresIn ref="kvm.oauth.expires_in">
    86400000 <!--value in milliseconds-->
</RefreshTokenExpiresIn>

Default:

2592000000 md (30 hari) (berlaku 31 Mei 2023)

Kehadiran:

Opsional
Jenis: Bilangan bulat
Nilai yang valid:
  • Bilangan bulat positif apa pun, bukan nol. Menentukan waktu masa berlaku dalam milidetik.
  • -1 akan habis masa berlakunya sesuai masa berlaku token refresh OAuth maksimum.

    Catatan: Menentukan bilangan bulat negatif lainnya atau nol akan menyebabkan error deployment.
Digunakan dengan jenis pemberian izin:
  • authorization_code
  • sandi
  • refresh_token

&lt;ResponseType&gt; elemen

<ResponseType>request.queryparam.response_type</ResponseType>

Elemen ini memberi tahu Apigee jenis pemberian izin yang diminta aplikasi klien. Tabel ini hanya digunakan dengan alur kode otorisasi dan jenis pemberian implisit.

Secara default, Apigee mencari nilai jenis respons dalam kueri response_type . Jika Anda ingin mengganti perilaku default ini, gunakan <ResponseType> elemen ke mengonfigurasi variabel alur yang berisi nilai jenis respons. Misalnya, jika Anda menyetel ke request.header.response_type, Apigee mencari jenis respons yang yang diteruskan di header permintaan. Lihat juga Mendapatkan token OAuth 2.0.

Default:

request.formparam.response_type (x-www-form-urlencoding dan ditentukan dalam permintaan isi)

Kehadiran:

Opsional. Gunakan elemen ini jika Anda ingin mengganti perilaku default.

Jenis: String
Nilai yang valid: code (untuk jenis pemberian kode otorisasi) atau token (untuk jenis pemberian implisit)
Digunakan dengan jenis pemberian izin:
  • implisit
  • Juga digunakan dengan operasi GenerateAuthorizationCode.

&lt;ReuseRefreshToken&gt; elemen

<ReuseRefreshToken>true</ReuseRefreshToken>

Jika ditetapkan ke true, token refresh yang ada akan digunakan kembali hingga masa berlakunya habis. Jika false, token refresh baru akan dikeluarkan oleh Apigee saat token refresh yang valid disajikan.

Default:

false

Kehadiran:

opsional
Jenis: boolean
Nilai yang valid:

true atau false
Digunakan dengan jenis pemberian izin:
  • refresh_token

&lt;RFCCompliantRequestResponse&gt; elemen

<RFCCompliantRequestResponse>[true | false]</RFCCompliantRequestResponse>

Saat true, kebijakan akan mematuhi RFC6749 standar dan memungkinkan perilaku yang mematuhi kebijakan berikut:

  • Respons error dan non-error akan menyertakan respons Cache-Control HTTP kolom header untuk mematuhi RFC2616 (Hypertext Transfer Protocol -- HTTP/1.1), dengan nilai no-store dalam yang berisi token, kredensial, atau informasi sensitif lainnya, serta Kolom header respons Pragma dengan nilai no-cache.
  • Properti expires_in akan menggunakan format alfanumerik. Untuk konsistensi, refresh_token_expires_in juga akan berupa alfanumerik.
  • Respons OAuthV2 untuk pembuatan token, akan mencakup Bearer yang sesuai dengan RFC bidang header, alih-alih BearerToken.
  • Pesan error dalam payload respons akan memiliki format: {"error" : "xxx", "error_description" :"yyy"} untuk error token refresh.

Default:

false: Secara default, kebijakan ini mengizinkan perilaku tertentu yang tidak sesuai dengan RFC. Untuk mengetahui detailnya, lihat Perilaku yang tidak sesuai dengan RFC. Setel elemen ini ke true untuk mengaktifkan kepatuhan RFC.

Kehadiran:

Opsional
Jenis: Boolean
Nilai yang valid: true atau false
Digunakan dengan jenis pemberian izin: Semua

&lt;SecretKey&gt;/&lt;Value&gt;

<SecretKey>
  <Value ref="your-variable-name"/>
</SecretKey>

Menyediakan kunci rahasia yang digunakan untuk memverifikasi atau menandatangani token akses berformat JWT dengan algoritma HMAC. Hanya gunakan jika algoritmanya adalah salah satu dari HS256, HS384, atau HS512. Gunakan atribut ref untuk meneruskan kunci dalam variabel flow. Untuk informasi selengkapnya, lihat Menggunakan operasi token OAuth JWT.

Apigee menerapkan kekuatan kunci minimum untuk algoritma HS256/HS384/HS512. Panjang kunci minimum untuk HS256 adalah 32 byte, untuk HS384 adalah 48 byte, dan untuk HS512 adalah 64 byte. Menggunakan kunci dengan kekuatan yang lebih rendah akan menyebabkan error runtime.

Default T/A
Kehadiran Diperlukan untuk algoritma HMAC.
Jenis String
Nilai yang valid Variabel flow

&lt;Scope&gt; elemen

<Scope>request.queryparam.scope</Scope>

Jika elemen ini ada di salah satu GenerateAccessToken atau GenerateAuthorizationCode kebijakan, kebijakan digunakan untuk menentukan cakupan mana yang akan diberikan token atau kode. Nilai-nilai ini bersifat yang biasanya diteruskan ke kebijakan dalam permintaan dari aplikasi klien. Anda dapat mengkonfigurasi elemen ini untuk mengambil variabel alur, yang memberi Anda opsi untuk memilih cara cakupan diteruskan dalam permintaan. Di beberapa contoh berikut, request.queryparam.scope menunjukkan bahwa cakupan harus ada sebagai parameter kueri, misalnya, ?scope=READ. Untuk mewajibkan di header HTTP, misalnya, tetapkan nilai ini ke request.header.scope.

Jika elemen ini muncul dalam "VerifyAccessToken" , maka digunakan untuk menentukan cakupan yang harus diterapkan oleh kebijakan tersebut. Dalam jenis kebijakan ini, nilai harus berupa "hard code" ruang lingkup Anda tidak dapat menggunakan variabel. Contoh:

<Scope>A B</Scope>

Lihat juga Bekerja dengan OAuth2 dan Dapatkan token OAuth 2.0.

Default:

Tidak ada cakupan

Kehadiran:

Opsional
Jenis: String
Nilai yang valid:

Jika digunakan dengan kebijakan Buat*, variabel flow.

Jika digunakan dengan VerifyAccessToken, daftar nama cakupan (string) yang dipisahkan spasi.
Digunakan dengan jenis pemberian izin:
  • authorization_code
  • implisit
  • sandi
  • client_credentials
  • Juga dapat digunakan dengan GenerateAuthorizationCode dan VerifyAccessToken operasional bisnis.

&lt;State&gt; elemen

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

Dalam kasus di mana aplikasi klien harus mengirimkan informasi status ke server otorisasi, Anda dapat menentukan di mana Apigee harus mencari nilai status. Misalnya, dapat dikirim sebagai parameter kueri atau dalam header HTTP. Nilai status biasanya digunakan sebagai keamanan untuk mencegah serangan CSRF.

Misalnya, request.queryparam.state menunjukkan bahwa status harus ada sebagai parameter kueri, misalnya, ?state=HjoiuKJH32. Untuk mewajibkan status dalam header HTTP, misalnya, tetapkan nilai ini ke request.header.state. Lihat juga Lihat juga Mendapatkan token OAuth 2.0.

Default:

Tanpa status

Kehadiran:

Opsional
Jenis: String
Nilai yang valid: Variabel alur apa pun yang dapat diakses oleh kebijakan saat runtime
Digunakan dengan jenis pemberian izin:
  • Semua
  • Juga dapat digunakan dengan operasi GenerateAuthorizationCode

&lt;StoreToken&gt; elemen

 <StoreToken>true</StoreToken>

Setel elemen ini ke true saat <ExternalAuthorization> adalah true. Elemen <StoreToken> memberi tahu Apigee untuk untuk menyimpan token akses eksternal. Jika tidak, peristiwa tersebut tidak akan dipertahankan.

Default:

salah

Kehadiran:

Opsional
Jenis: Boolean
Nilai yang valid: benar atau salah
Digunakan dengan jenis pemberian izin:
  • authorization_code
  • sandi
  • client_credentials

&lt;SupportedGrantTypes&gt;/&lt;GrantType&gt; elemen

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

Menentukan jenis pemberian yang didukung oleh endpoint token OAuth di Apigee. Endpoint mungkin mendukung beberapa jenis pemberian izin (yaitu, satu endpoint dapat dikonfigurasi untuk mendistribusikan akses token untuk beberapa jenis pemberian izin.) Untuk informasi selengkapnya tentang endpoint, lihat Memahami OAuth endpoint. Jenis pemberian ini diteruskan dalam permintaan token di grant_type .

Jika tidak ada jenis pemberian yang didukung, maka satu-satunya jenis pemberian yang diizinkan adalah authorization_code dan implicit. Lihat juga elemen &lt;GrantType&gt; (yang merupakan elemen tingkat lebih tinggi yang digunakan menentukan di mana Apigee harus mencari parameter grant_type yang diteruskan terhadap permintaan klien. Apigee akan memastikan bahwa nilai parameter grant_type cocok dengan salah satu jenis pemberian yang didukung).

Default:

otorisasi _code dan implisit

Kehadiran:

Wajib
Jenis: String
Nilai yang valid:
  • client_credentials
  • authorization_code
  • sandi
  • implisit

&lt;Tokens&gt;/&lt;Token&gt; elemen

Digunakan dengan operasi ValidateToken dan InvalidateToken. Lihat juga Menyetujui dan mencabut token akses. <Token> mengidentifikasi variabel alur yang mendefinisikan sumber token yang akan dicabut. Jika developer diharapkan untuk mengirimkan token akses sebagai parameter kueri bernama access_token, misalnya, gunakan request.queryparam.access_token.

&lt;UserName&gt; elemen

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

Elemen ini digunakan dengan jenis pemberian sandi saja. Dengan jenis pemberian sandi, kredensial pengguna (sandi dan nama pengguna) harus disediakan untuk kebijakan OAuthV2. Elemen <PassWord> dan <UserName> digunakan untuk menentukan variabel di mana Apigee dapat menemukan nilai ini. Jika elemen-elemen ini tidak ditentukan, kebijakan mengharapkan menemukan nilai (secara default) dalam parameter formulir bernama username dan password. Jika nilai tidak ditemukan, kebijakan akan menampilkan error. Anda dapat menggunakan elemen <PassWord> dan <UserName> untuk mereferensikan variabel flow yang berisi kredensial.

Misalnya, Anda dapat meneruskan nama pengguna dalam parameter kueri dan menyetel atribut <UserName> seperti ini: <UserName>request.queryparam.username</UserName>.Untuk mewajibkan nama pengguna di header HTTP, tetapkan nilai ini ke request.header.username.

Kebijakan OAuthV2 tidak melakukan apa pun terhadap nilai kredensial ini; Apigee adalah yang memverifikasi keberadaan mereka. Terserah pengembang API untuk mengambil permintaan nilai dan mengirimkannya ke penyedia identitas sebelum kebijakan pembuatan token dijalankan.

Lihat juga Mendapatkan token OAuth 2.0.

Default:

request.formparam.username (x-www-form-url berandadienkode dan ditentukan dalam permintaan isi)

Kehadiran:

Opsional
Jenis: String
Nilai yang valid: Setelan variabel apa pun.
Digunakan dengan jenis pemberian izin: sandi

Memverifikasi akses token

Setelah endpoint token disiapkan untuk proxy API, kebijakan OAuthV2 terkait yang menentukan operasi VerifyAccessToken yang dikaitkan ke Flow yang mengekspos resource yang dilindungi.

Misalnya, untuk memastikan bahwa semua permintaan ke API telah diotorisasi, kebijakan berikut menerapkan verifikasi token akses:

<OAuthV2 name="VerifyOAuthAccessToken">
  <Operation>VerifyAccessToken</Operation>
</OAuthV2>

Kebijakan ini dilampirkan ke resource API yang akan dilindungi. Untuk memastikan bahwa semua permintaan ke API telah diverifikasi, lampirkan kebijakan ke PreFlow permintaan ProxyEndpoint, sebagai berikut:

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

Elemen opsional berikut bisa digunakan untuk mengganti pengaturan {i>default<i} untuk Operasi VerifyAccessToken.

Nama Deskripsi
Cakupan

Daftar cakupan yang dipisahkan spasi. Verifikasi akan berhasil jika setidaknya salah satu dari cakupan yang tercantum ada dalam token akses. Misalnya, kebijakan berikut akan memeriksa token akses untuk memastikan bahwa token tersebut berisi setidaknya salah satu cakupan yang tercantum. Jika Ada READ atau WRITE, verifikasi akan berhasil.

<OAuthV2 name="ValidateOauthScopePolicy">
  <Operation>VerifyAccessToken</Operation>
  <Scope>READ WRITE</Scope>
</OAuthV2>
AccessToken Variabel tempat token akses diharapkan berada. Misalnya request.queryparam.accesstoken. Secara {i>default<i}, token akses diharapkan yang ditampilkan oleh aplikasi di header HTTP Otorisasi, sesuai dengan spesifikasi OAuth 2.0. Gunakan ini jika token akses diperkirakan akan ditampilkan di lokasi non-standar, seperti parameter kueri, atau header HTTP dengan nama selain Otorisasi.

Lihat juga Memverifikasi akses token dan Dapatkan token OAuth 2.0.

Menentukan lokasi variabel permintaan

Untuk setiap jenis pemberian izin, kebijakan membuat asumsi tentang lokasi atau informasi yang diperlukan dalam pesan permintaan. Asumsi tersebut didasarkan pada spesifikasi OAuth 2.0. Jika aplikasi Anda tidak sesuai dengan spesifikasi OAuth 2.0, maka Anda dapat menentukan lokasi yang diharapkan untuk setiap parameter. Misalnya, saat menangani kode otorisasi, Anda dapat menentukan lokasi kode otorisasi, ID klien, URI pengalihan, dan cakupan. Hal ini dapat ditentukan sebagai Header HTTP, parameter kueri, atau parameter formulir.

Contoh di bawah menunjukkan cara menentukan lokasi kode otorisasi yang diperlukan parameter sebagai header HTTP:

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

Atau, jika diperlukan untuk mendukung basis aplikasi klien, Anda dapat memadupadankan header dan kueri parameter:

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

Hanya satu lokasi yang dapat dikonfigurasi per parameter.

Variabel flow

Variabel alur yang ditentukan dalam tabel ini akan diisi saat kebijakan OAuth terkait dieksekusi, sehingga tersedia untuk kebijakan atau aplikasi lain yang dieksekusi di proxy API alur kerja.

Operasi VerifyAccessToken

Saat operasi VerifyAccessToken dijalankan, sejumlah besar variabel alur akan diisi dalam konteks eksekusi proxy. Variabel ini memberi Anda properti yang terkait dengan akses token, aplikasi developer, dan developer. Anda dapat menggunakan kebijakan Menetapkan Pesan atau JavaScript, misalnya, untuk membaca salah satu variabel ini dan menggunakannya sesuai kebutuhan nanti dalam alur. Ini variabel juga dapat berguna untuk tujuan proses debug.

Variabel khusus token

Variabel Deskripsi
organization_name Nama organisasi tempat proxy dijalankan.
developer.id ID developer atau AppGroup terkait dengan aplikasi klien yang terdaftar.
developer.app.name Nama pengembang atau AppGroup aplikasi yang terkait dengan aplikasi klien yang terdaftar.
client_id Client ID aplikasi klien yang terdaftar.
grant_type Jenis pemberian yang terkait dengan permintaan. Tidak didukung untuk operasi VerifyJWTAccessToken.
token_type Jenis token yang terkait dengan permintaan.
access_token Token akses yang sedang diverifikasi.
accesstoken.{custom_attribute} Atribut khusus bernama dalam token akses.
issued_at Tanggal penerbitan token akses yang dinyatakan dalam Unix waktu epoch dalam milidetik.
expires_in Waktu habis masa berlaku token akses. Dinyatakan dalam detik. Meskipun ExpiresIn menetapkan kedaluwarsa dalam milidetik, dalam respons token, dan variabel aliran, nilai diekspresikan dalam detik.
status Status token akses (misalnya, disetujui atau dicabut).
scope Cakupan (jika ada) yang terkait dengan token akses.
apiproduct.<custom_attribute_name> Atribut khusus bernama dari produk API yang terkait dengan klien terdaftar .
apiproduct.name Nama produk API yang terkait dengan aplikasi klien yang terdaftar.
revoke_reason

(Khusus Apigee Hybrid) Menunjukkan alasan token akses dicabut. Tidak didukung untuk operasi VerifyJWTAccessToken.

Nilai dapat berupa REVOKED_BY_APP, REVOKED_BY_ENDUSER, REVOKED_BY_APP_ENDUSER, atau TOKEN_REVOKED.

Variabel khusus aplikasi

Variabel ini terkait dengan Aplikasi Developer yang terkait dengan token.

Variabel Deskripsi
app.name
app.id
app.accessType
app.callbackUrl
app.status disetujui atau dicabut
app.scopes
app.appFamily
app.apiproducts
app.appParentStatus
app.appType Misalnya: Developer
app.appParentId
app.created_by
app.created_at
app.last_modified_at
app.last_modified_by
app.{custom_attributes} Atribut khusus bernama dari aplikasi klien terdaftar.

Variabel khusus AppGroup

Variabel alur berikut yang berisi informasi tentang AppGroup untuk token dan diisi oleh kebijakan. Atribut AppGroup ini hanya terisi jika verifyapikey.{policy_name}.app.appType adalah "AppGroup".

Variabel Deskripsi
appgroup.displayName Nama tampilan AppGroup.
appgroup.name Nama AppGroup.
appgroup.id AppGroup ID.
appOwnerStatus Status pemilik aplikasi: 'active', 'inactive', atau 'login_lock'.
created_at Stempel tanggal/waktu saat AppGroup dibuat.
created_by Alamat email developer yang membuat AppGroup.
last_modified_at Stempel tanggal/waktu saat AppGroup terakhir diubah.
last_modified_by Alamat email developer yang terakhir kali mengubah AppGroup.
{appgroup_custom_attributes} Atribut AppGroup kustom apa pun. Tentukan nama atribut khusus.

Variabel khusus developer

Jika app.appType adalah "Developer", lalu atribut developer akan diisi.

Variabel Deskripsi
Variabel khusus developer
developer.id
developer.userName
developer.firstName
developer.lastName
developer.email
developer.status aktif atau tidak aktif
developer.apps
developer.created_by
developer.created_at
developer.last_modified_at
developer.last_modified_by
developer.{custom_attributes} Atribut khusus bernama dari developer.

GenerateAuthorizationCode operasi

Variabel ini ditetapkan saat operasi GenerateAuthorizationCode dijalankan berhasil:

Awalan: oauthv2authcode.{policy_name}.{variable_name}

Contoh: oauthv2authcode.GenerateCodePolicy.code

Variabel Deskripsi
code Kode otorisasi yang dibuat saat kebijakan dijalankan.
redirect_uri URI pengalihan yang terkait dengan aplikasi klien yang terdaftar.
scope Cakupan OAuth opsional yang diteruskan di permintaan klien.
client_id Client ID yang diteruskan dalam permintaan klien.

GenerateAccessToken dan Operasi RefreshAccessToken

Variabel ini ditetapkan ketika operasi GenerateAccessToken dan RefreshAccessToken dieksekusi memulai proyek. Perhatikan bahwa variabel token refresh tidak berlaku untuk pemberian kredensial klien {i>type flow<i} (alur jenis).

Awalan: oauthv2accesstoken.{policy_name}.{variable_name}

Contoh: oauthv2accesstoken.GenerateTokenPolicy.access_token

Nama variabel Deskripsi
access_token Token akses yang dibuat.
client_id Client ID aplikasi developer yang terkait dengan token ini.
expires_in Nilai masa berlaku token. Lihat &lt;ExpiresIn&gt; untuk detailnya. Perhatikan bahwa dalam respons, expires_in dinyatakan dalam detik.
scope Daftar cakupan yang tersedia yang dikonfigurasi untuk token. Lihat Menggunakan cakupan OAuth2.
status Berupa approved atau revoked.
token_type Ditetapkan ke BearerToken.
developer.email Alamat email developer terdaftar yang memiliki aplikasi developer yang terkait dengan token.
organization_name Organisasi tempat proxy dieksekusi.
api_product_list Daftar produk yang terkait dengan aplikasi developer yang sesuai dengan token.
refresh_count
refresh_token Token refresh yang dibuat. Perhatikan bahwa token refresh tidak dibuat untuk jenis pemberian kredensial klien.
refresh_token_expires_in Masa pakai token refresh, dalam detik.
refresh_token_issued_at Nilai waktu ini adalah representasi string dari stempel waktu 32-bit yang sesuai kuantitas. Misalnya, 'Rab, 21 Agustus 2013 19:16:47 UTC' sesuai dengan nilai stempel waktu dari 1377112607413.
refresh_token_status Berupa approved atau revoked.

GenerateAccessTokenImplicitGrant

Variabel ini ditetapkan saat operasi GenerateAccessTokenImplicit berhasil dijalankan untuk alur jenis pemberian implisit.

Awalan: oauthv2accesstoken.{policy_name}.{variable_name}

Contoh: oauthv2accesstoken.RefreshTokenPolicy.access_token

Variabel Deskripsi
oauthv2accesstoken.access_token Token akses yang dibuat saat kebijakan dijalankan.
oauthv2accesstoken.{policy_name}.expires_in Nilai masa berlaku token, dalam detik. Lihat elemen &lt;ExpiresIn&gt; untuk detailnya.

Referensi error

Bagian ini menjelaskan kode error dan pesan error yang ditampilkan serta variabel error yang ditetapkan oleh Apigee saat kebijakan ini memicu error. Informasi ini penting untuk diketahui jika Anda mengembangkan aturan error untuk menangani error. Untuk mempelajari lebih lanjut, lihat Yang perlu Anda ketahui tentang error kebijakan dan Menangani error.

Error runtime

Error ini dapat terjadi saat kebijakan dijalankan.

Kode kerusakan Status HTTP Penyebab Ditampilkan oleh operasi
steps.oauth.v2.access_token_expired 401 Masa berlaku token akses telah berakhir.

VerifyAccessToken
InvalidateToken
steps.oauth.v2.access_token_not_approved 401 Token akses telah dicabut. VerifyAccessToken
steps.oauth.v2.apiresource_doesnot_exist 401 Resource yang diminta tidak ada produk API yang terkait dengan token akses. VerifyAccessToken
steps.oauth.v2.FailedToResolveAccessToken 500 Kebijakan diharapkan menemukan token akses dalam variabel yang ditentukan dalam elemen <AccessToken>, tetapi variabel tersebut tidak dapat di-resolve. GenerateAccessToken
steps.oauth.v2.FailedToResolveAuthorizationCode 500 Kebijakan diharapkan menemukan kode otorisasi dalam variabel yang ditentukan dalam elemen <Code>, tetapi variabel tersebut tidak dapat di-resolve. GenerateAuthorizationCode
steps.oauth.v2.FailedToResolveClientId 500 Kebijakan diharapkan menemukan Client ID dalam variabel yang ditentukan dalam elemen <ClientId>, tetapi variabel tersebut tidak dapat di-resolve. GenerateAccessToken
GenerateAuthorizationCode
GenerateAccessTokenImplicitGrant
RefreshAccessToken
steps.oauth.v2.FailedToResolveRefreshToken 500 Kebijakan diharapkan menemukan token refresh dalam variabel yang ditentukan dalam elemen <RefreshToken>, tetapi variabel tersebut tidak dapat di-resolve. RefreshAccessToken
steps.oauth.v2.FailedToResolveToken 500 Kebijakan diharapkan menemukan token dalam variabel yang ditentukan dalam elemen <Tokens>, tetapi variabel tidak dapat di-resolve.

ValidateToken
InvalidateToken
steps.oauth.v2.InsufficientScope 403 Token akses yang ditampilkan dalam permintaan memiliki cakupan yang tidak cocok dengan cakupan yang ditentukan dalam kebijakan token akses verifikasi. Untuk mempelajari cakupan, lihat Menggunakan cakupan OAuth2. VerifyAccessToken
steps.oauth.v2.invalid_access_token 401 Token akses yang dikirim dari klien tidak valid. VerifyAccessToken
steps.oauth.v2.invalid_client 401

Nama error ini ditampilkan saat properti <GenerateResponse> kebijakan ditetapkan ke true dan client ID yang dikirim dalam permintaan tidak valid. Periksa untuk memastikan Anda menggunakan kunci klien dan nilai rahasia yang benar untuk Aplikasi Developer yang terkait dengan proxy Anda. Biasanya, nilai ini dikirim sebagai header Basic Authorization yang dienkode Base64.

 GenerateAccessToken
RefreshAccessToken
steps.oauth.v2.invalid_request 400 Nama error ini digunakan untuk beberapa jenis error, biasanya untuk parameter yang tidak ada atau salah yang dikirim dalam permintaan. Jika <GenerateResponse> ditetapkan ke false, gunakan variabel error (dijelaskan di bawah) untuk mengambil detail tentang error, seperti nama dan penyebab error. GenerateAccessToken
GenerateAuthorizationCode
GenerateAccessTokenImplicitGrant
RefreshAccessToken
steps.oauth.v2.InvalidAccessToken 401 Header otorisasi tidak memiliki kata Bearer, yang diperlukan. Misalnya: Authorization: Bearer your_access_token VerifyAccessToken
steps.oauth.v2.InvalidAPICallAsNo\
ApiProductMatchFound		 401

Proxy atau operasi API yang sedang dijalankan tidak ada dalam Produk yang terkait dengan token akses.

Tips: Pastikan produk yang terkait dengan token akses dikonfigurasi dengan benar. Misalnya, jika Anda menggunakan karakter pengganti di jalur resource, pastikan karakter pengganti digunakan dengan benar. Lihat Mengelola produk API untuk mengetahui detailnya.

Lihat juga Verifikasi Token Akses Oauth2.0 menampilkan error "Panggilan API tidak valid karena tidak ada kecocokan apiproduct" untuk panduan selengkapnya tentang penyebab error ini.

 VerifyAccessToken
steps.oauth.v2.InvalidClientIdentifier 500

Nama error ini ditampilkan saat properti <GenerateResponse> kebijakan ditetapkan ke false dan client ID yang dikirim dalam permintaan tidak valid. Periksa untuk memastikan Anda menggunakan kunci klien dan nilai rahasia yang benar untuk Aplikasi Developer yang terkait dengan proxy Anda. Biasanya, nilai ini dikirim sebagai header Basic Authorization berenkode Base64.

GenerateAccessToken
RefreshAccessToken
steps.oauth.v2.InvalidParameter 500 Kebijakan harus menentukan token akses atau kode otorisasi, tetapi tidak keduanya. GenerateAuthorizationCode
GenerateAccessTokenImplicitGrant
steps.oauth.v2.InvalidTokenType 500 Elemen <Tokens>/<Token> mengharuskan Anda menentukan jenis token (misalnya, refreshtoken). Jika klien meneruskan jenis yang salah, error ini akan ditampilkan. ValidateToken
InvalidateToken
steps.oauth.v2.MissingParameter 500 Jenis respons adalah token, tetapi tidak ada jenis pemberian yang ditentukan. GenerateAuthorizationCode
GenerateAccessTokenImplicitGrant
steps.oauth.v2.UnSupportedGrantType 500

Klien menentukan jenis hibah yang tidak didukung oleh kebijakan (tidak tercantum dalam elemen <SupportedGrantTypes>).

 GenerateAccessToken
GenerateAuthorizationCode
GenerateAccessTokenImplicitGrant
RefreshAccessToken

Error runtime khusus token JWT

Kode dan deskripsi error runtime untuk alur token autentikasi JWT bergantung pada konteks alur OAuth2:

Kode error untuk alur pembuatan dan pembaruan token JWT

Untuk alur OAuth2 yang membuat atau memperbarui token JWT, respons error mematuhi respons error yang ditentukan dalam RFC6749. Untuk mengetahui detailnya, lihat Bagian 5.2 Respons Error.

Kode error untuk alur verifikasi token

Kode error yang tercantum dalam tabel berikut hanya berlaku untuk operasi VerifyAccessToken.

Kode kerusakan Status HTTP Penyebab Ditampilkan oleh operasi
oauth.v2.JWTSigningFailed 401 Kebijakan tidak dapat menandatangani JWT.

GenerateJWTAccessToken
oauth.v2.InvalidValueForJWTAlgorithm 401 Hal ini terjadi jika algoritma tidak ada di token akses JWT atau jika nilai tidak didukung.

GenerateJWTAccessToken
VerifyJWTAccessToken

oauth.v2.InsufficientKeyLength 401 Dalam Pembuatan JWT, untuk kunci yang kurang dari ukuran minimum untuk algoritma HS384 atau HS512

GenerateJWTAccessToken
VerifyJWTAccessToken

oauth.v2.JWTAlgorithmMismatch 401 Algoritma yang ditentukan dalam kebijakan Buat tidak cocok dengan algoritma yang diharapkan dalam kebijakan Verifikasi. Algoritma yang ditentukan harus cocok.

VerifyJWTAccessToken
oauth.v2.JWTDecodingFailed 401 Kebijakan tidak dapat mendekode JWT. JWT mungkin rusak.

VerifyJWTAccessToken
oauth.v2.MissingMandatoryClaimsInJWT 401 Terjadi saat klaim yang diperlukan tidak ada di Token Akses Jwt

VerifyJWTAccessToken
oauth.v2.InvalidJWTSignature 401 Hal ini terjadi jika tanda tangan token akses JWT tidak dapat diverifikasi atau jika tanda tangan tidak valid.

VerifyJWTAccessToken
oauth.v2.InvalidTypeInJWTHeader 401 Terjadi saat jenis JWT bukan at+Jwt

VerifyJWTAccessToken

Error saat deployment

Error ini dapat terjadi saat Anda men-deploy proxy yang berisi kebijakan ini.

Nama error Penyebab
InvalidValueForExpiresIn

Untuk elemen <ExpiresIn>, nilai yang valid adalah bilangan bulat positif dan -1.
InvalidValueForRefreshTokenExpiresIn Untuk elemen <RefreshTokenExpiresIn>, nilai yang valid adalah bilangan bulat positif dan -1.
InvalidGrantType Jenis pemberian yang tidak valid ditentukan di elemen <SupportedGrantTypes>. Lihat referensi kebijakan untuk mengetahui daftar jenis yang valid.
ExpiresInNotApplicableForOperation Pastikan operasi yang ditentukan dalam elemen <Operations> mendukung masa berlaku. Misalnya, operasi VerifyToken tidak.
RefreshTokenExpiresInNotApplicableForOperation Pastikan operasi yang ditentukan dalam elemen <Operations> mendukung masa berlaku token refresh. Misalnya, operasi VerifyToken tidak.
GrantTypesNotApplicableForOperation Pastikan jenis hibah yang ditentukan di <SupportedGrantTypes> didukung untuk operasi yang ditentukan.
OperationRequired

Anda harus menentukan operasi dalam kebijakan ini menggunakan elemen <Operation>.
InvalidOperation

Anda harus menentukan operasi yang valid dalam kebijakan ini menggunakan elemen <Operation>.
TokenValueRequired Anda harus menentukan nilai <Token> token dalam elemen <Tokens>.

Error deployment khusus token JWT

Error deployment ini khusus untuk kebijakan yang menggunakan operasi token JWT.

Nama error Penyebab
InvalidValueForAlgorithm Algoritma yang ditentukan dalam elemen <Algorithm> tidak ada dalam daftar algoritma yang tersedia atau tidak ada.
MissingKeyConfiguration Elemen <SecretKey>, <PrivateKey>, atau <PublicKey> yang diperlukan tidak ada, bergantung pada algoritma yang digunakan.
EmptyValueElementForKeyConfiguration Elemen turunan <Value> yang diperlukan tidak ditentukan dalam elemen <PrivateKey>, <PublicKey>, atau <SecretKey>
InvalidKeyConfiguration Elemen <PrivateKey> tidak digunakan dengan algoritma keluarga RSA atau elemen <SecretKey> tidak digunakan dengan algoritma Keluarga HS.
EmptyRefAttributeForKeyconfiguration Atribut ref dari elemen turunan <Value> dari elemen <PrivateKey>, <PublicKey>, atau <SecretKey> kosong.
InvalidVariableNameForKey Nama variabel alur yang ditentukan dalam atribut ref dari elemen turunan <Value> dari elemen <PrivateKey>, <PublicKey>, atau <SecretKey> tidak berisi awalan private.

Variabel error

Variabel ini ditetapkan saat kebijakan ini memicu error saat runtime.

Variabel Dari mana Contoh
fault.name="fault_name" fault_name adalah nama error, seperti yang tercantum dalam tabel Runtime errors di atas. Nama kerusakan adalah bagian terakhir dari kode kerusakan. fault.name = "invalid_request"
oauthV2.policy_name.failed policy_name adalah nama kebijakan yang ditentukan pengguna yang menampilkan error. oauthV2.GenerateAccesstoken.failed = true
oauthV2.policy_name.fault.name policy_name adalah nama kebijakan yang ditentukan pengguna yang menampilkan error. oauthV2.GenerateAccesstoken.fault.name = invalid_request
oauthV2.policy_name.fault.cause policy_name adalah nama kebijakan yang ditentukan pengguna yang menampilkan error. oauthV2.GenerateAccesstoken.cause = Required param : grant_type

Contoh respons error

Respons ini dikirim kembali ke klien jika elemen <GenerateResponse> bernilai true.

Jika <GenerateResponse> true, kebijakan akan menampilkan error dalam format ini untuk operasi yang menghasilkan token dan kode. Untuk mengetahui daftar lengkapnya, lihat Referensi respons error HTTP OAuth.

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

Jika <GenerateResponse> true, kebijakan akan menampilkan error dalam format ini untuk operasi verifikasi dan validasi. Untuk mengetahui daftar lengkapnya, lihat referensi respons error HTTP OAuth.

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

Contoh aturan error

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

Token di Storage Di-hash

Jika Anda menggunakan Apigee Hybrid atau Apigee, token akses OAuthV2 dan token refresh di-hash secara default saat disimpan dalam database Cassandra runtime. {i>Hashing<i} mencegah token digunakan jika {i>database<i} disusupi.

Bekerja dengan OAuth default konfigurasi

Setiap organisasi (bahkan organisasi uji coba gratis) di Apigee disediakan dengan token OAuth endpoint. Endpoint telah dikonfigurasi sebelumnya dengan kebijakan di proxy API yang disebut oauth. Anda dapat mulai menggunakan endpoint token segera setelah Anda membuat akun di Apigee. Sebagai detail, lihat Memahami OAuth endpoint.

Menghapus token akses

Secara default, token OAuth2 dihapus dari sistem Apigee selama 3 hari (259.200 detik) setelah masa berlaku token akses dan token pembaruan (jika ada).

Perilaku yang tidak sesuai dengan RFC

Secara {i>default<i}, kebijakan OAuthV2, dengan operasi GenerateAccessToken, menampilkan respons token yang berisi properti tertentu yang tidak sesuai dengan RFC. Tabel berikut menunjukkan konten yang tidak mematuhi kebijakan properti yang ditampilkan oleh kebijakan OAuthV2 dan properti yang sesuai dan terkait.

OAuthV2 akan menampilkan: Properti yang sesuai dengan RFC adalah:
"token_type":"BearerToken" "token_type":"Bearer"
"expires_in":"3600" "expires_in":3600

(Nilai yang sesuai adalah angka, bukan string.)

Selain itu, respons error untuk token refresh yang masa berlakunya sudah berakhir saat grant_type = refresh_token:

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

Namun, respons yang sesuai dengan RFC adalah: 

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

Topik terkait