Halaman ini diterjemahkan oleh Cloud Translation API.

Menerapkan jenis pemberian kode otorisasi

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

Kode otorisasi adalah salah satu jenis pemberian OAuth 2.0 yang paling umum digunakan. Otorisasi alur kode adalah "three-legged OAuth" konfigurasi Anda. Dalam konfigurasi ini, pengguna mengautentikasi sendiri dengan server resource dan memberikan izin kepada aplikasi untuk mengakses resource yang dilindungi tanpa membocorkan nama pengguna/sandi ke aplikasi klien.

Tentang topik ini

Topik ini menawarkan deskripsi umum dan ringkasan tentang jenis pemberian otorisasi OAuth 2.0 dan membahas cara mengimplementasikan alur ini di Apigee Edge.

Video

Tonton video singkat untuk mempelajari cara menggunakan jenis pemberian otorisasi OAuth 2.0 untuk mengamankan API Anda.

Kasus penggunaan

Jenis pemberian ini ditujukan untuk aplikasi yang ditulis oleh developer pihak ketiga yang tidak memiliki hubungan bisnis yang tepercaya dengan penyedia API. Misalnya, developer yang mendaftar untuk program API publik umumnya tidak boleh dipercaya. Dengan jenis pemberian ini, kredensial pada server sumber daya tidak pernah dibagikan ke aplikasi.

Contoh kode

Anda dapat menemukan contoh implementasi jenis pemberian kode otorisasi yang lengkap dan berfungsi di Apigee Edge di repo api-platform-samples di GitHub. Lihat kursus oauth-advanced sample di direktori api-platform-samples/sample-proxies. Lihat README untuk mengetahui detail tentang sampel.

Diagram alir

Diagram alur berikut mengilustrasikan alur OAuth kode otorisasi dengan Apigee Edge yang 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 kode otorisasi

Berikut adalah ringkasan langkah-langkah yang diperlukan untuk menerapkan jenis pemberian kode otorisasi Apigee Edge berfungsi sebagai server otorisasi. Ingat, kunci dari alur ini adalah bahwa klien tidak pernah melihat kredensial pengguna di server sumber daya.

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

