Pengantar OAuth 2.0

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

Beranda OAuth: Lihat halaman beranda OAuth untuk melihat tampilan garis besar dari panduan OAuth yang kami sediakan.

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

Apa itu OAuth 2.0?

Ada banyak buku, blog, dan situs yang ditujukan untuk OAuth 2.0. Sebaiknya Anda memulai dengan meninjau spesifikasi IETF OAuth 2.0. Berikut adalah definisi OAuth 2.0 dari spesifikasi IETF OAuth 2.0:

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

Hal utama yang perlu Anda ketahui adalah OAuth 2.0 memberikan cara bagi aplikasi untuk mendapatkan akses terbatas ke resource yang dilindungi milik pengguna (misalnya rekening bank atau informasi sensitif lainnya yang mungkin ingin diakses pengguna dari aplikasi) tanpa mengharuskan pengguna untuk membocorkan kredensial login mereka ke aplikasi.

Alur OAuth 2.0

Berikut adalah alur umum untuk framework keamanan OAuth 2.0. Kita akan membahas alur tersebut secara lebih mendetail 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 pengenalan singkat.

Istilah yang harus Anda ketahui

• Klien: Juga disebut "aplikasi". Dapat berupa aplikasi yang berjalan di perangkat seluler atau aplikasi web tradisional. Aplikasi akan membuat permintaan ke server resource untuk aset yang dilindungi atas nama pemilik resource. Pemilik resource harus memberikan izin kepada aplikasi untuk mengakses resource yang dilindungi.
• Pemilik resource: Juga disebut "pengguna akhir". Umumnya, orang ini (atau entitas lain) yang mampu memberikan akses ke resource yang dilindungi. Misalnya, jika 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: Anggap server resource sebagai layanan seperti Facebook, Google, atau Twitter; atau layanan HR di intranet Anda; atau layanan partner di ekstranet B2B Anda. Apigee Edge adalah server resource setiap kali validasi token OAuth diperlukan untuk memproses permintaan API. Server resource memerlukan otorisasi tertentu sebelum menyediakan resource yang dilindungi ke aplikasi.
• Server otorisasi: Server otorisasi diterapkan sesuai dengan spesifikasi OAuth 2.0, dan bertanggung jawab untuk memvalidasi pemberian otorisasi dan menerbitkan token akses yang memberi aplikasi akses ke data pengguna di server resource. Anda dapat mengonfigurasi "endpoint token" di Apigee Edge, yang dalam hal ini Edge akan berperan sebagai server otorisasi.
• Pemberian otorisasi: Memberi aplikasi izin untuk mengambil token akses atas nama pengguna akhir. OAuth 2.0 mendefinisikan empat "jenis hibah" secara spesifik. Lihat "Apa saja jenis pemberian OAuth 2.0" di bawah.
• Token akses: String karakter panjang yang berfungsi sebagai kredensial yang digunakan untuk mengakses resource yang dilindungi. Lihat juga "Apa itu token akses?" di bawah.
• Resource yang dilindungi: Data milik pemilik resource. Misalnya, daftar kontak pengguna, informasi akun, atau data sensitif lainnya.

Tempat yang cocok dengan Apigee Edge

Anda dapat melindungi API apa pun yang di-proxy-kan melalui Apigee Edge dengan OAuth 2.0. Edge menyertakan implementasi server otorisasi, sehingga 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 interaksi jenis pemberian.

Apigee menyediakan kebijakan OAuthV2 multifaset yang menerapkan detail setiap jenis pemberian, sehingga penyiapan OAuth di Apigee Edge relatif mudah. Misalnya, Anda dapat mengonfigurasi kebijakan yang menerima permintaan token akses, mengevaluasi semua kredensial yang diperlukan, dan menampilkan token akses jika kredensial tersebut valid.

Perlu diketahui bahwa setiap server resource yang dipanggil oleh proxy API aman Anda harus berada di belakang firewall (artinya, resource tidak boleh dapat diakses melalui cara apa pun selain proxy API atau API lain yang diamankan dengan baik).

