Anda sedang melihat dokumentasi Apigee Edge.
Buka
Dokumentasi Apigee X. info
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 Edge.
Tips: Jika ingin mempelajari OAuth di Apigee Edge lebih lanjut, lihat halaman beranda OAuth. Menyediakan link ke referensi, sampel, video, dan lain-lain. Lihat kursus lanjutan Contoh OAuth di GitHub untuk menunjukkan cara kerja kebijakan ini dalam aplikasi.
Contoh
VerifyAccessToken
VerifyAccessToken
Konfigurasi kebijakan OAuthV2 ini (dengan operasi VerifyAccessToken) memverifikasi bahwa token akses yang dikirimkan ke Apigee Edge valid. Saat operasi kebijakan ini dipicu, Edge 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 async="false" continueOnError="false" enabled="true" name="OAuth-v20-2"> <DisplayName>OAuth v2.0 2</DisplayName> <Operation>VerifyAccessToken</Operation> <AccessTokenPrefix>Bearer</AccessTokenPrefix> <!-- Optional, default is Bearer --> </OAuthV2>
Catatan: Hanya Token Pembawa OAuth 2.0 yang didukung. Autentikasi Pesan Token kode (MAC) tidak didukung.
Contoh:
$ curl -H "Authorization: Bearer ylSkZIjbdWybfsUQe9BqP0LH5Z" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282
Secara default, Edge menerima token akses di header Authorization
dengan
awalan Bearer
. Anda dapat mengubah setelan default ini dengan <AccessToken>
.
GenerateAccessToken
Membuat token akses
Misalnya yang menunjukkan cara meminta token akses untuk setiap jenis pemberian yang didukung, lihat Meminta token akses dan kode otorisasi Google. 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 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 harus sudah ditetapkan sebelumnya dan yang tersedia dalam alur:
var client_id = context.getVariable("local_clientid"); var client_secret = context.getVariable("local_secret"); context.setVariable("request.header.Authorization","Basic "+CryptoJS.enc.Base64.stringify(CryptoJS.enc.Latin1 .parse(client_id + ':' + client_secret)));
Lihat juga "Dasar pengkodean 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 umum untuk semua elemen induk kebijakan:
Atribut | Deskripsi | Default | Ketersediaan |
---|---|---|---|
name |
Nama internal kebijakan. Nilai atribut Secara opsional, gunakan elemen |
T/A | Wajib |
continueOnError |
Tetapkan ke Setel ke |
salah | Opsional |
enabled |
Setel ke Setel ke |
true | Opsional |
async |
Atribut ini tidak digunakan lagi. |
salah | Tidak digunakan lagi |
<DisplayName> elemen
Gunakan selain atribut name
untuk memberi label kebijakan di
editor proxy UI dengan nama natural language yang berbeda.
<DisplayName>Policy Display Name</DisplayName>
Default |
T/A Jika Anda menghapus elemen ini, nilai atribut |
---|---|
Ketersediaan | Opsional |
Jenis | String |
<AccessToken> elemen
<AccessToken>request.header.access_token</AccessToken>
Secara default, VerifyAccessToken mengharapkan token akses dikirim di Authorization
{i>header<i}.
Anda dapat mengubah default tersebut menggunakan elemen ini. Sebagai
contoh request.queryparam.access_token
menunjukkan bahwa token akses
harus ada sebagai parameter kueri yang bernama access_token
.
<AccessToken>request.header.access_token</AccessToken>
ditetapkan:
curl https://myorg-myenv.apigee.net/oauth2/validate -H "access_token:Rft3dqrs56Blirls56a"Contoh dengan
<AccessToken>request.queryparam.access_token</AccessToken>
ditetapkan:
curl "https://myorg-myenv.apigee.net/oauth2/validate?access_token:Rft3dqrs56Blirls56a"
Default: |
T/A |
Kehadiran: |
Opsional |
Jenis: | String |
Digunakan dengan operasi: |
|
<AccessTokenPrefix> elemen
<AccessTokenPrefix>Bearer</AccessTokenPrefix>
Secara default, VerifyAccessToken mengharapkan token akses dikirim dalam header Otorisasi sebagai Token pemilik. Contoh:
-H "Authorization: Bearer Rft3dqrs56Blirls56a"
Saat ini, Bearer adalah satu-satunya awalan yang didukung.
Default: |
Operator |
Kehadiran: |
Opsional |
Jenis: | String |
Nilai yang valid: |
Operator |
Digunakan dengan operasi: |
|
<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 Edge harus 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 Edge 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: |
|
<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 Edge harus mencari ID klien. Satu-satunya yang valid
yang dapat Anda tetapkan adalah
variabel flow request.formparam.client_id
. Menyetel ClientId
ke variabel lain tidak didukung.
Lihat juga Meminta token akses dan otorisasi
kode tersebut.
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 Edge). Elemen ini memungkinkan Anda menentukan di mana Edge 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
Meminta token akses dan
kode otorisasi Google.
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
.
Dengan Apigee Edge for Public Cloud, Edge mempertahankan entity berikut dalam cache minimal selama 180 detik setelah entity diakses.
- Token akses OAuth. Artinya, token yang dicabut mungkin masih berhasil hingga tiga menit, hingga batas {i>cache<i} kedaluwarsa.
- 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>
Edge tidak mendukung cara memaksa habis masa berlaku token setelah 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 Edge otomatis 3 hari setelah masa berlaku habis. Lihat juga Menghapus akses token
Private Cloud: Untuk penginstalan Edge untuk Private Cloud, setelan default
ditetapkan oleh properti conf_keymanagement_oauth_auth_code_expiry_time_in_millis
.
Untuk menetapkan properti ini:
- Buka file
message-processor.properties
di editor. Jika file tidak ada, buat file tersebut:vi /opt/apigee/customer/application/message-processor.properties
- Tetapkan properti sesuai keinginan:
conf_keymanagement_oauth_auth_code_expiry_time_in_millis=3600000
- Pastikan file properti dimiliki oleh "apigee" pengguna:
chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
- Mulai ulang Pemroses Pesan.
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
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 Edge tempat menemukan token akses eksternal (token akses yang tidak dibuat oleh Apigee Edge).
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, Edge memvalidasi client_id dan client_secret biasanya terhadap penyimpanan otorisasi Apigee Edge. 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 Edge tempat menemukan kode autentikasi eksternal (kode autentikasi yang tidak dibuat oleh Apigee Edge).
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 Edge tempat menemukan token refresh eksternal (token refresh yang tidak dibuat oleh Apigee Edge).
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 disetel ke true
, kebijakan akan membuat dan menampilkan respons. Misalnya, untuk
GenerateAccessToken, responsnya mungkin seperti ini:
{ "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 false
, tidak ada respons yang akan 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: |
salah |
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 Meminta token akses dan otorisasi
kode tersebut.
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: |
|
<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 Edge dapat menemukan nilai-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; Edge sederhana yang memverifikasi keberadaan mereka. Terserah pengembang API untuk mengambil permintaan nilai dan mengirimkannya ke penyedia identitas sebelum kebijakan pembuatan token dijalankan.
Lihat juga Meminta token akses dan kode otorisasi.
Default: |
request.formparam.password (x-www-form-urlencrypted 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 |
<RedirectUri> elemen
<RedirectUri>request.queryparam.redirect_uri</RedirectUri>
Menentukan tempat Edge harus mencari parameter redirect_uri
di kolom
permintaan.
Tentang URI pengalihan
URI pengalihan digunakan dengan kode otorisasi dan jenis pemberian implisit. Pengalihan URI memberi tahu server otorisasi (Edge) 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 mendaftarkan aplikasi developer di Edge dan menentukan URL Callback, lihat Mendaftarkan aplikasi dan mengelola API . - (opsional) Jika URL Callback terdaftar, dan
redirect_uri
tidak ada dari permintaan, lalu Edge mengalihkan ke URL Callback yang terdaftar. - (wajib) Jika URL Callback tidak terdaftar, berarti
redirect_uri
tidak diperlukan. Perhatikan bahwa dalam kasus ini, Edge 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
juga Meminta token akses dan
kode otorisasi Google.
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 di mana Edge 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
juga Meminta token akses dan
kode otorisasi Google.
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 sistem
nilai yang dihasilkan ditambah nilai <RefreshTokenExpiresIn>
. Jika
<RefreshTokenExpiresIn>
disetel ke -1, token refresh
masa berlaku habis sesuai masa berlaku token refresh OAuth maksimum. Jika <RefreshTokenExpiresIn>
tidak ditentukan,
sistem menerapkan nilai {i>default<i}
yang dikonfigurasi di tingkat sistem. Hubungi Dukungan Apigee Edge untuk mengetahui informasi selengkapnya
informasi tentang setelan sistem default.
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"> 3600000 <!--default value in milliseconds--> </RefreshTokenExpiresIn>
Private Cloud: Untuk penginstalan Edge untuk Private Cloud, setelan default
ditetapkan oleh properti conf_keymanagement_oauth_refresh_token_expiry_time_in_millis
.
Untuk menetapkan properti ini:
- Buka file
message-processor.properties
di editor. Jika file tidak ada, buat file tersebut:vi /opt/apigee/customer/application/message-processor.properties
- Tetapkan properti sesuai keinginan:
conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000
- Pastikan file properti dimiliki oleh "apigee" pengguna:
chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
- Mulai ulang Pemroses Pesan.
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
Default: |
63072000000 md (2 tahun) (berlaku 5 Agustus 2024) |
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 Edge jenis pemberian izin yang diminta aplikasi klien. Tabel ini hanya digunakan dengan alur kode otorisasi dan jenis pemberian implisit.
Secara default, Edge 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
, Edge mencari jenis respons yang
yang diteruskan di header permintaan. Lihat juga Meminta token akses dan otorisasi
kode tersebut.
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 diterbitkan oleh Apigee Edge saat token refresh yang valid
disajikan.
Default: |
|
Kehadiran: |
opsional |
Jenis: | boolean |
Nilai yang valid: |
|
Digunakan dengan jenis pemberian izin: |
|
<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 cakupan dan Meminta token akses dan kode otorisasi.
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, elemen ini memungkinkan Anda menentukan di mana Edge harus mencari nilai-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 di header HTTP, misalnya, tetapkan nilai ini
ke request.header.state
. Lihat juga Lihat juga Meminta token akses dan otorisasi
kode tersebut.
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 Edge 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 Edge. 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 Edge harus mencari parameter grant_type
yang diteruskan
terhadap permintaan klien. Edge 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 Edge dapat menemukan nilai-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 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; Edge sederhana yang memverifikasi keberadaan mereka. Terserah pengembang API untuk mengambil permintaan nilai dan mengirimkannya ke penyedia identitas sebelum kebijakan pembuatan token dijalankan.
Lihat juga Meminta token akses dan kode otorisasi.
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 Meminta token akses dan kode otorisasi.
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
Operasi VerifyAccessToken dijalankan, sejumlah besar variabel alur terisi dalam konteks eksekusi proxy. Variabel ini memberi Anda properti yang terkait dengan akses token, aplikasi developer, developer, dan perusahaan. 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.
proxy.pathsuffix
). Setelan variabel flow.resource.name secara eksplisit tidak diperlukan.
Jika produk API tidak dikonfigurasi dengan lingkungan dan proxy API yang valid, maka
flow.resource.name
harus ditetapkan secara eksplisit untuk mengisi variabel produk API di
alur kerja. Untuk detail tentang konfigurasi produk, lihat Menggunakan pengelolaan Edge
API untuk Publish API.
Variabel khusus token
Variabel | Deskripsi |
---|---|
organization_name |
Nama organisasi tempat proxy dijalankan. |
developer.id |
ID developer yang terkait dengan aplikasi klien yang terdaftar. |
developer.app.name |
Nama developer yang terkait dengan aplikasi klien terdaftar. |
client_id |
Client ID aplikasi klien yang terdaftar. |
grant_type |
Jenis pemberian yang terkait dengan permintaan. |
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. 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 developer
Jika app.appType adalah "Company", atribut perusahaan akan diisi dan 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. |
Variabel khusus perusahaan
Jika app.appType adalah "Company", atribut perusahaan akan diisi dan jika app.appType adalah "Developer", lalu atribut developer akan diisi.
Variabel | Deskripsi |
---|---|
company.id |
|
company.displayName |
|
company.apps |
|
company.appOwnerStatus |
|
company.created_by |
|
company.created_at |
|
company.last_modified_at |
|
company.last_modified_by |
|
company.{custom_attributes} |
Atribut khusus bernama perusahaan. |
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 kesalahan yang dikembalikan dan variabel kesalahan yang disetel oleh Edge saat kebijakan ini memicu kesalahan. Informasi ini penting untuk diketahui jika Anda mengembangkan aturan kesalahan untuk menangani kesalahan. Untuk mempelajari lebih lanjut, lihat Yang perlu Anda ketahui tentang error kebijakan dan Penanganan kesalahan.
Error runtime
Error ini dapat terjadi saat kebijakan dijalankan.
Kode error | Status HTTP | Penyebab | Dimunculkan oleh operasi |
---|---|---|---|
steps.oauth.v2.access_token_expired |
401 | Masa berlaku token akses telah berakhir. |
VerifyAccessToken |
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 masing-masing. | VerifyAccessToken |
steps.oauth.v2.FailedToResolveAccessToken |
500 | Kebijakan ini diharapkan menemukan token akses dalam variabel yang ditentukan dalam
<AccessToken> , tetapi variabel tidak dapat diselesaikan. |
GenerateAccessToken |
steps.oauth.v2.FailedToResolveAuthorizationCode |
500 | Kebijakan ini diharapkan menemukan kode otorisasi dalam variabel yang ditentukan dalam
<Code> , tetapi variabel tidak dapat diselesaikan. |
GenerateAuthorizationCode |
steps.oauth.v2.FailedToResolveClientId |
500 | Kebijakan ini diharapkan menemukan Client-ID dalam variabel yang ditentukan dalam
<ClientId> , tetapi variabel tidak dapat diselesaikan. |
GenerateAccessToken GenerateAuthorizationCode GenerateAccessTokenImplicitGrant RefreshAccessToken |
steps.oauth.v2.FailedToResolveRefreshToken |
500 | Kebijakan ini diharapkan menemukan token refresh dalam variabel yang ditentukan dalam
<RefreshToken> , tetapi variabel tidak dapat diselesaikan. |
RefreshAccessToken |
steps.oauth.v2.FailedToResolveToken |
500 | Kebijakan ini diharapkan menemukan token dalam variabel yang ditentukan dalam
<Tokens> , tetapi variabel tidak dapat diselesaikan. |
ValidateToken |
steps.oauth.v2.InsufficientScope |
403 | Token akses yang ditampilkan dalam permintaan memiliki cakupan yang tidak sesuai 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 Catatan: Sebaiknya Anda mengubah aturan kesalahan yang sudah ada
kondisi untuk menangkap |
GenerateAccessToken RefreshAccessToken |
steps.oauth.v2.invalid_request |
400 | Nama {i>error<i} ini digunakan untuk
berbagai jenis {i>error<i}, biasanya untuk {i>error<i}
atau parameter yang salah
yang dikirim dalam permintaan. Jika <GenerateResponse> adalah
disetel ke false , gunakan variabel fault (dijelaskan di bawah) untuk mengambil detail tentang
{i>error<i}, seperti nama
kesalahan dan penyebabnya. |
GenerateAccessToken GenerateAuthorizationCode GenerateAccessTokenImplicitGrant RefreshAccessToken |
steps.oauth.v2.InvalidAccessToken |
401 | Header otorisasi tidak berisi kata "Bearer", yang wajib diisi. Sebagai
contoh: Authorization: Bearer your_access_token |
VerifyAccessToken |
steps.oauth.v2.InvalidAPICallAsNo\ |
401 |
Proxy API tidak ada dalam Produk yang terkait dengan token akses. Tips: Pastikan produk yang terkait dengan token akses telah dikonfigurasi dengan benar. Misalnya, jika Anda menggunakan karakter pengganti di jalur resource, pastikan {i>wildcard <i}digunakan dengan benar. Lihat Membuat produk API untuk mengetahui detailnya. Lihat juga ini Postingan Komunitas Apigee untuk mendapatkan panduan lebih lanjut tentang penyebab error ini. |
VerifyAccessToken |
steps.oauth.v2.InvalidClientIdentifier |
500 |
Nama error ini ditampilkan saat properti |
GenerateAccessToken |
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 token
(misalnya, refreshtoken ). Jika klien meneruskan jenis yang salah,
ditampilkan error. |
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 <SupportedGrantTypes> ). Catatan: Saat ini terdapat bug berupa error jenis pemberian izin yang tidak didukung tidak ditampilkan dengan benar. Jika terjadi error jenis pemberian izin yang tidak didukung, proxy tidak akan memasuki Alur Kesalahan, seperti yang diharapkan. |
GenerateAccessToken GenerateAuthorizationCode GenerateAccessTokenImplicitGrant RefreshAccessToken |
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 positif
bilangan bulat dan -1 . |
InvalidGrantType |
Jenis pemberian yang tidak valid ditentukan dalam <SupportedGrantTypes>
. Lihat referensi kebijakan untuk mengetahui daftar jenis yang valid. |
ExpiresInNotApplicableForOperation |
Pastikan operasi yang ditentukan dalam <Operations> dukungan elemen masa berlaku. Misalnya, operasi VerifyToken tidak demikian. |
RefreshTokenExpiresInNotApplicableForOperation |
Pastikan operasi yang ditentukan dalam <Operations> refresh dukungan elemen masa berlaku token habis. Misalnya, operasi VerifyToken tidak demikian. |
GrantTypesNotApplicableForOperation |
Pastikan jenis hibah yang ditentukan di <SupportedGrantTypes> didukung untuk operasi yang ditentukan. |
OperationRequired |
Anda harus menentukan operasi dalam kebijakan ini menggunakan Catatan: Jika elemen |
InvalidOperation |
Anda harus menetapkan operasi yang valid dalam kebijakan ini menggunakan metode
Elemen Catatan: Jika elemen |
TokenValueRequired |
Anda harus menentukan nilai <Token> token di
elemen <Tokens> . |
Variabel kesalahan
Variabel ini ditetapkan saat kebijakan ini memicu error saat runtime.
<GenerateResponse>
ditetapkan ke
false
Jika <GenerateResponse>
adalah
true
, kebijakan akan langsung menampilkan respons kepada klien jika terjadi error --
alur error dilewati dan variabel ini tidak diisi. Untuk informasi selengkapnya, lihat
Hal yang perlu
mengetahui error kebijakan.Variabel | Di 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
Catatan: Untuk operasi VerifyAccessToken, nama kesalahan menyertakan akhiran ini: |
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 dikirim kembali ke klien jika <GenerateResponse>
adalah true.
errorcode
dari respons error. Jangan mengandalkan teks di
faultstring
, karena bisa saja berubah.Jika <GenerateResponse>
true, kebijakan akan menampilkan error
dalam format ini untuk operasi yang
menghasilkan token dan kode. Untuk daftar lengkapnya, lihat
Error HTTP OAuth
referensi respons.
{"ErrorCode" : "invalid_client", "Error" :"ClientId is Invalid"}
Jika <GenerateResponse>
true, kebijakan akan menampilkan error
dalam format ini untuk memverifikasi
dan memvalidasi operasi. Untuk daftar lengkap, lihat Error HTTP OAuth
referensi respons.
{ { "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>
Skema kebijakan
Setiap jenis kebijakan ditentukan oleh skema XML (.xsd
). Sebagai referensi, kebijakan
skema tersedia di GitHub.
Bekerja dengan OAuth default konfigurasi
Setiap organisasi (bahkan organisasi uji coba gratis) di Apigee Edge 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 Edge. Sebagai detail, lihat Memahami OAuth endpoint.
Menghapus token akses
Secara default, token OAuth2 dihapus dari sistem Apigee Edge selama 3 hari (259.200 detik) setelah masa berlaku token akses dan token pembaruan (jika ada). Dalam beberapa kasus, Anda mungkin ingin mengubah {i>default<i} ini. Misalnya, Anda mungkin ingin mempersingkat waktu penghapusan menghemat ruang {i>disk<i} jika token yang dihasilkan dalam jumlah besar.
Jika Anda menggunakan Edge for Private Cloud, Anda dapat mengubah setelan default ini dengan menyetel seperti yang dijelaskan di bagian ini. (Penghapusan token yang sudah tidak berlaku selama 3 hari berlaku untuk Edge untuk Private Cloud versi 4.19.01 dan yang lebih baru. Untuk versi sebelumnya, interval penghapusan default adalah 180 hari.)
Memperbarui setelan penghapusan permanen untuk Edge Private Cloud 4.16.01 dan versi yang lebih baru
Catatan: Hanya token yang dibuat setelah setelan ini yang diterapkan terpengaruh; pengaturan tidak berlaku untuk token yang dihasilkan sebelumnya.
- Buka file ini untuk mengedit:
/opt/apigee/customer/application/message-processor.properties
- Tambahkan properti berikut untuk menetapkan jumlah detik untuk menunggu sebelum menghapus token
setelah masa berlakunya habis:
conf_keymanagement_oauth.access.token.purge.after.seconds=<number of seconds>
- Mulai ulang pemroses pesan. Contoh:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
<ExpiresIn>
dan
Atribut <RefreshTokenExpiresIn>
.
Memperbarui penghapusan permanen pengaturan Edge Private Cloud 4.15.07
Catatan: Hanya token yang dibuat setelah setelan ini diterapkan terpengaruh; pengaturan tidak berlaku untuk token yang dihasilkan sebelumnya.
-
Tetapkan nilai positif untuk
<ExpiresIn>
dan<RefreshTokenExpiresIn>
dalam kebijakan OAuthV2. Nilai dalam dalam milidetik. Contoh:<ExpiresIn>1000</ExpiresIn> <RefreshTokenExpiresIn>10000</RefreshTokenExpiresIn>
-
Deploy ulang proxy.
-
Gunakan API ini untuk memperbarui properti penghapusan permanen token untuk organisasi Anda:
POST https://<host-name>/v1/organizations/<org-name>
Muatan:
<Organization name="AutomationOrganization"> <Description>Desc</Description> <Properties> <Property name="keymanagement.oauth20.access.token.purge">true</Property> <Property name="keymanagement.oauth20.access.token.purge.after.seconds">120</Property> </Properties> </Organization>
-
Mulai ulang pemroses pesan. Contoh:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
API ini menetapkan properti penghapusan token ke benar (true) untuk organisasi yang disebut {i>AutomationOrganization<i}. Dalam hal ini, token akses akan dihapus permanen dari database 120 detik setelah masa berlaku token dan token refresh berakhir.
Perilaku yang tidak sesuai dengan RFC
Kebijakan OAuthV2 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"}