Halaman ini berlaku untuk Apigee dan Apigee hybrid.
Lihat dokumentasi Apigee Edge.
Apa
OAuthV2 adalah kebijakan multi-aspek 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 adalah Kebijakan yang dapat diperluas dan penggunaan kebijakan ini mungkin memiliki implikasi biaya atau penggunaan, bergantung pada lisensi Apigee Anda. Untuk informasi tentang jenis kebijakan dan implikasi penggunaan, lihat Jenis kebijakan.
Untuk mempelajari OAuth di Apigee lebih lanjut, lihat halaman beranda OAuth. Halaman ini menyediakan link ke referensi, contoh, video, dan lainnya.
Contoh
VerifyAccessToken
VerifyAccessToken
Konfigurasi kebijakan OAuthV2 ini (dengan operasi VerifyAccessToken) memverifikasi bahwa token akses yang dikirim ke Apigee valid. Saat operasi kebijakan ini dipicu, Apigee akan mencari token akses yang valid dalam permintaan. Jika token akses valid, permintaan akan diizinkan untuk dilanjutkan. Jika tidak valid, semua pemrosesan akan berhenti dan error akan ditampilkan dalam respons.
<OAuthV2 name="OAuthV2-Verify-Access-Token"> <Operation>VerifyAccessToken</Operation> </OAuthV2>
Aplikasi klien harus mengirimkan permintaan dengan token. Misalnya, menggunakan 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
Untuk contoh 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
Membuat kode otorisasi
Untuk contoh yang menunjukkan cara meminta kode otorisasi, lihat Meminta kode otorisasi.
RefreshAccessToken
Memperbarui token akses
Untuk contoh yang menunjukkan cara meminta token akses menggunakan token refresh, lihat Memperbarui 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 pada alur respons
Terkadang, Anda mungkin perlu membuat token akses dalam alur respons. Misalnya, Anda dapat melakukannya sebagai respons terhadap beberapa validasi kustom yang dilakukan di layanan backend. Dalam contoh ini, kasus penggunaan memerlukan token akses dan token refresh, sehingga mengecualikan jenis pemberian implisit. Dalam hal ini, kita akan menggunakan jenis pemberian sandi untuk membuat token. Seperti yang akan Anda lihat, trik untuk membuatnya berfungsi adalah dengan meneruskan header permintaan Otorisasi dengan kebijakan JavaScript.
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 Anda menempatkan kebijakan ini di alur respons, kebijakan akan gagal dengan error 401 UnAuthorized meskipun parameter login yang benar ditentukan dalam kebijakan. Untuk mengatasi masalah ini, Anda perlu menetapkan header permintaan Otorisasi.
Header Otorisasi harus berisi Skema akses dasar dengan client_id:client_secret yang dienkode Base64.
Anda dapat menambahkan header ini dengan kebijakan JavaScript yang ditempatkan tepat sebelum kebijakan OAuthV2, seperti ini. Variabel konteks "local_clientid" dan "local_secret" harus ditetapkan sebelumnya dan 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 Mengenkode kredensial autentikasi dasar.
Referensi elemen
Referensi kebijakan menjelaskan elemen dan atribut kebijakan OAuthV2.
Contoh kebijakan yang ditampilkan di bawah adalah salah satu dari banyak kemungkinan konfigurasi. Contoh ini menunjukkan kebijakan OAuthV2 yang dikonfigurasi untuk operasi GenerateAccessToken. Ini mencakup elemen wajib dan opsional. Lihat deskripsi elemen di bagian ini untuk mengetahui 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>
Atribut <OAuthV2>
<OAuthV2 async="false" continueOnError="false" enabled="true" name="MyOAuthPolicy">
Tabel berikut menjelaskan atribut yang umum untuk semua elemen induk kebijakan:
Atribut | Deskripsi | Default | Kehadiran |
---|---|---|---|
name |
Nama internal kebijakan. Nilai atribut Secara opsional, gunakan elemen |
T/A | Wajib |
continueOnError |
Tetapkan ke Tetapkan ke |
false | Opsional |
enabled |
Tetapkan ke Tetapkan ke |
benar | Opsional |
async |
Atribut ini tidak digunakan lagi. |
false | Tidak digunakan lagi |
Elemen <DisplayName>
Gunakan selain atribut name
untuk melabeli kebijakan di editor proxy UI pengelolaan dengan nama bahasa alami yang berbeda.
<DisplayName>Policy Display Name</DisplayName>
Default |
T/A Jika Anda menghapus elemen ini, nilai atribut |
---|---|
Kehadiran | Opsional |
Jenis | String |
Elemen <AccessToken>
<AccessToken>request.header.access_token</AccessToken>
Secara default, jika Operation
adalah VerifyAccessToken
, kebijakan mengharapkan token akses dikirim dalam header Authorization
sebagai token pembawa; yaitu, dengan awalan "Bearer", diikuti dengan satu spasi kosong.
Anda dapat mengubah default tersebut menggunakan elemen ini, dengan menentukan nama variabel yang berisi token akses yang akan diverifikasi. Saat Anda menggunakan elemen ini, kebijakan secara default tidak
mencari awalan dalam konten variabel. Jika Anda ingin menentukan bahwa kebijakan
harus mencari awalan, gunakan juga elemen
AccessTokenPrefix
.
Contoh:
Jika 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"
Jika 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"
Dengan 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 |
|
Elemen <AccessTokenPrefix>
<AccessTokenPrefix>Prefix</AccessTokenPrefix>
Secara default, jika Operation
adalah VerifyAccessToken
, kebijakan mengharapkan token akses dikirim dalam header Authorization
sebagai token pembawa; yaitu, dengan awalan "Bearer", diikuti dengan satu spasi kosong.
Jika menggunakan elemen AccessToken
untuk
menentukan lokasi yang berbeda untuk token akses yang masuk, Anda juga dapat 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 akan mengekstrak token akses masuk dari header permintaan token
,
dengan cara ini: jika header dimulai dengan kata "KEY" diikuti dengan spasi, kebijakan akan menghapus
awalan dan spasi tersebut serta menafsirkan nilai yang tersisa sebagai token akses. Jika
awalan yang ditentukan tidak ada di header, kebijakan akan menampilkan error.
Jika Anda menentukan elemen AccessToken
, dan tidak menentukan elemen AccessTokenPrefix
, kebijakan akan menafsirkan seluruh nilai variabel yang ditentukan dalam elemen AccessToken
sebagai token akses.
Elemen ini hanya efektif jika elemen AccessToken
juga digunakan.
Default |
-none- |
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, sedangkan algoritma HMAC (HS*) menggunakan secret bersama. Elemen ini diperlukan
untuk operasi GenerateJWTAccessToken
, VerifyJWTAccessToken
, dan RefreshJWTAccessToken
.
Default | T/A |
Kehadiran | Wajib ada saat menggunakan
operasi GenerateJWTAccessToken , VerifyJWTAccessToken , dan RefreshJWTAccessToken . |
Jenis | String |
Nilai yang valid | HS256, HS384, HS512, RS256, RS384, RS512 |
Elemen <AppEndUser>
<AppEndUser>request.queryparam.app_enduser</AppEndUser>
Jika ID pengguna akhir aplikasi harus dikirim ke server otorisasi, elemen ini memungkinkan Anda menentukan tempat Apigee harus mencari ID pengguna akhir. Misalnya, parameter ini dapat dikirim sebagai parameter kueri atau dalam header HTTP.
Misalnya, request.queryparam.app_enduser
menunjukkan bahwa
AppEndUser harus ada sebagai parameter kueri, seperti, misalnya,
?app_enduser=ntesla@theramin.com
. Untuk mewajibkan AppEndUser dalam header HTTP, misalnya, tetapkan nilai ini ke request.header.app_enduser
.
Dengan menyediakan setelan ini, Anda dapat menyertakan ID pengguna akhir aplikasi dalam token akses. Fitur ini berguna jika Anda ingin dapat mengambil atau mencabut token akses OAuth 2.0 menurut ID pengguna akhir. Untuk informasi selengkapnya, lihat Mengaktifkan pengambilan dan pencabutan token akses OAuth 2.0 menurut ID pengguna akhir, ID aplikasi, atau keduanya.
Default |
T/A |
Kehadiran |
Opsional |
Jenis | String |
Nilai yang valid |
Setiap variabel alur yang dapat diakses oleh kebijakan saat runtime. |
Digunakan dengan jenis pemberian akses |
|
<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. Misalnya, Anda dapat menyematkan ID pengguna atau ID sesi dalam token akses yang dapat diekstrak dan diperiksa saat runtime.
Elemen ini memungkinkan Anda menentukan nilai dalam variabel alur atau dari string literal. Jika Anda menentukan variabel dan string, nilai yang ditentukan dalam variabel alur akan digunakan. Jika variabel tidak dapat di-resolve, string akan menjadi default.
Untuk mengetahui informasi selengkapnya tentang penggunaan elemen ini, lihat Menyesuaikan Token dan Kode Otorisasi.
Menampilkan atau menyembunyikan atribut kustom dalam respons
Perlu diingat bahwa jika Anda menetapkan elemen GenerateResponse kebijakan ini ke true, representasi JSON lengkap token akan ditampilkan dalam respons, termasuk atribut kustom yang Anda tetapkan. Dalam beberapa kasus, Anda mungkin ingin menyembunyikan beberapa atau semua atribut kustom dalam respons sehingga tidak terlihat oleh aplikasi klien.
Secara default, atribut kustom akan muncul dalam respons. Jika ingin menyembunyikannya, Anda dapat menetapkan 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
tidak
dipertahankan. Misalnya, Anda membuat token akses dengan atribut kustom yang ingin disembunyikan dalam
respons yang dihasilkan. Menetapkan display=false
akan mencapai sasaran tersebut. Namun, jika token akses baru
dibuat nanti menggunakan token refresh, atribut kustom asli dari
token akses akan muncul dalam respons token refresh. Hal ini karena Apigee tidak mengingat bahwa
atribut display
awalnya ditetapkan ke false
dalam kebijakan pembuatan token akses--atribut
kustom hanyalah bagian dari metadata token akses.
Anda akan melihat perilaku yang sama jika menambahkan atribut kustom ke kode otorisasi. Saat token akses dibuat menggunakan kode tersebut, atribut kustom tersebut akan muncul dalam respons token akses. Sekali lagi, ini mungkin bukan perilaku yang Anda inginkan.
Untuk menyembunyikan atribut kustom dalam kasus ini, Anda memiliki pilihan berikut:
- Reset atribut kustom secara eksplisit dalam kebijakan token refresh dan tetapkan tampilannya ke false. Dalam hal ini, Anda mungkin perlu mengambil nilai kustom asli dari token akses asli menggunakan kebijakan GetOAuthV2Info.
- Gunakan kebijakan JavaScript pascapemrosesan untuk mengekstrak atribut kustom apa pun yang tidak ingin Anda lihat dalam respons secara manual.
Lihat juga Menyesuaikan Token dan Kode Otorisasi.
Default |
|
Kehadiran |
Opsional |
Nilai yang valid |
|
Digunakan dengan jenis pemberian akses |
|
Elemen <CacheExpiryInSeconds>
<CacheExpiryInSeconds ref="propertyset.settings.token-ttl">60</CacheExpiryInSeconds>
Elemen ini hanya dapat digunakan dengan operasi VerifyAccessToken
. Ini menentukan
time-to-live (TTL) pada cache token akses untuk eksekusi kebijakan tertentu. Saat pertama kali memverifikasi token akses OAuth 2, Apigee harus mengambil token akses dari penyimpanan persisten. Ini adalah operasi yang relatif mahal, sehingga Apigee meng-cache hasil pencarian token, termasuk status token, daftar produk yang valid untuk token, dan atribut kustom apa pun yang dilampirkan ke token. Panggilan berikutnya dari
OAuthV2/VerifyAccessToken
hingga TTL berlalu akan membaca hasil cache
dalam memori, yang berarti verifikasi token akan jauh lebih cepat.
TTL default untuk cache token akses adalah 180 detik. Elemen ini memungkinkan Anda mengurangi TTL tersebut, sehingga mengorbankan performa demi akurasi. Salah satu skenario yang akan masuk akal adalah jika Anda terkadang mencabut token, dan Anda ingin mengurangi periode waktu saat Apigee akan terus memperlakukan token yang dicabut sebagai valid.
Rentang yang didukung adalah antara 1 dan 180 detik. Anda dapat memberikan variabel alur dan nilai default. Jika Anda memberikan variabel alur dan jika variabel tersebut berisi nilai numerik, variabel tersebut akan lebih diutamakan daripada nilai default yang ditentukan.
Default |
T/A
Jika Anda menghilangkan elemen ini, periode habis masa berlaku default untuk token akses yang di-cache adalah 180 detik. |
Kehadiran |
Opsional |
Jenis |
Bilangan bulat |
Nilai yang valid |
Semua bilangan bulat positif yang bukan nol. Menentukan waktu habis masa berlaku dalam detik. |
Digunakan dengan operasi |
|
Atribut
Tabel berikut menjelaskan atribut elemen <CacheExpiryInSeconds>
Atribut | Deskripsi | Default | Kehadiran |
---|---|---|---|
ref |
Referensi ke variabel flow yang berisi nilai untuk masa berlaku cache, yang dinyatakan dalam detik. Jika disediakan, nilai variabel alur akan lebih diprioritaskan daripada nilai default yang ditentukan. |
T/A | Opsional |
Elemen <ClientId>
<ClientId>request.formparam.client_id</ClientId>
Dalam beberapa kasus, aplikasi klien harus mengirim client ID ke server otorisasi. Elemen ini
menentukan bahwa Apigee harus mencari client ID dalam variabel alur
request.formparam.client_id
. Menetapkan ClientId
ke variabel lain tidak didukung.
Lihat juga Mendapatkan token OAuth 2.0.
Default |
request.formparam.client_id (x-www-form-urlencoded dan ditentukan dalam isi permintaan) |
Kehadiran |
Opsional |
Jenis | String |
Nilai yang valid | Variabel alur: request.formparam.client_id |
Digunakan dengan jenis pemberian akses |
Juga dapat digunakan dengan operasi GenerateAuthorizationCode. |
Elemen <Code>
<Code>request.queryparam.code</Code>
Dalam alur jenis pemberian otorisasi, klien harus mengirimkan kode otorisasi ke server otorisasi (Apigee). Elemen ini memungkinkan Anda menentukan tempat Apigee harus mencari kode otorisasi. Misalnya, parameter ini dapat dikirim sebagai parameter kueri, header HTTP, atau parameter formulir (default).
Variabel, request.queryparam.auth_code
menunjukkan bahwa
kode otorisasi harus ada sebagai parameter kueri, seperti, misalnya, ?auth_code=AfGlvs9
. Untuk mewajibkan kode otorisasi di header HTTP, misalnya, tetapkan nilai ini ke request.header.auth_code
. Lihat juga
Mendapatkan token OAuth 2.0.
Default |
request.formparam.code (x-www-form-urlencoded dan ditentukan dalam isi permintaan) |
Kehadiran |
opsional |
Jenis | String |
Nilai yang valid | Setiap variabel alur yang dapat diakses oleh kebijakan saat runtime |
Digunakan dengan jenis pemberian akses | authorization_code |
Elemen<ExpiresIn>
<ExpiresIn>10000</ExpiresIn>
Menerapkan waktu habis masa berlaku token akses dan kode otorisasi dalam milidetik. (Untuk
token refresh, gunakan <RefreshTokenExpiresIn>
.) Nilai waktu habis masa berlaku adalah
nilai yang dihasilkan sistem ditambah nilai <ExpiresIn>
. Jika
<ExpiresIn>
ditetapkan ke -1, masa berlaku token atau kode akan berakhir sesuai dengan masa berlaku token akses OAuth maksimum. Jika <ExpiresIn>
tidak ditentukan, sistem akan menerapkan
nilai default yang dikonfigurasi di tingkat sistem.
Waktu habis masa berlaku juga dapat ditetapkan saat runtime menggunakan nilai default yang di-hardcode atau dengan
mereferensikan variabel alur. Misalnya, Anda dapat menyimpan nilai masa berlaku token dalam peta nilai kunci, mengambilnya, menetapkannya ke variabel, dan mereferensikannya dalam kebijakan. Contoh,
kvm.oauth.expires_in
.
Apigee menyimpan entitas berikut dalam cache selama minimal 180 detik setelah entitas diakses.
- Token akses OAuth. Artinya, elemen
ExpiresIn
pada kebijakan OAuth v2 tidak akan dapat berakhir masa berlakunya token akses dalam waktu kurang dari 180 detik. - Entitas Key Management Service (KMS) (Aplikasi, Developer, Produk API).
- Atribut kustom pada token OAuth dan entitas KMS.
Stanza berikut juga menentukan variabel alur dan nilai default. Perhatikan bahwa nilai variabel aliran lebih diutamakan daripada nilai default yang ditentukan.
<ExpiresIn ref="kvm.oauth.expires_in"> 3600000 <!--default value in milliseconds--> </ExpiresIn>
Apigee tidak mendukung cara untuk memaksa masa berlaku token berakhir setelah token dibuat. Jika Anda perlu memaksa masa berlaku token berakhir (misalnya, berdasarkan kondisi), kemungkinan solusinya dijelaskan dalam postingan Komunitas Apigee ini.
Secara default, token akses yang sudah tidak berlaku akan dihapus secara permanen dari sistem Apigee Apigee secara otomatis 3 hari setelah masa berlakunya berakhir. Lihat juga Menghapus token akses
Default |
Jika tidak ditentukan, sistem akan menerapkan nilai default yang dikonfigurasi di tingkat sistem. |
Kehadiran |
Opsional |
Jenis | Bilangan bulat |
Nilai yang valid |
|
Digunakan dengan jenis pemberian akses |
Juga digunakan dengan operasi GenerateAuthorizationCode. |
Elemen <ExternalAccessToken>
<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, misalnya, ?external_access_token=12345678
. Untuk mewajibkan token akses eksternal
dalam header HTTP, misalnya, tetapkan nilai ini
ke request.header.external_access_token
. Lihat juga Menggunakan Token OAuth Pihak Ketiga.
Elemen <ExternalAuthorization>
<ExternalAuthorization>true</ExternalAuthorization>
Jika elemen ini salah atau tidak ada, Apigee akan memvalidasi client_id dan client_secret secara normal terhadap penyimpanan otorisasi Apigee. Gunakan elemen ini jika Anda ingin menggunakan token OAuth pihak ketiga. Untuk mengetahui detail tentang penggunaan elemen ini, lihat Menggunakan Token OAuth Pihak Ketiga.
Default |
false |
Kehadiran |
Opsional |
Jenis | Boolean |
Nilai yang valid | benar atau salah |
Digunakan dengan jenis pemberian akses |
|
Elemen <ExternalAuthorizationCode>
<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, seperti, misalnya, ?external_auth_code=12345678
. Untuk mewajibkan kode autentikasi
eksternal
dalam header HTTP, misalnya, tetapkan nilai ini
ke request.header.external_auth_code
. Lihat juga Menggunakan Token OAuth Pihak Ketiga.
Elemen <ExternalRefreshToken>
<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, seperti, misalnya, ?external_refresh_token=12345678
. Untuk mewajibkan token refresh eksternal
dalam header HTTP, misalnya, tetapkan nilai ini
ke request.header.external_refresh_token
. Lihat juga Menggunakan Token OAuth Pihak Ketiga.
Elemen <GenerateResponse>
<GenerateResponse enabled='true'/>
Jika ditetapkan ke true
atau jika atribut enabled
dihilangkan, kebijakan akan menghasilkan dan menampilkan respons. Misalnya, untuk GenerateAccessToken, responsnya mungkin seperti:
{ "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, serangkaian variabel alur diisi dengan nilai yang terkait dengan
fungsi kebijakan. Misalnya, variabel alur yang disebut
oauthv2authcode.OAuthV2-GenerateAuthorizationCode.code
diisi dengan kode autentikasi
yang baru dibuat. Perhatikan bahwa expires_in dinyatakan dalam detik dalam
respons.
Default |
benar |
Kehadiran |
Opsional |
Jenis | string |
Nilai yang valid | benar atau salah |
Digunakan dengan jenis pemberian akses |
|
Elemen <GenerateErrorResponse>
<GenerateErrorResponse enabled='true'/>
Jika disetel ke true
, kebijakan akan membuat dan menampilkan respons jika
atribut ContinueOnError disetel ke benar (true). Jika false
(default), tidak ada respons yang dikirim. Sebagai gantinya, serangkaian variabel alur diisi dengan nilai yang terkait dengan
fungsi kebijakan.
Default |
false |
Kehadiran |
Opsional |
Jenis | string |
Nilai yang valid | benar atau salah |
Digunakan dengan jenis pemberian akses |
|
<GrantType>
<GrantType>request.queryparam.grant_type</GrantType>
Memberi tahu kebijakan tempat menemukan parameter jenis hibah yang diteruskan dalam permintaan. Sesuai dengan spesifikasi OAuth 2.0, jenis pemberian harus dilengkapi dengan permintaan untuk token akses dan kode otorisasi. Variabel dapat berupa header, parameter kueri, atau parameter formulir (default).
Misalnya, request.queryparam.grant_type
menunjukkan bahwa Sandi harus ada sebagai parameter kueri, seperti, misalnya, ?grant_type=password
.
Untuk mewajibkan jenis pemberian 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-urlencoded dan ditentukan dalam isi permintaan) |
Kehadiran |
Opsional |
Jenis | string |
Nilai yang valid | Variabel, seperti yang dijelaskan di atas. |
Digunakan dengan jenis pemberian akses |
|
Elemen <Operation>
<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 memilih untuk menggunakan token akses JWT, bukan token string buram, operasi berikut juga tersedia untuk membuat dan memvalidasi token JWT. Untuk mengetahui detailnya, lihat Menggunakan operasi token OAuth JWT:
|
Elemen <PassWord>
<PassWord>request.queryparam.password</PassWord>
Elemen ini hanya digunakan dengan jenis pemberian sandi. Dengan
jenis pemberian sandi, kredensial pengguna (sandi dan nama pengguna) harus disediakan untuk
kebijakan OAuthV2. Elemen <PassWord>
dan <UserName>
digunakan untuk menentukan variabel tempat Apigee dapat menemukan nilai ini. Jika 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 menetapkan elemen seperti ini: <PassWord>request.queryparam.password</PassWord>
.
Untuk mewajibkan sandi dalam header HTTP, tetapkan nilai ini ke request.header.password
.
Kebijakan OAuthV2 tidak melakukan tindakan lain dengan nilai kredensial ini; Apigee hanya memverifikasi bahwa nilai tersebut ada. Developer API dapat mengambil permintaan nilai dan mengirimnya ke penyedia identitas sebelum kebijakan pembuatan token dijalankan.
Lihat juga Mendapatkan token OAuth 2.0.
Default |
request.formparam.password (x-www-form-urlencoded dan ditentukan dalam isi permintaan) |
Kehadiran |
Opsional |
Jenis | String |
Nilai yang valid | Setiap variabel alur yang tersedia untuk kebijakan saat runtime. |
Digunakan dengan jenis pemberian akses | sandi |
<PrivateKey>/<Value>
<PrivateKey> <Value ref="variable-name-here"/> </PrivateKey>
Memberikan kunci pribadi yang digunakan untuk memverifikasi atau menandatangani token akses berformat JWT dengan algoritma RSA.
Gunakan atribut ref
untuk meneruskan kunci dalam variabel alur.
Hanya gunakan jika
nilai elemen Algorithm
adalah salah satu dari RS256, RS384, atau RS512. Untuk mengetahui informasi selengkapnya, lihat
Menggunakan operasi token OAuth JWT.
Default | T/A |
Kehadiran | Diperlukan jika nilai elemen Algorithm adalah salah satu dari
HS256, HS384, atau HS512. |
Jenis | String |
Nilai yang valid | Variabel alur yang berisi string yang mewakili nilai kunci pribadi RSA yang dienkode 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 alur. Gunakan hanya jika
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 elemen Sertifikat, JWKS, atau Nilai. |
Jenis | String |
Nilai yang valid | Variabel atau string alur. |
Elemen <RedirectUri>
<RedirectUri>request.queryparam.redirect_uri</RedirectUri>
Menentukan tempat Apigee harus mencari parameter redirect_uri
dalam
permintaan.
Tentang URI pengalihan
URI pengalihan digunakan dengan kode otorisasi dan jenis pemberian implisit. URI pengalihan memberi tahu server otorisasi (Apigee) tempat mengirim kode otorisasi (untuk jenis pemberian kode otorisasi) atau token akses (untuk jenis pemberian implisit). Penting untuk memahami kapan parameter ini diperlukan, kapan bersifat opsional, dan cara penggunaannya:
-
(wajib) Jika URL Callback terdaftar dengan aplikasi developer yang terkait dengan kunci klien permintaan, dan jika
redirect_uri
ada dalam permintaan, keduanya harus sama persis. Jika tidak cocok, error akan ditampilkan. Untuk informasi tentang cara mendaftarkan aplikasi developer di Apigee dan menentukan URL Callback, lihat Mendaftarkan aplikasi dan mengelola kunci API. - (opsional) Jika URL Callback terdaftar, dan
redirect_uri
tidak ada dalam permintaan, Apigee akan mengalihkan ke URL Callback yang terdaftar. - (wajib) Jika URL Callback tidak terdaftar,
redirect_uri
diperlukan. Perhatikan bahwa dalam hal ini, Apigee akan menerima URL APA PUN. Kasus ini dapat menimbulkan masalah keamanan, sehingga hanya boleh digunakan dengan aplikasi klien tepercaya. Jika aplikasi klien tidak tepercaya, praktik terbaiknya adalah selalu mewajibkan pendaftaran URL Callback.
Anda dapat mengirim parameter ini dalam parameter kueri atau dalam header. Variabel
request.queryparam.redirect_uri
menunjukkan bahwa RedirectUri
harus ada sebagai parameter kueri, seperti, misalnya, ?redirect_uri=login.myapp.com
. Untuk mewajibkan RedirectUri di header HTTP, misalnya, tetapkan nilai ini ke request.header.redirect_uri
. Lihat
juga Mendapatkan token OAuth 2.0.
Default |
request.formparam.redirect_uri (x-www-form-urlencoded dan ditentukan dalam isi permintaan) |
Kehadiran |
Opsional |
Jenis | String |
Nilai yang valid | Setiap variabel alur yang dapat diakses dalam kebijakan saat runtime |
Digunakan dengan jenis pemberian akses |
Juga digunakan dengan operasi GenerateAuthorizationCode. |
Elemen <RefreshToken>
<RefreshToken>request.queryparam.refreshtoken</RefreshToken>
Saat meminta token akses menggunakan token refresh, Anda harus memberikan token refresh dalam permintaan. Elemen ini memungkinkan Anda menentukan tempat Apigee harus mencari token refresh. Misalnya, parameter ini dapat dikirim sebagai parameter kueri, header HTTP, atau parameter formulir (default).
Variabel request.queryparam.refreshtoken
menunjukkan bahwa token refresh harus ada sebagai parameter kueri, seperti, misalnya, ?refresh_token=login.myapp.com
. Untuk mewajibkan RefreshToken dalam header HTTP, misalnya, tetapkan nilai ini ke request.header.refresh_token
. Lihat
juga Mendapatkan token OAuth 2.0.
Default |
request.formparam.refresh_token (x-www-form-urlencoded dan ditentukan dalam isi permintaan) |
Kehadiran |
Opsional |
Jenis | String |
Nilai yang valid | Setiap variabel alur yang dapat diakses dalam kebijakan saat runtime |
Digunakan dengan jenis pemberian akses |
|
Elemen <RefreshTokenExpiresIn>
<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>
ditetapkan ke -1, masa berlaku token refresh
akan berakhir sesuai dengan masa berlaku token refresh
OAuth maksimum. Jika <RefreshTokenExpiresIn>
tidak ditentukan,
sistem akan menerapkan nilai default.
Waktu habis masa berlaku juga dapat ditetapkan saat runtime menggunakan nilai default yang di-hardcode atau dengan
mereferensikan variabel alur. Misalnya, Anda dapat menyimpan nilai masa berlaku token dalam peta nilai kunci, mengambilnya, menetapkannya ke variabel, dan mereferensikannya dalam kebijakan. Misalnya, kvm.oauth.expires_in
.
Stanza berikut juga menentukan variabel alur dan nilai default. Perhatikan bahwa nilai variabel flow lebih diutamakan daripada nilai default yang ditentukan.
<RefreshTokenExpiresIn ref="kvm.oauth.expires_in"> 86400000 <!--value in milliseconds--> </RefreshTokenExpiresIn>
Default |
2592000000 md (30 hari) (mulai berlaku 31 Mei 2023) |
Kehadiran |
Opsional |
Jenis | Bilangan bulat |
Nilai yang valid |
|
Digunakan dengan jenis pemberian akses |
|
Elemen <ResponseType>
<ResponseType>request.queryparam.response_type</ResponseType>
Elemen ini memberi tahu Apigee jenis pemberian yang diminta aplikasi klien. Kode ini hanya digunakan dengan alur kode otorisasi dan jenis pemberian implisit.
Secara default, Apigee mencari nilai jenis respons dalam parameter kueri response_type
. Jika Anda ingin mengganti perilaku default ini, gunakan elemen <ResponseType> untuk mengonfigurasi variabel alur yang berisi nilai jenis respons. Misalnya, jika Anda menetapkan elemen ini
ke request.header.response_type
, Apigee akan mencari jenis respons yang akan
diteruskan di header permintaan. Lihat juga Mendapatkan token OAuth 2.0.
Default |
request.formparam.response_type (x-www-form-urlencoded dan ditentukan dalam isi permintaan) |
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 akses |
|
Elemen <ReuseRefreshToken>
<ReuseRefreshToken>true</ReuseRefreshToken>
Jika disetel ke true
, token refresh yang ada akan digunakan kembali hingga masa berlakunya berakhir. Jika
false
, token refresh baru akan dikeluarkan oleh Apigee saat token refresh yang valid
ditampilkan.
Default |
|
Kehadiran |
opsional |
Jenis | boolean |
Nilai yang valid |
|
Digunakan dengan jenis pemberian akses |
|
Elemen <RFCCompliantRequestResponse>
<RFCCompliantRequestResponse>[true | false]</RFCCompliantRequestResponse>
Jika true
, kebijakan akan mematuhi standar RFC6749 dan mengaktifkan perilaku yang mematuhi berikut:
- Respons error dan non-error akan menyertakan kolom header respons HTTP
Cache-Control
untuk mematuhi RFC2616 (Hypertext Transfer Protocol -- HTTP/1.1), dengan nilaino-store
dalam respons apa pun 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 menyertakan kolom header
Bearer
yang mematuhi RFC, bukanBearerToken
. - 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 akses | Semua |
<SecretKey>/<Value>
<SecretKey> <Value ref="your-variable-name"/> </SecretKey>
Memberikan kunci rahasia yang digunakan untuk memverifikasi atau menandatangani token akses berformat JWT dengan algoritma HMAC. Hanya gunakan
jika algoritmenya adalah salah satu dari HS256, HS384, atau HS512. Gunakan atribut ref
untuk meneruskan kunci dalam variabel alur. Untuk mengetahui 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 alur |
Elemen <Scope>
<Scope>request.queryparam.scope</Scope>
Jika elemen ini ada di salah satu kebijakan GenerateAccessToken atau GenerateAuthorizationCode, elemen ini digunakan untuk menentukan cakupan yang akan memberikan token atau kode. Nilai ini
biasanya diteruskan ke kebijakan dalam permintaan dari aplikasi klien. Anda dapat mengonfigurasi elemen untuk
mengambil variabel alur, yang memberi Anda opsi untuk memilih cara cakupan diteruskan dalam permintaan. Dalam
contoh berikut, request.queryparam.scope
menunjukkan bahwa cakupan harus
ada sebagai parameter kueri, seperti, misalnya, ?scope=READ
. Untuk mewajibkan cakupan di header HTTP, misalnya, tetapkan nilai ini ke request.header.scope
.
Jika elemen ini muncul dalam kebijakan "VerifyAccessToken", elemen ini akan digunakan untuk menentukan cakupan yang harus diterapkan kebijakan. Dalam jenis kebijakan ini, nilai harus berupa nama cakupan "hard code" -- Anda tidak dapat menggunakan variabel. Contoh:
<Scope>A B</Scope>
Lihat juga Menggunakan cakupan OAuth2 dan Mendapatkan token OAuth 2.0.
Default |
Tidak ada cakupan |
Kehadiran |
Opsional |
Jenis | String |
Nilai yang valid |
Jika digunakan dengan kebijakan Generate*, variabel alur. Jika digunakan dengan VerifyAccessToken, daftar nama cakupan (string) yang dipisahkan spasi. |
Digunakan dengan jenis pemberian akses |
|
Elemen <State>
<State>request.queryparam.state</State>
Jika aplikasi klien harus mengirim informasi status ke server otorisasi, elemen ini memungkinkan Anda menentukan tempat Apigee harus mencari nilai status. Misalnya, parameter ini dapat dikirim sebagai parameter kueri atau dalam header HTTP. Nilai status biasanya digunakan sebagai tindakan keamanan untuk mencegah serangan CSRF.
Misalnya, request.queryparam.state
menunjukkan bahwa status harus
ada sebagai parameter kueri, seperti, misalnya, ?state=HjoiuKJH32
. Untuk mewajibkan status di 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 | Setiap variabel alur yang dapat diakses oleh kebijakan saat runtime |
Digunakan dengan jenis pemberian akses |
|
Elemen <StoreToken>
<StoreToken>true</StoreToken>
Tetapkan elemen ini ke true
saat elemen
<ExternalAuthorization>
adalah true
. Elemen <StoreToken>
memberi tahu Apigee untuk
menyimpan token akses eksternal. Jika tidak, data tidak akan dipertahankan.
Default |
false |
Kehadiran |
Opsional |
Jenis | Boolean |
Nilai yang valid | benar atau salah |
Digunakan dengan jenis pemberian akses |
|
Elemen <SupportedGrantTypes>/<GrantType>
<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 dapat
mendukung beberapa jenis pemberian (yaitu, satu endpoint dapat dikonfigurasi untuk mendistribusikan token akses
untuk beberapa jenis pemberian). Untuk mengetahui informasi selengkapnya tentang endpoint, lihat Memahami endpoint
OAuth. Jenis pemberian diteruskan dalam permintaan token dalam parameter grant_type
.
Jika tidak ada jenis hibah yang didukung yang ditentukan, satu-satunya jenis hibah yang diizinkan adalah
authorization_code
dan implicit
. Lihat juga elemen <GrantType> (yang merupakan elemen tingkat tinggi yang digunakan untuk
menentukan tempat Apigee harus mencari parameter grant_type
yang diteruskan dalam
permintaan klien. Apigee akan memastikan bahwa nilai parameter grant_type
cocok dengan salah satu jenis pemberian yang didukung).
Default |
authorization _code dan implicit |
Kehadiran |
Wajib |
Jenis | String |
Nilai yang valid |
|
Elemen <Tokens>/<Token>
Digunakan dengan operasi ValidateToken dan InvalidateToken. Lihat juga Menyetujui dan mencabut token akses. Elemen <Token> mengidentifikasi variabel alur yang menentukan
sumber token yang akan dicabut. Jika developer diharapkan untuk mengirimkan token akses sebagai
parameter kueri bernama access_token
, misalnya,
gunakan request.queryparam.access_token
.
Elemen <UserName>
<UserName>request.queryparam.user_name</UserName>
Elemen ini hanya digunakan dengan jenis pemberian sandi. Dengan
jenis pemberian sandi, kredensial pengguna (sandi dan nama pengguna) harus disediakan untuk
kebijakan OAuthV2. Elemen <PassWord>
dan <UserName>
digunakan untuk menentukan variabel tempat Apigee dapat menemukan nilai ini. Jika 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 nama pengguna dalam parameter kueri dan menetapkan elemen <UserName>
seperti ini: <UserName>request.queryparam.username</UserName>
.
Untuk mewajibkan nama pengguna dalam header HTTP, tetapkan nilai ini ke request.header.username
.
Kebijakan OAuthV2 tidak melakukan tindakan lain dengan nilai kredensial ini; Apigee hanya memverifikasi bahwa nilai tersebut ada. Developer API dapat mengambil permintaan nilai dan mengirimnya ke penyedia identitas sebelum kebijakan pembuatan token dijalankan.
Lihat juga Mendapatkan token OAuth 2.0.
Default |
request.formparam.username (x-www-form-urlencoded dan ditentukan dalam isi permintaan) |
Kehadiran |
Opsional |
Jenis | String |
Nilai yang valid | Setelan variabel apa pun. |
Digunakan dengan jenis pemberian akses | sandi |
Memverifikasi token akses
Setelah endpoint token disiapkan untuk proxy API, kebijakan OAuthV2 yang sesuai yang menentukan operasi VerifyAccessToken
akan dilampirkan ke Flow yang mengekspos resource yang dilindungi.
Misalnya, untuk memastikan bahwa semua permintaan ke API diotorisasi, kebijakan berikut menerapkan verifikasi token akses:
<OAuthV2 name="VerifyOAuthAccessToken"> <Operation>VerifyAccessToken</Operation> </OAuthV2>
Kebijakan dilampirkan ke resource API yang akan dilindungi. Untuk memastikan bahwa semua permintaan ke API diverifikasi, lampirkan kebijakan ke PreFlow permintaan ProxyEndpoint, sebagai berikut:
<PreFlow> <Request> <Step><Name>VerifyOAuthAccessToken</Name></Step> </Request> </PreFlow>
Elemen opsional berikut dapat digunakan untuk mengganti setelan default untuk operasi VerifyAccessToken.
Nama | Deskripsi |
---|---|
Cakupan |
Daftar cakupan yang dipisahkan spasi. Verifikasi akan berhasil jika setidaknya salah satu 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 READ atau WRITE ada, 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 default, token akses diharapkan
ditampilkan oleh aplikasi di header HTTP Otorisasi, sesuai dengan spesifikasi OAuth 2.0. Gunakan setelan
ini jika token akses diharapkan ditampilkan di lokasi non-standar, seperti
parameter kueri, atau header HTTP dengan nama selain Authorization. |
Lihat juga Memverifikasi token akses dan Mendapatkan token OAuth 2.0.
Menentukan lokasi variabel permintaan
Untuk setiap jenis pemberian, kebijakan membuat asumsi tentang lokasi atau informasi yang diperlukan dalam pesan permintaan. Asumsi ini didasarkan pada spesifikasi OAuth 2.0. Jika aplikasi Anda perlu menyimpang dari spesifikasi OAuth 2.0, Anda dapat menentukan lokasi yang diharapkan untuk setiap parameter. Misalnya, saat menangani kode otorisasi, Anda dapat menentukan lokasi kode otorisasi, client ID, URI pengalihan, dan cakupan. Parameter ini dapat ditentukan sebagai header HTTP, parameter kueri, atau parameter formulir.
Contoh di bawah menunjukkan cara menentukan lokasi parameter kode otorisasi yang diperlukan 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 perlu untuk mendukung basis aplikasi klien, Anda dapat menggabungkan header dan parameter kueri:
... <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 alur
Variabel alur yang ditentukan dalam tabel ini diisi saat kebijakan OAuth masing-masing dieksekusi, sehingga tersedia untuk kebijakan atau aplikasi lain yang dieksekusi dalam alur proxy API.
Operasi VerifyAccessToken
Saat operasi VerifyAccessToken dieksekusi, sejumlah besar variabel alur diisi dalam konteks eksekusi proxy. Variabel ini memberi Anda properti yang terkait dengan token akses, aplikasi developer, dan developer. Anda dapat menggunakan kebijakan AssignMessage atau JavaScript, misalnya, untuk membaca salah satu variabel ini dan menggunakannya sesuai kebutuhan nanti dalam alur. Variabel ini 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 yang terkait dengan aplikasi klien terdaftar. |
developer.app.name |
Nama developer atau aplikasi AppGroup yang terkait dengan aplikasi klien terdaftar. |
client_id |
Client-ID aplikasi klien 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 di token akses. |
issued_at |
Tanggal token akses diterbitkan yang dinyatakan dalam waktu epoch Unix dalam milidetik. |
expires_in |
Waktu habis masa berlaku untuk token akses. Dinyatakan dalam
detik. Meskipun elemen ExpiresIn menetapkan masa berlaku dalam milidetik, dalam respons token dan variabel alur, nilainya dinyatakan dalam detik. |
status |
Status token akses (misalnya, disetujui atau dicabut). |
scope |
Cakupan (jika ada) yang terkait dengan token akses. |
apiproduct.<custom_attribute_name> |
Atribut kustom bernama dari produk API yang terkait dengan aplikasi klien yang terdaftar. |
apiproduct.name |
Nama produk API yang terkait dengan aplikasi klien terdaftar. |
revoke_reason |
(Khusus Apigee hybrid) Menunjukkan alasan token akses dicabut. Tidak didukung untuk operasi Nilainya dapat berupa |
Variabel khusus aplikasi
Variabel ini terkait dengan Aplikasi Developer yang dikaitkan 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 kustom bernama dari aplikasi klien terdaftar. |
Variabel khusus AppGroup
Variabel alur berikut berisi informasi tentang
AppGroup
untuk token dan diisi oleh kebijakan. Atribut AppGroup ini hanya diisi jika
verifyapikey.{policy_name}.app.appType
adalah "AppGroup".
Variabel | Deskripsi |
---|---|
appgroup.displayName |
Nama tampilan AppGroup. |
appgroup.name |
Nama AppGroup. |
appgroup.id |
ID AppGroup. |
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 mengubah AppGroup. |
{appgroup_custom_attributes} |
Atribut AppGroup kustom apa pun. Tentukan nama atribut kustom. |
Variabel khusus developer
Jika app.appType
adalah
"Developer", 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 kustom bernama dari developer. |
Operasi GenerateAuthorizationCode
Variabel ini ditetapkan saat operasi GenerateAuthorizationCode berhasil dijalankan:
Awalan: oauthv2authcode.{policy_name}.{variable_name}
Contoh: oauthv2authcode.GenerateCodePolicy.code
Variabel | Deskripsi |
---|---|
code |
Kode otorisasi yang dibuat saat kebijakan dieksekusi. |
redirect_uri |
URI pengalihan yang terkait dengan aplikasi klien terdaftar. |
scope |
Cakupan OAuth opsional yang diteruskan dalam permintaan klien. |
client_id |
Client ID yang diteruskan dalam permintaan klien. |
Operasi GenerateAccessToken dan RefreshAccessToken
Variabel ini ditetapkan saat operasi GenerateAccessToken dan RefreshAccessToken berhasil dijalankan. Perhatikan bahwa variabel token refresh tidak berlaku untuk alur jenis pemberian kredensial klien.
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 untuk token. Lihat elemen <ExpiresIn> untuk mengetahui detailnya. Perhatikan bahwa dalam respons, expires_in dinyatakan dalam detik. |
scope |
Daftar cakupan yang tersedia dan dikonfigurasi untuk token. Lihat Menggunakan cakupan OAuth2. |
status |
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 dijalankan. |
api_product_list |
Daftar produk yang terkait dengan aplikasi developer token yang sesuai. |
refresh_count |
|
refresh_token |
Token refresh yang dihasilkan. Perhatikan bahwa token refresh tidak dibuat untuk jenis pemberian kredensial klien. |
refresh_token_expires_in |
Masa berlaku token refresh, dalam detik. |
refresh_token_issued_at |
Nilai waktu ini adalah representasi string dari kuantitas stempel waktu 32-bit yang sesuai. Misalnya, 'Rabu, 21 Agustus 2013 19.16.47 UTC' sesuai dengan nilai stempel waktu 1377112607413. |
refresh_token_status |
approved atau revoked . |
GenerateAccessTokenImplicitGrant
Variabel ini ditetapkan saat operasi GenerateAccessTokenImplicit berhasil dijalankan untuk alur jenis pemberian izin implisit.
Awalan: oauthv2accesstoken.{policy_name}.{variable_name}
Contoh: oauthv2accesstoken.RefreshTokenPolicy.access_token
Variabel | Deskripsi |
---|---|
oauthv2accesstoken.access_token |
Token akses yang dibuat saat kebijakan dieksekusi. |
oauthv2accesstoken.{policy_name}.expires_in |
Nilai masa berlaku token, dalam detik. Lihat elemen <ExpiresIn> untuk mengetahui 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 dieksekusi.
Kode kerusakan | Status HTTP | Penyebab | Ditampilkan 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 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. |
|
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 |
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\ |
401 |
Proxy atau operasi API yang sedang dieksekusi 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 |
|
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 |
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 atau pembaruan token, lihat Kode error untuk alur pembuatan dan pembaruan token JWT di bawah.
- Untuk alur verifikasi token, lihat Kode error untuk alur verifikasi token di bawah.
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. |
|
oauth.v2.InvalidValueForJWTAlgorithm |
401 |
Hal ini terjadi jika algoritma tidak ada di token akses JWT atau jika nilai 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 |
Algoritma yang ditentukan dalam kebijakan Buat tidak cocok dengan algoritma 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 di Token Akses Jwt |
|
oauth.v2.InvalidJWTSignature |
401 |
Hal ini terjadi jika 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 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 melakukannya. |
GrantTypesNotApplicableForOperation |
Pastikan jenis hibah yang ditentukan di <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 |
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 error adalah bagian terakhir dari kode error. | 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>
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 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 Penyimpanan Di-hash
Jika Anda menggunakan Apigee hybrid atau Apigee, token akses OAuthV2 dan token refresh di-hash secara default saat disimpan di database Cassandra runtime. Hashing mencegah token digunakan jika database disusupi.
Menggunakan konfigurasi OAuth default
Setiap organisasi (bahkan organisasi uji coba gratis) di Apigee disediakan dengan endpoint token OAuth. Endpoint dikonfigurasi sebelumnya dengan kebijakan di proxy API yang disebut oauth. Anda dapat mulai menggunakan endpoint token segera setelah membuat akun di Apigee. Untuk mengetahui detailnya, lihat Memahami endpoint OAuth.
Menghapus token akses
Secara default, token OAuth2 dihapus dari sistem Apigee 3 hari (259.200 detik) setelah masa berlaku token akses dan token refresh (jika ada) berakhir.
Perilaku yang tidak mematuhi RFC
Secara default, kebijakan OAuthV2, dengan operasi GenerateAccessToken, menampilkan respons token yang berisi properti tertentu yang tidak mematuhi RFC. Tabel berikut menunjukkan properti yang tidak mematuhi kebijakan OAuthV2 dan properti yang mematuhi kebijakan yang sesuai.
OAuthV2 menampilkan: | Properti yang mematuhi RFC adalah: |
---|---|
"token_type":"BearerToken" |
"token_type":"Bearer"
|
"expires_in":"3600" |
"expires_in":3600
(Nilai yang mematuhi adalah angka, bukan string.) |
Selain itu, respons error untuk token refresh yang sudah tidak berlaku lagi saat grant_type = refresh_token
adalah:
{"ErrorCode" : "invalid_request", "Error" :"Refresh Token expired"}
Namun, respons yang sesuai dengan RFC adalah:
{"error" : "invalid_grant", "error_description" :"refresh token expired"}