Apa yang dimaksud dengan jenis pemberian OAuth 2.0?

Bayangkan jenis pemberian sebagai jalur atau interaksi berbeda yang dapat dilakukan aplikasi untuk mendapatkan token akses. Setiap jenis hibah menangani satu atau beberapa kasus penggunaan, dan Anda harus memilih jenis hibah yang akan digunakan berdasarkan kebutuhan Anda sendiri. Secara umum, setiap jenis hibah memiliki kelebihan dan kekurangan, dan Anda harus mempertimbangkan konsekuensinya berdasarkan kasus penggunaan bisnis Anda. Salah satu pertimbangan pentingnya 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 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 sebenarnya (misalnya, Facebook atau Twitter).

Jika Anda berhasil login, aplikasi akan menerima kode otorisasi yang dapat digunakan untuk menegosiasikan token akses dengan server otorisasi. Biasanya, jenis pemberian ini 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 sandi pengguna untuk server resource (yaitu, misalnya, aplikasi tidak pernah melihat atau menangani kredensial Twitter Anda). Alur jenis pemberian izin ini juga disebut OAuth "three-legged".

• implisit -- Dianggap sebagai versi kode otorisasi yang disederhanakan. Biasanya jenis pemberian ini digunakan saat aplikasi berada di klien. Misalnya, kode aplikasi diimplementasikan di browser menggunakan JavaScript atau bahasa skrip lain (bukan tinggal dan berjalan di server web terpisah). Dalam alur jenis pemberian ini, server otorisasi menampilkan token akses secara langsung saat pengguna diautentikasi, bukan mengeluarkan kode otorisasi terlebih dahulu. Pemberian implisit dapat meningkatkan daya respons aplikasi dalam beberapa kasus, tetapi keuntungan ini perlu mempertimbangkan kemungkinan implikasi keamanan seperti yang dijelaskan dalam spesifikasi IETF.
• kredensial sandi pemilik resource -- Dalam alur ini, klien diberi token akses saat nama pengguna/sandi pengguna divalidasi oleh server otorisasi. Alur ini direkomendasikan untuk aplikasi yang sangat tepercaya. Keuntungan dari alur ini, misalnya, autentikasi dasar, adalah pengguna hanya memberikan nama pengguna/sandi satu kali. Selanjutnya, token akses akan digunakan.
• kredensial klien -- Pertimbangkan penggunaan untuk situasi ketika aplikasi klien bertindak atas namanya sendiri. Artinya, klien juga merupakan pemilik resource. Jenis pemberian ini biasanya digunakan saat aplikasi perlu mengakses layanan penyimpanan data backend, misalnya. Aplikasi perlu menggunakan layanan untuk melakukan tugasnya, dan layanan akan bersifat buram bagi pengguna akhir. Dengan jenis pemberian ini, aplikasi dapat menerima token akses dengan menampilkan client ID dan kunci rahasia klien ke server otorisasi. Tidak ada langkah lebih lanjut yang diperlukan. Edge menyediakan solusi kredensial klien siap pakai yang mudah diterapkan untuk semua proxy API.

Apa yang dimaksud dengan token akses?

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

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

Server resource memahami bahwa token akses "sebagai pengganti" kredensial seperti nama pengguna dan sandi. Selain itu, token akses dapat dikeluarkan dengan pembatasan, 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 kasus ini, Anda harus mendapatkan token akses baru untuk terus menggunakan aplikasi. Namun, Anda tidak perlu mengubah nama pengguna atau sandi pada server resource yang dilindungi (misalnya, Facebook atau Twitter).

Token akses umumnya memiliki masa berlaku (untuk alasan keamanan). Beberapa jenis pemberian memungkinkan server otorisasi untuk mengeluarkan token refresh, yang memungkinkan aplikasi untuk mengambil token akses baru jika token yang lama sudah tidak berlaku. Untuk detail lebih lanjut tentang akses dan token refresh, lihat spesifikasi IETF OAuth 2.0.

