Pengantar OAuth 2.0

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

Beranda OAuth: Lihat halaman beranda OAuth untuk mendapatkan tampilan tingkat atas tentang panduan OAuth yang kami yang Anda sediakan.

Topik ini memberikan ringkasan dasar tentang OAuth 2.0 di Apigee Edge.

Apa itu OAuth 2.0?

Ada banyak buku, blog, dan situs yang didedikasikan untuk OAuth 2.0. Sebaiknya Anda mulai dengan meninjau IETF OAuth 2.0 spesifikasi. Berikut adalah definisi OAuth 2.0 dari spesifikasi OAuth 2.0 IETF itu sendiri:

"Framework otorisasi OAuth 2.0 memungkinkan aplikasi untuk memperoleh akses terbatas ke layanan HTTP, baik atas nama pemilik sumber daya dengan mengatur interaksi persetujuan antara pemilik sumber daya dan layanan HTTP, atau dengan mengizinkan aplikasi pihak ketiga untuk mendapatkan akses atas namanya sendiri."

Hal utama yang perlu Anda ketahui adalah bahwa OAuth 2.0 menyediakan cara bagi aplikasi untuk mendapatkan akses terbatas ke sumber daya yang dilindungi pengguna (seperti rekening bank atau informasi sensitif yang mungkin ingin diakses pengguna dari aplikasi) tanpa mengharuskan pengguna untuk membocorkan kredensial {i> login<i} mereka ke aplikasi.

Alur OAuth 2.0

Berikut adalah alur umum untuk framework keamanan OAuth 2.0. Kita akan membahas alur ini lebih lanjut dalam topik ini, dimulai dengan diagram, yang menggambarkan banyak hal tentang cara kerja OAuth 2.0. Jika Anda tidak terbiasa dengan istilah yang digunakan dalam diagram, baca bagian ini untuk pengantar.

Istilah yang harus Anda ketahui

• Klien: Juga disebut "aplikasi". Aplikasi dapat berupa aplikasi yang berjalan di perangkat seluler perangkat atau aplikasi web tradisional. Aplikasi membuat permintaan ke server resource untuk dilindungi aset atas nama pemilik aset. Pemilik aset harus memberikan izin kepada aplikasi untuk untuk mengakses resource yang dilindungi.
• Pemilik resource: Disebut juga "pengguna akhir". Ini umumnya adalah orang (atau entitas lain) yang mampu memberikan akses ke sumber daya yang dilindungi. Sebagai misalnya, jika sebuah aplikasi perlu menggunakan data dari salah satu situs media sosial Anda, maka Anda adalah pemilik resource -- satu-satunya orang yang dapat memberikan akses aplikasi ke data Anda.
• Server resource: Bayangkan server resource sebagai layanan seperti Facebook, Google, atau Twitter; atau layanan SDM di intranet Anda; atau layanan partner di Ekstranet B2B. Apigee Edge adalah server resource setiap kali validasi token OAuth diperlukan untuk memproses permintaan API. Server sumber daya membutuhkan semacam otorisasi sebelum server dapat melayani sumber daya yang dilindungi untuk aplikasi.
• Server otorisasi: Server otorisasi diterapkan sesuai dengan spesifikasi OAuth 2.0, dan bertanggung jawab untuk memvalidasi pemberian otorisasi dan menerbitkan akses yang memberi aplikasi akses ke data pengguna di server resource. Anda dapat mengonfigurasi "endpoint token" di Apigee Edge, dalam hal ini Edge berperan sebagai server otorisasi.
• Pemberian otorisasi: Memberi aplikasi izin untuk mengambil akses token Anda atas nama pengguna akhir. OAuth 2.0 mendefinisikan empat "jenis pemberian" yang spesifik. Lihat "Apa saja jenis pemberian izin OAuth 2.0" di bawah ini.
• Token akses: String karakter panjang yang berfungsi sebagai kredensial digunakan untuk mengakses sumber daya yang dilindungi. Lihat juga "Apa itu akses token ini?"" di bawah ini.
• Resource yang dilindungi: Data milik pemilik resource. Misalnya, daftar kontak pengguna, informasi akun, atau data sensitif lainnya.

