Mengimplementasikan jenis pemberian sandi

Anda sedang melihat dokumentasi Apigee Edge.
Buka dokumentasi Apigee X.
info

Jenis pemberian sandi (atau "sandi") pemilik resource sebagian besar digunakan dalam kasus ketika aplikasi sangat tepercaya. Dalam konfigurasi ini, pengguna memberikan kredensial server resource (nama pengguna/sandi) ke aplikasi klien, yang mengirimkannya dalam permintaan token akses ke Apigee Edge. Server identitas akan memvalidasi kredensial, dan jika kredensial tersebut valid, Edge akan melanjutkan pembuatan token akses dan mengembalikannya 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 Edge.

Contoh yang mungkin berguna bagi Anda

  • Meminta accesstoken: Jenis pemberian sandi: Menunjukkan cara membuat permintaan token, mengonfigurasi kebijakan OAuthV2 untuk jenis pemberian sandi, dan cara mengonfigurasi endpoint untuk kebijakan di Edge.
  • oauth-validate-key-secret: Contoh proxy di GitHub yang dapat Anda deploy ke Edge dan coba. Ini adalah contoh end-to-end yang menampilkan jenis pemberian {i>password<i}. Langkah ini menunjukkan praktik terbaik, yaitu mengautentikasi kredensial (kunci/rahasia) aplikasi klien 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 yang sangat tepercaya atau memiliki hak istimewa karena pengguna harus memberikan kredensial server resource ke aplikasi. Biasanya, aplikasi menyediakan layar login tempat pengguna memasukkan kredensial.

Diagram alir

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

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

Langkah-langkah dalam alur jenis pemberian sandi

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

Prasyarat: Aplikasi klien harus terdaftar di Apigee Edge 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 milik pengguna (misalnya, pengguna mengklik tombol dalam aplikasi), pengguna akan dialihkan ke formulir login.

2. Aplikasi meminta token akses dari Apigee Edge

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

Berikut 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

(Semua 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 Basic Auth yang diperlukan, lihat bagian pemberian sandi pada "Meminta token akses dan kode otorisasi".

3. Edge memvalidasi aplikasi klien

Sebelum mengirimkan nama pengguna dan sandi pengguna ke penyedia identitas, Edge perlu mengetahui bahwa aplikasi klien yang membuat permintaan tersebut adalah aplikasi yang 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 contoh proxy yang menggambarkan teknik yang terkait ini di repositori contoh api-platform-di GitHub.

4. Edge memproses kredensial login

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

Jika layanan identitas memvalidasi kredensial, dan menampilkan respons 200, Edge akan melanjutkan pemrosesan permintaan; jika tidak, Edge akan berhenti memproses 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. 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. 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 diajukan ke Apigee Edge (proxy), dan Edge 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