Mengimplementasikan jenis pemberian sandi

Anda 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) kepada aplikasi klien, yang mengirimkannya dalam permintaan token akses ke Apigee Edge. Server identitas memvalidasi kredensial, dan jika valid, Edge akan melanjutkan untuk membuat token akses dan menampilkannya ke aplikasi.

Tentang topik ini

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

Contoh yang mungkin berguna

  • Meminta token akses: 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 keluar. Contoh ini adalah contoh end-to-end yang menampilkan jenis pemberian sandi. Contoh ini menunjukkan praktik terbaik, yaitu mengautentikasi kredensial aplikasi klien (kunci/secret) sebelum mengirimkan 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 diwajibkan untuk 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 Edge yang berfungsi sebagai server otorisasi.

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

Prasyarat: Aplikasi klien harus didaftarkan ke Apigee Edge untuk mendapatkan kunci client ID dan client secret. Lihat Mendaftarkan aplikasi klien untuk 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 Edge

Aplikasi mengirimkan 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 tersebut dapat dilakukan sebagai berikut, menggunakan opsi -u untuk curl guna 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 Autentikasi Dasar yang diperlukan, lihat bagian pemberian sandi di "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 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 secret klien. Ada contoh proxy yang menggambarkan teknik alternatif ini di repositori api-platform-samples 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, layanan tersebut dapat 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 terus memproses 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. 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 Edge (proxy), dan Edge bertanggung jawab untuk memvalidasi token akses sebelum meneruskan panggilan API ke server resource target. Token akses diteruskan dalam header Authorization. Contoh:

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