Keunggulan Apigee Edge

Anda dapat melindungi API apa pun yang di-proxy-kan melalui Apigee Edge dengan OAuth 2.0. Edge menyertakan implementasi server otorisasi, dan dengan demikian, dapat membuat dan memvalidasi token akses. Developer memulai dengan mendaftarkan aplikasi mereka ke Apigee Edge. Aplikasi yang terdaftar dapat meminta token akses melalui salah satu dari empat pemberian jenis interaksi.

Apigee menyediakan kebijakan OAuthV2 multifaset yang menerapkan detail setiap jenis hibah, sehingga relatif mudah untuk menyiapkan OAuth di Apigee Edge. Sebagai Anda dapat mengonfigurasi kebijakan yang menerima permintaan untuk token akses, mengevaluasi semua kredensial yang diperlukan, dan mengembalikan token akses jika kredensial tersebut valid.

Perhatikan bahwa setiap server resource yang panggilan proxy API aman Anda harus berada di belakang firewall (yaitu, resource tidak boleh dapat diakses melalui cara apa pun selain proxy API atau API yang aman.

Apa itu OAuth 2.0 jenis hibah?

Anggaplah jenis izin ini sebagai jalur atau interaksi berbeda yang dapat diambil aplikasi untuk mendapatkan akses sebelumnya yang benar. Setiap jenis pemberian izin menangani satu atau beberapa kasus penggunaan, dan Anda harus memilih pemberian yang mana untuk digunakan berdasarkan kebutuhan Anda sendiri. Secara umum, setiap jenis hibah memiliki kelebihan dan kekurangannya, dan Anda harus mempertimbangkan konsekuensinya berdasarkan kasus penggunaan bisnis. paket Premium AI pertimbangan penting adalah "kepercayaan" aplikasi yang akan mengakses data Anda. Umumnya, aplikasi pihak ketiga kurang tepercaya dibandingkan aplikasi yang dikembangkan dan digunakan dalam perusahaan.

Apigee Edge mendukung empat jenis pemberian izin OAuth 2.0 utama:

• kode otorisasi -- Dianggap sebagai jenis pemberian yang paling aman. Sebelum server otorisasi mengeluarkan token akses, aplikasi harus terlebih dahulu menerima kode otorisasi dari server resource. Anda telah melihat alur ini setiap kali aplikasi membuka browser ke halaman login server resource dan mengundang Anda untuk login ke akun Anda yang sebenarnya (misalnya, Facebook atau Twitter).

Jika Anda berhasil login, aplikasi akan menerima otorisasi kode yang dapat digunakan untuk menegosiasikan token akses dengan server otorisasi. Biasanya, proses ini pemberian izin digunakan saat aplikasi berada di server, bukan di klien. Jenis hibah ini dianggap sangat aman karena aplikasi klien tidak pernah menangani atau melihat nama pengguna atau untuk server resource (misalnya, aplikasi tidak pernah melihat atau menangani Kredensial Twitter). Alur jenis hibah ini juga disebut "three-legged" OAuth.

• implisit -- Dianggap sebagai versi kode otorisasi yang disederhanakan. Biasanya jenis pemberian ini digunakan saat aplikasi berada di klien. Misalnya, kode diterapkan di browser menggunakan JavaScript atau bahasa skrip lainnya (bukan berada dan berjalan di server web terpisah). Dalam alur jenis pemberian ini, otorisasi server mengembalikan token akses secara langsung ketika pengguna diotentikasi, bukan mengeluarkan kode otorisasi terlebih dahulu. Pemberian implisit dapat meningkatkan responsivitas aplikasi dalam beberapa kasus, tetapi keuntungan ini perlu dipertimbangkan berdasarkan kemungkinan implikasi keamanan seperti dijelaskan dalam Spesifikasi IETF.
• kredensial sandi pemilik resource -- Dalam alur ini, klien akan diterbitkan token akses ketika nama pengguna/kata sandi pengguna divalidasi oleh server otorisasi. Alur ini direkomendasikan untuk aplikasi yang sangat tepercaya. Keuntungan dari alur ini, misalnya, otentikasi dasar, adalah bahwa pengguna hanya memberikan nama pengguna / {i>password<i} mereka satu kali. Setelah itu token akses akan digunakan.
• kredensial klien -- Pertimbangkan penggunaan dalam situasi ketika klien aplikasi bertindak atas namanya sendiri. Artinya, klien juga merupakan pemilik resource. Hibah ini tipe ini biasanya digunakan ketika aplikasi perlu mengakses layanan penyimpanan data backend, untuk contoh. Aplikasi harus menggunakan layanan untuk melakukan tugasnya, dan layanan akan buram kepada pengguna akhir. Dengan jenis pemberian ini, aplikasi dapat menerima token akses dengan memberikan ID klien dan kunci rahasia klien ke server otorisasi. Tidak perlu langkah lebih lanjut. Edge menyediakan solusi kredensial klien siap pakai yang mudah diterapkan untuk semua Proxy API.

Apa itu akses sebelumnya?

Token akses adalah string karakter panjang yang berfungsi sebagai kredensial yang digunakan untuk mengakses resource yang dilindungi. Token resource (juga disebut token pemilik) diteruskan di Otorisasi {i>header<i}, seperti ini:

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

Server resource memahami bahwa token akses "bertahan" untuk kredensial seperti nama pengguna dan {i>password<i}. Selain itu, token akses dapat diterbitkan dengan batasan, sehingga, misalnya, aplikasi dapat membaca tetapi tidak dapat menulis atau menghapus data di server resource. Perhatikan bahwa token akses dapat dicabut jika, misalnya, aplikasi disusupi. Dalam hal ini, Anda perlu mendapatkan token akses baru untuk terus menggunakan aplikasi; Namun, Anda tidak perlu mengubah nama pengguna atau sandi pada server sumber daya yang dilindungi (misalnya, Facebook atau Twitter).

Token akses umumnya memiliki masa berlaku (untuk alasan keamanan). Beberapa jenis izin mengizinkan server otorisasi untuk mengeluarkan token refresh, yang memungkinkan aplikasi mengambil token akses baru kapan yang lama kedaluwarsa. Untuk mengetahui detail selengkapnya tentang token akses dan refresh, lihat OAuth IETF Spesifikasi versi 2.0.

Akses terbatas melalui cakupan

Melalui mekanisme cakupan, OAuth 2.0 dapat memberikan akses terbatas kepada aplikasi ke Google Cloud Platform. Misalnya, aplikasi mungkin hanya memiliki akses ke sumber daya tertentu, mungkin dapat memperbarui tambahan, atau hanya dapat diberi akses hanya baca. Di bawah yang disebut "berkaki tiga" alur OAuth, pengguna biasanya menentukan tingkat akses melalui halaman izin (misalnya, halaman web di mana pengguna memilih cakupan dengan kotak centang mekanisme lainnya).

Mendaftarkan aplikasi

Semua klien (aplikasi) harus mendaftar ke server otorisasi OAuth 2.0 tempat mereka yang bermaksud meminta token akses. Saat mendaftarkan aplikasi, Anda akan menerima kembali serangkaian kunci. Satu adalah kunci publik yang disebut pengenal klien, dan yang lainnya adalah kunci rahasia, rahasia. Tanpa kunci ini, aplikasi tidak dapat mengeluarkan permintaan untuk kode otorisasi atau token akses ke server otorisasi. Perlu diketahui bahwa meskipun spesifikasi OAuth IETF memanggil klien kunci ini ID dan rahasia klien, UI Apigee Edge menyebutnya Consumer ID dan Consumer secret. Mereka adalah ekuivalen.

Ringkasan kasus penggunaan OAuth 2.0

Alur jenis pemberian OAuth 2.0 mana yang Anda pilih untuk diterapkan bergantung pada kasus penggunaan spesifik Anda, seperti beberapa jenis pemberian izin lebih aman daripada yang lain. Pilihan jenis hibah Anda bergantung pada kredibilitas aplikasi klien dan membutuhkan pertimbangan yang sangat cermat, seperti yang dijelaskan dalam tabel berikut:

Kasus Penggunaan	Kredibilitas	Jenis Pemberian Otorisasi OAuth 2.0 yang Disarankan	Deskripsi
B2B (ekstranet), intranet, lainnya	Aplikasi yang sangat tepercaya, yang ditulis oleh developer internal atau developer dengan hubungan bisnis dengan penyedia API. Aplikasi yang perlu mengakses resource atas namanya sendiri.	Kredensial klien	Biasanya, aplikasi juga merupakan pemilik resource Memerlukan Client ID dan Kunci rahasia klien Mewajibkan aplikasi didaftarkan ke penyedia layanan
Situs intranet, portal	Aplikasi tepercaya yang ditulis oleh developer internal atau pihak ketiga tepercaya. Sebuah contoh yang baik adalah masuk ke situs SDM perusahaan Anda untuk membuat pilihan asuransi, mengirimkan ulasan, atau mengubah informasi pribadi.	Sandi Implisit	Memerlukan rahasia dan ID klien, serta nama pengguna dan sandi Mewajibkan aplikasi didaftarkan ke penyedia layanan
Aplikasi yang tersedia secara publik	Aplikasi tidak tepercaya ditulis oleh developer pihak ketiga yang tidak memiliki bisnis tepercaya dengan penyedia API. Misalnya, developer yang mendaftar ke API publik program secara umum seharusnya tidak dipercaya.	Kode otorisasi	Mewajibkan pengguna login ke penyedia resource pihak ketiga (misalnya, Twitter Facebook) Aplikasi tidak pernah melihat nama pengguna dan sandi pengguna Mewajibkan aplikasi didaftarkan ke penyedia layanan
B2C	Ada pengguna akhir individu (pengguna seluler) yang terlibat, dan kredensial pengguna disimpan pada perangkat seluler.	Implisit	Mewajibkan aplikasi terdaftar ke penyedia layanan. Kredensial pengguna disimpan di perangkat yang menjalankan aplikasi.

OAuth 2.0 vs. kunci API keamanan

Validasi kunci API memerlukan aplikasi untuk mengirim kunci ke Edge. Kunci tersebut harus berupa kunci konsumen yang valid dari aplikasi developer Apigee Edge yang terkait dengan proxy API. Jika karena suatu alasan Anda harus mencabut izin aplikasi klien untuk melakukan panggilan ke proxy, Anda harus mencabut izin tersebut kunci konsumen. Setiap aplikasi klien yang menggunakan kunci tersebut juga tidak akan dapat mengakses proxy API. Pada sisi lain, token OAuth dapat dicabut kapan saja tanpa mencabut kunci aplikasi. Aplikasi bisa meminta token baru atas nama pengguna, dan jika token diberikan, aplikasi dapat terus menggunakan proxy API.

Perbedaan lain antara kunci API dan token adalah token dapat menyertakan metadata yang dapat Anda ambil dan gunakan nanti. Misalnya, Anda dapat menyimpan ID pengguna melakukan panggilan API dan menggunakannya untuk menyesuaikan panggilan ke layanan target backend.

Untuk mengetahui detail tentang validasi kunci API, lihat API . Untuk informasi tentang penggunaan atribut khusus dengan token OAuth, lihat Menyesuaikan Token dan Kode Otorisasi.

Direkomendasikan sumber daya

Membaca

Lihat Mempelajari OAuth 2.0.