Halaman ini diterjemahkan oleh Cloud Translation API.

Menerapkan jenis pemberian sandi

Halaman ini berlaku untuk Apigee dan Apigee Hybrid.

Baca dokumentasi Apigee Edge.

Jenis pemberian sandi pemilik resource (atau "sandi") paling banyak digunakan dalam kasus ketika aplikasi sangat tepercaya. Dalam konfigurasi ini, pengguna memberikan kredensial server resource mereka (nama pengguna/sandi) ke aplikasi klien, yang mengirimi mereka permintaan token akses ke Apigee. Server identitas akan memvalidasi kredensial, dan jika kredensial tersebut valid, Apigee akan melanjutkan membuat token akses dan menampilkannya ke aplikasi.

Tentang topik ini

Topik ini memberikan deskripsi umum dan ringkasan tentang alur jenis pemberian sandi pemilik resource OAuth 2.0 dan membahas cara menerapkan alur ini di Apigee.

Contoh yang mungkin berguna bagi Anda

Gunakan jenis pemberian sandi: Menunjukkan cara membuat permintaan token, mengonfigurasi kebijakan OAuthV2 untuk jenis pemberian sandi, dan cara mengonfigurasi endpoint untuk kebijakan di Apigee.
oauth-validate-key-secret: Contoh proxy di GitHub yang dapat di-deploy ke Apigee dan mencobanya. Ini adalah contoh end-to-end yang menampilkan jenis pemberian sandi. Hal ini menunjukkan praktik terbaik, yaitu mengautentikasi kredensial aplikasi klien (kunci/rahasia) sebelum mengirim kredensial pengguna ke penyedia identitas.

Video

Video: Tonton video ini tentang cara menerapkan jenis pemberian sandi.

Kasus penggunaan

Jenis pemberian ini ditujukan untuk aplikasi dengan hak istimewa atau tepercaya karena pengguna diwajibkan memberikan kredensial server resource ke aplikasi. Biasanya, aplikasi menyediakan layar login tempat pengguna memasukkan kredensial.

Diagram alir

Diagram alur berikut mengilustrasikan alur jenis pemberian sandi pemilik resource dengan Apigee yang berfungsi sebagai server otorisasi.

Tips: Untuk melihat versi diagram yang lebih besar, klik kanan dan buka diagram di tab baru, atau simpan dan buka diagram di penampil gambar.

Alur jenis pemberian sandi pemilik resource.

Langkah-langkah dalam alur jenis pemberian sandi

Berikut adalah ringkasan langkah-langkah yang diperlukan untuk menerapkan jenis pemberian sandi saat Apigee berfungsi sebagai server otorisasi.

Prasyarat: Aplikasi klien harus terdaftar di Apigee untuk mendapatkan client ID dan kunci rahasia klien. Lihat Mendaftarkan aplikasi klien untuk mengetahui detailnya.

1. Pengguna memulai alur dan memasukkan kredensial

Saat aplikasi perlu mengakses resource yang dilindungi pengguna (misalnya, pengguna mengklik tombol di aplikasi), pengguna akan dialihkan ke formulir login.

2. Aplikasi meminta token akses dari Apigee

Aplikasi akan mengirimkan permintaan token akses, termasuk kredensial pengguna, ke endpoint GenerateAccessToken di Apigee.

Berikut adalah contoh permintaan POST, yang mencakup parameter yang diperlukan untuk jenis pemberian ini:

$ curl -i \
  -X POST \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAySVg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ' \
  -d 'grant_type=password&username=the-user-name&password=the-users-password' \
  https://docs-test.apigee.net/oauth/token

Atau, perintah tersebut dapat dilakukan sebagai berikut, menggunakan opsi -u untuk melakukan curl guna membuat header Autentikasi Dasar berenkode base64 untuk Anda.

$ curl -i \
  -X POST \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -u sqH8ooHexTz8C02IX9ORo6rhgq1iSrAl:Z4ljtJdneBOjPMAU \
  -d 'grant_type=password&username=the-user-name&password=the-users-password' \
  https://docs-test.apigee.net/oauth/token

(Setiap perintah tersebut harus berada dalam satu baris.)