Ketika aplikasi perlu mengakses sumber daya pengguna yang dilindungi dari server sumber daya (untuk (misalnya, daftar kontak di situs media sosial), situs ini mengirimkan panggilan API ke Apigee Edge, memvalidasi ID klien dan, jika valid, mengalihkan browser pengguna ke halaman login tempat pengguna akan memasukkan kredensial mereka. Panggilan API menyertakan informasi yang diberikan aplikasi klien yang diperoleh saat didaftarkan: ID klien dan URI pengalihan.

2. Pengguna memasukkan kredensial

Pengguna kini melihat halaman login tempat mereka diminta untuk memasukkan kredensial login. Jika berhasil, kita lanjutkan ke langkah berikutnya.

3. Pengguna memberikan izin

Pada langkah ini, pengguna memberikan izin kepada aplikasi untuk mengakses resource mereka. Formulir izin biasanya mencakup pilihan cakupan, di mana pengguna dapat memilih tindakan yang diizinkan oleh aplikasi server resource. Misalnya, pengguna dapat memberikan izin akses hanya-baca, atau izin untuk aplikasi untuk memperbarui sumber daya.

4. Aplikasi login mengirimkan permintaan Apigee Edge

Jika login dan izin berhasil, aplikasi login akan MEMPOSTING data ke /otorisasicode endpoint Apigee Edge. Data tersebut mencakup URI pengalihan, client ID, cakupan, kolom informasi yang ingin disertakan, dan indikasi bahwa {i>login<i} berhasil.

5. Edge Apigee membuat kode otorisasi

Saat Edge menerima permintaan GET dari aplikasi login pada endpoint /authorizationcode, dua terjadi banyak hal. Pertama, Edge menentukan bahwa proses {i>login<i} telah berhasil (dengan memeriksa status HTTP atau beberapa cara lainnya). Berikutnya Edge memeriksa untuk memastikan bahwa URI pengalihan dikirim dari aplikasi login cocok dengan URI pengalihan yang ditentukan saat aplikasi didaftarkan dengan Apigee Edge. Jika tidak ada masalah, Edge akan menghasilkan kode otorisasi. Contoh:

http://myorg-test.apigee.net/oauth/authorizationcode?client_id={consumer_key}&response_type=code&redirect_uri={redirect_uri}&scope=scope1%20scope2&state={some_string}

6. Tepi mengirimkan kode otorisasi kembali ke klien

Edge mengirim pengalihan 302 dengan kode auth yang dilampirkan sebagai parameter kueri ke dengan klien besar.

7. Klien mengambil kode otorisasi dan meminta kode akses dari Edge

Kini, dengan kode autentikasi yang valid, klien dapat meminta token akses dari Edge. Hal ini dilakukan dengan MEMPOSTING ID klien dan kunci rahasia klien (diperoleh saat aplikasi didaftarkan di Edge), jenis hibah, dan ruang lingkup. Dengan menyertakan client ID dan kunci rahasia Apigee Edge dapat memverifikasi bahwa aplikasi klien adalah aplikasi yang telah didaftarkan. Contoh:

$ curl https://{org_name}-test.apigee.net/my_oauth_proxy/accesstoken?code=Xyz123&grant_type=authorization_code -X POST -d 'client_id=bBGAQrXgivA9lKu7NMPyoYpKNhGar6K&client_secret=hAr4GngA9vAyvI4'

8. Klien menerima token akses

Jika semuanya berhasil, Edge akan menampilkan token akses ke klien. Token akses ini akan memiliki masa berlaku, dan hanya akan valid untuk cakupan yang ditentukan oleh pengguna mengizinkan aplikasi untuk mengakses sumber daya mereka.

9. 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 ylSkZIjbdWybfs4fUQe9BqP0LH5Z" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282

Mengonfigurasi alur dan kebijakan

Sebagai server otorisasi, Edge perlu memproses sejumlah permintaan OAuth: untuk akses token, kode autentikasi, token refresh, pengalihan halaman login, dll. Ada dua langkah dasar untuk konfigurasikan endpoint ini:

Membuat alur kustom
Menambahkan dan mengonfigurasi kebijakan OAuthV2

Konfigurasi alur kustom

Anda biasanya mengonfigurasi alur jenis pemberian ini sehingga setiap langkah atau "segmen" dari alur didefinisikan oleh alur di proxy Apigee Edge. Setiap alur memiliki endpoint dan kebijakan yang melakukan Tugas khusus OAuth diperlukan, seperti membuat kode otorisasi atau token akses. Sebagai seperti yang ditunjukkan dalam XML di bawah ini, endpoint /oauth/authorizationcode memiliki kebijakan terkait yang disebut GenerateAuthCode (yang merupakan kebijakan OAuthV2 dengan Operasi GenerateAuthorizationCode yang ditentukan).

Cara termudah untuk menampilkan konfigurasi flow adalah dengan contoh XML. Lihat baris komentar untuk informasi tentang setiap alur. Ini adalah sebuah contoh -- nama alur dan jalur bisa dikonfigurasi sesuai keinginan Anda. Lihat juga Mengonfigurasi OAuth endpoint dan kebijakan untuk mendapatkan ringkasan singkat tentang langkah-langkah yang diperlukan untuk membuat alur kustom seperti ini.

Lihat juga contoh implementasi di GitHub.

<Flows>
  <Flow name="RedirectToLoginApp">
         <!-- 
         Publish this URI to developers to use for their 'login' link 
         -->
    <Condition>proxy.pathsuffix == "/oauth/authorize"</Condition>
    <Request>
        <Step><Name>RedirectToLoginPage</Name></Step>
    </Request>
  </Flow>
  <Flow name="GetAuthCode">
         <!-- 
         Call this URL from your Login app after you authenticate the user.
         The policy will automatically return the auth code in the response to the 
         redirect_uri registered by the calling app 
         -->
    <Condition>proxy.pathsuffix == "/oauth/authorizationcode"</Condition>
    <Request>
        <Step><Name>GenerateAuthCode</Name></Step>
    </Request>
  </Flow>
  <Flow name="GetAccessToken">
         <!-- This policy flow is triggered when the URI path suffix
         matches /oauth/accesstoken. Publish this URL to app developers 
         to use when obtaining an access token using an auth code   
         -->
    <Condition>proxy.pathsuffix == "/oauth/accesstoken"</Condition>
    <Request>
        <Step><Name>GenerateAccessToken</Name></Step>
    </Request>
  </Flow>
</Flows>

Mengonfigurasi alur dengan kebijakan

Setiap endpoint memiliki kebijakan yang terkait dengannya. Mari kita lihat contoh-contoh kebijakan tersebut. Lihat juga Mengonfigurasi OAuth endpoint dan kebijakan untuk mendapatkan ringkasan singkat tentang langkah-langkah yang diperlukan guna menambahkan kebijakan OAuthV2 ke endpoint proxy.

Ini adalah jalur /oauth/authorize. Kebijakan yang terlampir bertanggung jawab untuk mengalihkan pengguna ke aplikasi proses masuk, tempat pengguna akhir dapat mengotentikasi dan memberi otorisasi untuk mengakses resource yang dilindungi tanpa membocorkan nama pengguna dan sandi ke aplikasi klien. Anda dapat melakukannya dengan kebijakan info layanan, JavaScript, Node.js, atau sarana lain.

Panggilan API untuk melakukan permintaan adalah GET dan memerlukan parameter kueri client_id, response_type, redirect_uri, scope, dan state.

$ curl http://myorg-test.apigee.net/oauth/authorize?client_id={consumer_key}&response_type=code&redirect_uri={redirect_uri}&scope=scope1%20scope2&state={some_string}

Dapatkan kode autentikasi

Ini adalah jalur /oauth/authorizationcode. Protokol tersebut menggunakan kebijakan OAuthV2 dengan Operasi GenerateAuthorizationCode ditentukan.

<OAuthV2 async="false" continueOnError="false" enabled="true" name="GetAuthCode">
    <DisplayName>GetAuthCode</DisplayName>
    <Operation>GenerateAuthorizationCode</Operation>
    <ExpiresIn>600000</ExpiresIn>
    <GenerateResponse/>
</OAuthV2>

Panggilan API untuk mendapatkan kode otorisasi adalah panggilan GET dan memerlukan parameter kueri client_id, response_type, serta secara opsional, scope dan state, seperti yang ditunjukkan dalam contoh ini:

$curl http://myorg-test.apigee.net/oauth/authorizationcode?client_id={consumer_key}&response_type=code&scope=scope1%20scope2&state={some_string}

Mendapatkan token akses

Kebijakan ini disertakan pada jalur /oauth/accesstoken. Protokol ini menggunakan OAuthV2 kebijakan dengan operasi GenerateAccessCode yang ditentukan. Dalam hal ini, parameter grant_type adalah diharapkan sebagai parameter kueri:

<OAuthV2 name="GetAccessToken">
    <Operation>GenerateAccessToken</Operation>
    <ExpiresIn>360000000</ExpiresIn> 
    <SupportedGrantTypes> 
        <GrantType>authorization_code</GrantType> 
    </SupportedGrantTypes> 
    <GrantType>request.queryparam.grant_type</GrantType> 
    <GenerateResponse/> 
</OAuthV2>

Panggilan API untuk mendapatkan kode akses adalah POST dan harus menyertakan client_id, client_secret, Grants_type=Authorization_code, dan, jika perlu, cakupan. Contoh:

$ curl https://{org_name}-test.apigee.net/oauth/accesstoken?grant_type=authorization_code -X POST -d 'client_id=bBGAQrXgivA9lKu7NMPyoYpVKNhGar6K&client_secret=hAr4Gn0gA9vAyvI4'

Ini hanyalah ringkasan dasar. Contoh produksi mencakup banyak kebijakan lain untuk membangun URL, melakukan transformasi, dan melakukan tugas lainnya. Lihat contoh di GitHub untuk proyek berjalan,

Lampiran kebijakan token verifikasi akses

Melampirkan kebijakan VerifyAccessToken (kebijakan OAuthV2 dengan operasi VerifyAccessToken ditetapkan) ke awal setiap alur yang mengakses API yang dilindungi, sehingga dapat dieksekusi setiap kali ada permintaan resource yang dilindungi. Pemeriksaan edge untuk memastikan setiap permintaan memiliki token akses yang valid. Jika tidak, pesan error akan muncul. Untuk mengetahui langkah-langkah dasar, lihat Memverifikasi token akses.

<OAuthV2 async="false" continueOnError="false" enabled="true" name="VerifyAccessToken">
    <DisplayName>VerifyAccessToken</DisplayName>
    <ExternalAuthorization>false</ExternalAuthorization>
    <Operation>VerifyAccessToken</Operation>
    <SupportedGrantTypes/>
    <GenerateResponse enabled="true"/>
    <Tokens/>
</OAuthV2>

Memanggil API yang dilindungi

Untuk memanggil API yang dilindungi dengan keamanan OAuth 2.0, Anda harus memberikan akses yang valid sebelumnya yang benar. Pola yang benar adalah menyertakan token di header Authorization, sebagai berikut: Catatan token akses juga disebut sebagai "{i>bearer token<i}".

$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \
  http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282

Lihat juga Mengirim token akses.