Mengimplementasikan jenis pemberian sandi

Halaman ini berlaku untuk Apigee dan Apigee hybrid.

Lihat dokumentasi Apigee Edge.

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

Tentang topik ini

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

Contoh yang mungkin berguna bagi Anda

  • Menggunakan 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 Anda deploy ke Apigee dan coba. Contoh ini adalah contoh end-to-end yang menampilkan jenis pemberian sandi. Hal ini menunjukkan praktik terbaik, yaitu mengautentikasi kredensial (kunci/secret) aplikasi klien sebelum mengirim kredensial pengguna ke penyedia identitas.

Video

Video: Tonton video ini tentang penerapan jenis pemberian sandi.

Kasus penggunaan

Jenis pemberian ini ditujukan untuk aplikasi yang sangat tepercaya atau memiliki hak istimewa karena pengguna harus memberikan kredensial server resource mereka ke aplikasi. Biasanya, aplikasi menyediakan layar login tempat pengguna memasukkan kredensial mereka.

Diagram alur

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

Tips: Untuk melihat versi diagram yang lebih besar, klik kanan diagram tersebut dan buka di tab baru, atau simpan dan buka 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 didaftarkan ke Apigee untuk mendapatkan kunci client ID dan rahasia klien. Lihat Mendaftarkan aplikasi klien untuk mengetahui detailnya.

1. Pengguna memulai alur dan memasukkan kredensial

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

2. Aplikasi meminta token akses dari Apigee

Aplikasi 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 ke curl untuk membuat header Autentikasi Dasar yang dienkode 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 terdapat dalam parameter formulir, sedangkan kredensial klien dienkode dalam header autentikasi dasar HTTP. Untuk mengetahui deskripsi mendetail tentang panggilan API ini, termasuk detail tentang header Basic Auth yang diperlukan, lihat bagian pemberian sandi di "Mendapatkan token OAuth 2.0".

3. Apigee memvalidasi aplikasi klien

Sebelum mengirim nama pengguna dan sandi pengguna ke penyedia identitas, Edge perlu mengetahui bahwa aplikasi klien yang membuat permintaan adalah aplikasi yang valid dan tepercaya. Salah satu caranya 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 alternatif ini di repositori api-platform-samples di GitHub.

4. Apigee memproses kredensial login

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

Jika layanan identitas memvalidasi kredensial, dan menampilkan respons 200, Apigee akan melanjutkan pemrosesan permintaan; jika tidak, Apigee akan menghentikan pemrosesan dan menampilkan error ke aplikasi klien.

5. Kebijakan OAuthV2 dijalankan

Jika kredensial valid, langkah pemrosesan berikutnya adalah menjalankan kebijakan OAuthV2 yang dikonfigurasi untuk jenis pemberian sandi. Ini contohnya. Elemen <UserName> dan <PassWord> diperlukan, dan Anda dapat mengambilnya dari variabel alur yang disimpan dengan kebijakan ExtractVariables. Untuk mengetahui 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. Respons 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

Sekarang, 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 untuk 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