Kredensial pengguna dimuat dalam parameter formulir, sedangkan kredensial klien dienkode dalam header autentikasi dasar HTTP. Untuk deskripsi mendetail tentang panggilan API ini, termasuk detail tentang header Auth Dasar yang diperlukan, lihat bagian pemberian sandi "Mendapatkan token OAuth 2.0".

3. Apigee memvalidasi aplikasi klien

Sebelum mengirimkan nama pengguna dan sandi pengguna ke penyedia identitas, Edge perlu mengetahui bahwa aplikasi klien yang mengajukan permintaan adalah aplikasi valid dan tepercaya. Salah satu cara untuk melakukannya adalah dengan menggunakan autentikasi kunci API pada panggilan API. Dalam beberapa kasus, Anda mungkin ingin memvalidasi kunci dan rahasia klien. Ada proxy contoh yang menggambarkan teknik aternate ini di repositori contoh api-platform-di GitHub.

4. Apigee memproses kredensial login

Setelah aplikasi klien divalidasi, Anda dapat menggunakan kebijakan Pemanggilan Layanan atau JavaScript untuk memanggil layanan identitas, yang mengirimkan kredensial pengguna. Misalnya, kredensial dapat berupa layanan LDAP atau layanan apa pun yang ingin Anda gunakan untuk memvalidasi kredensial. Untuk mengetahui detail tentang kebijakan ini, lihat kebijakan Mengekstrak Variabel dan kebijakan JavaScript.

Jika layanan identitas memvalidasi kredensial, dan menampilkan respons 200, maka Apigee akan terus memproses permintaan; jika tidak, Apigee akan berhenti memproses dan menampilkan error ke aplikasi klien.

5. Kebijakan OAuthV2 berjalan

Jika kredensial valid, langkah pemrosesan berikutnya adalah menjalankan kebijakan OAuthV2 yang dikonfigurasi untuk jenis pemberian sandi. Berikut adalah contohnya. Elemen <UserName> dan <PassWord> wajib ada, dan Anda dapat mengambilnya dari variabel alur yang disimpan dengan kebijakan ExtractVariables. Untuk informasi referensi mendetail tentang kebijakan ini, lihat kebijakan OAuthV2.

<OAuthV2 name="GetAccessToken">
  <Operation>GenerateAccessToken</Operation>
  <ExpiresIn>360000000</ExpiresIn> 
  <SupportedGrantTypes> 
     <GrantType>password</GrantType> 
  </SupportedGrantTypes> 
  <GrantType>request.queryparam.grant_type</GrantType> 
  <UserName>login</UserName>
  <PassWord>password</PassWord>
  <GenerateResponse/> 
</OAuthV2>

Jika kebijakan ini berhasil, respons akan dibuat kembali ke klien yang berisi token akses. Responsnya dalam format JSON. Berikut contohnya. Perhatikan bahwa access_token adalah salah satu elemen:

{
    "issued_at": "1420258685042",
    "scope": "READ",
    "application_name": "ce1e94a2-9c3e-42fa-a2c6-1ee01815476b",
    "refresh_token_issued_at": "1420258685042",
    "status": "approved",
    "refresh_token_status": "approved",
    "api_product_list": "[PremiumWeatherAPI]",
    "expires_in": "1799",
    "developer.email": "tesla@weathersample.com",
    "organization_id": "0",
    "token_type": "BearerToken",
    "refresh_token": "IFl7jlijYuexu6XVSSjLMJq8SVXGOAAq",
    "client_id": "5jUAdGv9pBouF0wOH5keAVI35GBtx3dT",
    "access_token": "I6daIgMSiUgYX1K2qgQWPi37ztS6",
    "organization_name": "docs",
    "refresh_token_expires_in": "0",
    "refresh_count": "0"
}

6. Klien memanggil API yang dilindungi

Kini, dengan kode akses yang valid, klien dapat melakukan panggilan ke API yang dilindungi. Dalam skenario ini, permintaan dibuat ke Apigee (proxy), dan Apigee bertanggung jawab memvalidasi token akses sebelum meneruskan panggilan API ke server resource target. Token akses diteruskan di header Otorisasi. Contoh:

$ curl -H "Authorization: Bearer I6daIgMSiUgYX1K2qgQWPi37ztS6
" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282