Akses terbatas melalui cakupan

Melalui mekanisme cakupan, OAuth 2.0 dapat memberi aplikasi akses terbatas ke resource yang dilindungi. Contohnya, aplikasi mungkin hanya memiliki akses ke resource tertentu, mungkin dapat mengupdate resource, atau mungkin hanya diberikan akses hanya baca. Pada alur OAuth "tiga kaki", pengguna biasanya menentukan tingkat akses melalui halaman izin (misalnya, halaman web tempat pengguna memilih cakupan dengan kotak centang mekanisme lain).

Mendaftarkan aplikasi

Semua klien (aplikasi) harus mendaftar ke server otorisasi OAuth 2.0 tempat klien tersebut ingin meminta token akses. Saat mendaftarkan aplikasi, Anda akan menerima kembali kumpulan kunci. Salah satunya adalah kunci publik yang disebut ID klien, dan satunya lagi adalah kunci rahasia yang disebut rahasia klien. Tanpa kunci ini, aplikasi tidak dapat mengeluarkan permintaan kode otorisasi atau token akses ke server otorisasi. Perlu diperhatikan bahwa meskipun spesifikasi OAuth IETF memanggil client ID dan rahasia klien kunci ini, UI Apigee Edge menyebutnya sebagai ID Konsumen dan rahasia Konsumen. Keduanya setara.

Ringkasan kasus penggunaan OAuth 2.0

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

Kasus Penggunaan	Ketepercayaan	Jenis Pemberian Otorisasi OAuth 2.0 yang Disarankan	Deskripsi
B2B (ekstranet), intranet, lainnya	Aplikasi yang sangat tepercaya, ditulis oleh developer internal atau developer yang memiliki hubungan bisnis tepercaya dengan penyedia API. Aplikasi yang perlu mengakses resource atas nama mereka 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 pihak ketiga internal atau tepercaya. Contoh yang bagus adalah login ke situs HR perusahaan untuk membuat pilihan asuransi, mengirim ulasan, atau mengubah informasi pribadi.	Sandi Implisit	Memerlukan ID dan rahasia klien, serta nama pengguna dan sandi Mewajibkan aplikasi didaftarkan ke penyedia layanan
Aplikasi yang tersedia secara publik	Aplikasi yang tidak tepercaya ditulis oleh developer pihak ketiga yang tidak memiliki hubungan bisnis tepercaya dengan penyedia API. Misalnya, developer yang mendaftar ke program API publik umumnya tidak dapat dipercaya.	Kode otorisasi	Mengharuskan pengguna untuk 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 di perangkat seluler.	Implisit	Mewajibkan aplikasi didaftarkan ke penyedia layanan. Kredensial pengguna disimpan di perangkat yang menjalankan aplikasi.

OAuth 2.0 vs. keamanan kunci API

Validasi kunci API memerlukan aplikasi untuk mengirimkan kunci ke Edge. Kunci harus berupa kunci konsumen yang valid dari aplikasi developer Apigee Edge yang dikaitkan dengan proxy API. Jika karena alasan tertentu Anda perlu mencabut izin aplikasi klien untuk melakukan panggilan ke proxy, Anda harus mencabut kunci konsumen tersebut. Setiap aplikasi klien yang menggunakan kunci tersebut juga tidak akan dapat mengakses proxy API. Di sisi lain, token OAuth dapat dicabut kapan saja tanpa mencabut kunci aplikasi. Aplikasi cukup 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 atribut metadata yang dapat Anda ambil dan gunakan di lain waktu. Misalnya, Anda dapat menyimpan ID pengguna yang melakukan panggilan API dan menggunakannya untuk menyesuaikan panggilan ke layanan target backend.

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

Referensi yang direkomendasikan

Membaca

Lihat Mempelajari OAuth 2.0.