Halaman ini diterjemahkan oleh Cloud Translation API.

Menerapkan jenis pemberian sandi

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

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

Tentang topik ini

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

Contoh yang mungkin berguna bagi Anda

Meminta accesstoken: Jenis pemberian sandi: Menunjukkan cara membentuk 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 posisi-posisi ini. Ini adalah contoh menyeluruh yang menampilkan jenis pemberian {i>password<i}. Ini menunjukkan jawaban terbaik yaitu mengautentikasi kredensial (kunci/rahasia) aplikasi klien sebelum mengirimkan kredensial pengguna ke penyedia identitas.

Video

Video: Tonton video ini tentang cara menerapkan pemberian sandi .

Kasus penggunaan

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

Diagram alir

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

Tips: Untuk melihat versi diagram yang lebih besar, klik kanan dan buka diagram 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 di Apigee Edge berfungsi sebagai server otorisasi.

Prasyarat: Aplikasi klien harus terdaftar di Apigee Edge untuk mendapatkan ID klien dan kunci rahasia klien. Lihat Mendaftarkan aplikasi klien untuk spesifikasi pendukung.

1. Pengguna memulai alur dan memasukkan kredensial

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

2. Permintaan aplikasi token akses dari Apigee Edge

Aplikasi mengirim permintaan token akses, termasuk kredensial pengguna, ke Endpoint GenerateAccessToken di Apigee Edge.

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 itu dapat dilakukan sebagai berikut, menggunakan opsi -u untuk melakukan curl untuk membuat {i>header<i} Otentikasi 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

(Masing-masing perintah tersebut harus berada dalam satu baris.)

Kredensial pengguna terdapat di dalam parameter formulir, sedangkan kredensial klien yang dienkode di header otentikasi dasar HTTP. Untuk mendapatkan penjelasan mendetail tentang panggilan API ini, termasuk detail tentang header Auth Dasar yang diperlukan, lihat bagian pemberian sandi pada "Meminta token akses dan kode otorisasi".

3. Edge memvalidasi klien aplikasi

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

4. Edge memproses kredensial login

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

Jika layanan identitas memvalidasi kredensial, dan menampilkan respons 200, Edge akan melanjutkan memroses permintaan; jika tidak, Edge akan menghentikan pemrosesan dan mengembalikan kesalahan ke aplikasi klien.

5. Kebijakan OAuthV2 dijalankan

Jika kredensial valid, langkah pemrosesan berikutnya adalah menjalankan kebijakan OAuthV2 dikonfigurasikan untuk jenis pemberian {i>password<i}. Ini contohnya. Bagian <UserName> dan <PassWord> diperlukan, dan Anda dapat mengambilnya dari variabel alur yang disimpan dengan kebijakan ExtractVariables. Untuk informasi referensi terperinci 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 akses sebelumnya yang benar. Respons akan 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 metode API yang dilindungi

Kini, dengan kode akses yang valid, klien dapat melakukan panggilan ke API yang dilindungi. Di sini ini, permintaan dibuat 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