Halaman ini berlaku untuk Apigee dan Apigee hybrid.
Lihat Dokumentasi Apigee Edge.
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 Atau, gunakan elemen |
T/A | Diperlukan |
continueOnError |
Setel ke Setel ke |
false | Opsional |
enabled |
Setel ke Setel ke |
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 |
---|---|
Kehadiran | Opsional |
Jenis | String |
<AccessToken> 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: |
|
<AccessTokenPrefix> 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: |
|
<Algorithm>
<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 |
<AppEndUser> 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: |
|
<Attributes/Attribute>
<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: |
|
Kehadiran: |
Opsional |
Nilai yang valid: |
|
Digunakan dengan jenis pemberian izin: |
|
<CacheExpiryInSeconds> 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 |
<ClientId> 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: |
Juga dapat digunakan dengan operasi GenerateAuthorizationCode. |
<Code> 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 |
<ExpiresIn> 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: |
|
Digunakan dengan jenis pemberian izin: |
Juga digunakan dengan operasi GenerateAuthorizationCode. |
<ExternalAccessToken> 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.
<ExternalAuthorization> 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: |
|
<ExternalAuthorizationCode> 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.
<ExternalRefreshToken> 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.
<GenerateResponse> 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: |
|
<GenerateErrorResponse> 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: |
|
<GrantType>
<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: |
|
<Operation> elemen
<Operation>GenerateAuthorizationCode</Operation>
Operasi OAuth 2.0 yang dijalankan oleh kebijakan.
Default: |
Jika |
Kehadiran: |
Opsional |
Jenis: | String |
Nilai yang valid: |
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:
|
<PassWord> 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 |
<PrivateKey>/<Value>
<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. |
<PublicKey>/<Value>
<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. |
<RedirectUri> 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: |
Juga digunakan dengan operasi GenerateAuthorizationCode. |
<RefreshToken> 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: |
|
<RefreshTokenExpiresIn> 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: |
|
Digunakan dengan jenis pemberian izin: |
|
<ResponseType> 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: |
|
<ReuseRefreshToken> 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: |
|
Kehadiran: |
opsional |
Jenis: | boolean |
Nilai yang valid: |
|
Digunakan dengan jenis pemberian izin: |
|
<RFCCompliantRequestResponse> 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 nilaino-store
dalam yang berisi token, kredensial, atau informasi sensitif lainnya, serta Kolom header responsPragma
dengan nilaino-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-alihBearerToken
. - Pesan error dalam payload respons akan memiliki format:
{"error" : "xxx", "error_description" :"yyy"}
untuk error token refresh.
Default: |
|
Kehadiran: |
Opsional |
Jenis: | Boolean |
Nilai yang valid: | true atau false |
Digunakan dengan jenis pemberian izin: | Semua |
<SecretKey>/<Value>
<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 |
<Scope> 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: |
|
<State> 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: |
|
<StoreToken> 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: |
|
<SupportedGrantTypes>/<GrantType> 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 <GrantType> (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: |
|
<Tokens>/<Token> 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
.
<UserName> 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 Nilai dapat berupa |
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 <ExpiresIn> 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 <ExpiresIn> untuk detailnya. |
Referensi error
Bagian ini menjelaskan kode kesalahan dan pesan error yang ditampilkan dan variabel kesalahan yang disetel oleh Apigee saat kebijakan ini memicu error. Informasi ini penting untuk diketahui apakah Anda mengembangkan aturan kesalahan untuk menangani kesalahan. Untuk mempelajari lebih lanjut, lihat Yang perlu Anda ketahui tentang error kebijakan dan Menangani kesalahan.
Error runtime
Error ini dapat terjadi saat kebijakan dieksekusi.
Kode kesalahan | Status HTTP | Penyebab | Dilempar oleh operasi |
---|---|---|---|
steps.oauth.v2.access_token_expired |
401 |
Masa berlaku token akses telah berakhir. |
|
steps.oauth.v2.access_token_not_approved |
401 |
Token akses dicabut. | VerifyAccessToken |
steps.oauth.v2.apiresource_doesnot_exist |
401 |
Resource yang diminta tidak ada produk API apa pun yang terkait dengan token akses. | VerifyAccessToken |
steps.oauth.v2.FailedToResolveAccessToken |
500 |
Kebijakan diharapkan dapat menemukan token akses dalam variabel yang ditentukan dalam elemen <AccessToken> , tetapi variabel tersebut tidak dapat di-resolve. |
GenerateAccessToken |
steps.oauth.v2.FailedToResolveAuthorizationCode |
500 |
Kebijakan ini seharusnya menemukan kode otorisasi dalam variabel yang ditentukan dalam elemen <Code> , tetapi variabel tersebut tidak dapat di-resolve. |
GenerateAuthorizationCode |
steps.oauth.v2.FailedToResolveClientId |
500 |
Kebijakan ini diharapkan dapat 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 ini 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 tersebut tidak dapat di-resolve. |
|
steps.oauth.v2.InsufficientScope |
403 | Token akses yang ditampilkan dalam permintaan memiliki cakupan yang tidak cocok dengan cakupan yang ditentukan dalam kebijakan verifikasi token akses. 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 jika properti |
GenerateAccessToken RefreshAccessToken |
steps.oauth.v2.invalid_request |
400 | Nama error ini digunakan untuk berbagai jenis error, biasanya untuk parameter yang tidak ada
atau salah yang dikirim dalam permintaan. Jika <GenerateResponse> ditetapkan ke false , gunakan variabel kesalahan (yang dijelaskan di bawah) untuk mengambil detail error, seperti nama dan penyebab kesalahan. |
GenerateAccessToken GenerateAuthorizationCode GenerateAccessTokenImplicitGrant RefreshAccessToken |
steps.oauth.v2.InvalidAccessToken |
401 |
Header otorisasi tidak memiliki kata Bearer , yang diperlukan. Sebagai
contoh: Authorization: Bearer your_access_token |
VerifyAccessToken |
steps.oauth.v2.InvalidAPICallAsNo\ |
401 |
Operasi atau proxy 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 tersebut digunakan dengan benar. Lihat Mengelola produk API untuk detailnya. Lihat juga Verifikasi Token Akses Oauth2.0 menampilkan error "Invalid API call as no apiproduct match found" untuk mendapatkan panduan selengkapnya tentang penyebab error ini. |
VerifyAccessToken |
steps.oauth.v2.InvalidClientIdentifier |
500 |
Nama error ini ditampilkan jika properti |
|
steps.oauth.v2.InvalidParameter |
500 |
Kebijakan ini 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 responsnya adalah token , tetapi tidak ada jenis pemberian yang ditentukan. |
GenerateAuthorizationCode GenerateAccessTokenImplicitGrant |
steps.oauth.v2.UnSupportedGrantType |
500 |
Klien menentukan jenis pemberian yang tidak didukung oleh kebijakan (tidak tercantum dalam
elemen |
GenerateAccessToken GenerateAuthorizationCode GenerateAccessTokenImplicitGrant RefreshAccessToken |
Error runtime khusus token JWT
Kode dan deskripsi error runtime untuk alur token autentikasi JWT bergantung pada konteks alur OAuth2:
- Jika konteks alur adalah pembuatan token atau refresh, lihat Kode error untuk pembuatan token JWT dan alur refresh di bawah.
- Untuk mengetahui alur verifikasi token, lihat Kode error untuk alur verifikasi token di bawah.
Kode error untuk pembuatan token JWT dan alur refresh
Untuk alur OAuth2 yang menghasilkan atau memuat ulang token JWT, respons error akan mematuhi respons error yang ditentukan dalam RFC6749. Untuk mengetahui detailnya, lihat Respons Error Bagian 5.2.
Kode error untuk alur verifikasi token
Kode error yang tercantum dalam tabel berikut hanya berlaku untuk operasi VerifyAccessToken.
Kode kesalahan | Status HTTP | Penyebab | Dilempar oleh operasi |
---|---|---|---|
oauth.v2.JWTSigningFailed |
401 |
Kebijakan tidak dapat menandatangani JWT. |
|
oauth.v2.InvalidValueForJWTAlgorithm |
401 |
Hal ini terjadi ketika algoritma tidak ada dalam token akses JWT atau ketika nilainya tidak didukung. |
|
oauth.v2.InsufficientKeyLength |
401 |
Dalam Pembuatan JWT, untuk kunci yang kurang dari ukuran minimum untuk algoritma HS384 atau HS512 |
|
oauth.v2.JWTAlgorithmMismatch |
401 |
Algoritme yang ditentukan dalam kebijakan Buat tidak cocok dengan yang diharapkan dalam kebijakan Verifikasi. Algoritma yang ditentukan harus cocok. |
|
oauth.v2.JWTDecodingFailed |
401 |
Kebijakan tidak dapat mendekode JWT. JWT mungkin rusak. |
|
oauth.v2.MissingMandatoryClaimsInJWT |
401 |
Terjadi saat klaim yang diperlukan tidak ada dalam token Jwt Access |
|
oauth.v2.InvalidJWTSignature |
401 |
Hal ini terjadi ketika tanda tangan token akses JWT tidak dapat diverifikasi atau jika tanda tangan tidak valid. |
|
oauth.v2.InvalidTypeInJWTHeader |
401 |
Terjadi saat jenis JWT bukan at+Jwt |
|
Error saat deployment
Error ini dapat terjadi saat Anda men-deploy proxy yang berisi kebijakan ini.
Nama error | Penyebab |
---|---|
InvalidValueForExpiresIn |
Untuk elemen |
InvalidValueForRefreshTokenExpiresIn |
Untuk elemen <RefreshTokenExpiresIn> , nilai yang valid adalah bilangan bulat positif dan -1 . |
InvalidGrantType |
Jenis pemberian yang tidak valid ditentukan dalam elemen
<SupportedGrantTypes> . Lihat referensi kebijakan untuk mengetahui daftar jenis yang valid. |
ExpiresInNotApplicableForOperation |
Pastikan operasi yang ditentukan dalam elemen <Operations> mendukung akhir masa berlaku. Misalnya, operasi VerifyToken tidak demikian. |
RefreshTokenExpiresInNotApplicableForOperation |
Pastikan operasi yang ditentukan dalam elemen <Operations> mendukung akhir masa berlaku token refresh. Misalnya, operasi VerifyToken tidak demikian. |
GrantTypesNotApplicableForOperation |
Pastikan jenis pemberian yang ditentukan dalam <SupportedGrantTypes> didukung untuk operasi yang ditentukan. |
OperationRequired |
Anda harus menentukan operasi dalam kebijakan ini menggunakan elemen
|
InvalidOperation |
Anda harus menentukan operasi yang valid dalam kebijakan ini menggunakan elemen |
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 |
Algoritme yang ditentukan dalam elemen <Algorithm> tidak termasuk dalam daftar algoritma yang tersedia atau tidak ada. |
MissingKeyConfiguration |
Elemen <SecretKey> , <PrivateKey> , atau
<PublicKey> yang diperlukan tidak ada, bergantung pada algoritme yang digunakan. |
EmptyValueElementForKeyConfiguration |
Elemen turunan <Value> yang diperlukan tidak ditentukan dalam elemen <PrivateKey> , <PublicKey> , atau <SecretKey> |
InvalidKeyConfiguration |
Elemen <PrivateKey> tidak digunakan dengan algoritme keluarga RSA atau elemen <SecretKey> tidak digunakan dengan algoritma Keluarga HS. |
EmptyRefAttributeForKeyconfiguration |
Atribut ref elemen turunan <Value> dari elemen <PrivateKey> , <PublicKey> , atau <SecretKey> kosong. |
InvalidVariableNameForKey |
Nama variabel flow yang ditentukan dalam atribut ref elemen turunan
<Value> dari elemen <PrivateKey> ,
<PublicKey> , atau <SecretKey> tidak
berisi awalan private . |
Variabel kesalahan
Variabel ini ditetapkan saat kebijakan ini memicu error saat runtime.
Variabel | Dari mana | Contoh |
---|---|---|
fault.name="fault_name" |
fault_name adalah nama kesalahan, seperti yang tercantum dalam tabel Error runtime di atas. Nama kesalahan adalah bagian terakhir dari kode kesalahan. | fault.name = "invalid_request" |
oauthV2.policy_name.failed |
policy_name adalah nama kebijakan yang ditentukan pengguna yang menampilkan kesalahan. | oauthV2.GenerateAccesstoken.failed = true |
oauthV2.policy_name.fault.name |
policy_name adalah nama kebijakan yang ditentukan pengguna yang menampilkan kesalahan. | oauthV2.GenerateAccesstoken.fault.name = invalid_request
|
oauthV2.policy_name.fault.cause |
policy_name adalah nama kebijakan yang ditentukan pengguna yang menampilkan kesalahan. | oauthV2.GenerateAccesstoken.cause = Required param : grant_type |
Contoh respons error
Respons ini akan dikirim kembali ke klien jika elemen <GenerateResponse>
bernilai true.
Jika <GenerateResponse>
bernilai 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>
bernilai 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 kesalahan
<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"}