Pengantar OAuth 2.0

Halaman ini berlaku untuk Apigee dan Apigee hybrid.

Lihat dokumentasi Apigee Edge.

Beranda OAuth: Lihat halaman beranda OAuth untuk melihat panduan OAuth tingkat atas yang kami berikan.

Topik ini menawarkan ringkasan dasar tentang OAuth 2.0 di Apigee.

Apa yang dimaksud dengan OAuth 2.0?

Ada banyak buku, blog, dan situs yang membahas 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 itu sendiri:

"Framework otorisasi OAuth 2.0 memungkinkan aplikasi pihak ketiga mendapatkan akses terbatas ke layanan HTTP, baik atas nama pemilik resource dengan mengatur 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 menyediakan cara bagi aplikasi untuk mendapatkan akses terbatas ke resource yang dilindungi pengguna (misalnya, rekening bank atau informasi sensitif lainnya yang mungkin ingin diakses pengguna dari aplikasi) tanpa perlu pengguna mengungkapkan kredensial login mereka ke aplikasi.

Alur OAuth 2.0

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

Alur umum untuk framework keamanan OAuth 2.0.

Istilah yang perlu Anda ketahui

  • Klien: Juga disebut aplikasi. Ini dapat berupa aplikasi yang berjalan di perangkat seluler atau aplikasi web tradisional. Aplikasi 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. Ini biasanya adalah orang (atau entitas lain) yang dapat memberikan akses ke resource yang dilindungi. Misalnya, jika aplikasi perlu menggunakan data dari salah satu situs media sosial Anda, 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 extranet B2B Anda. Apigee adalah server resource setiap kali validasi token OAuth diperlukan untuk memproses permintaan API. Server resource memerlukan semacam otorisasi sebelum menayangkan resource yang dilindungi ke aplikasi.
  • Server otorisasi: Server otorisasi diimplementasikan 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, dengan demikian Apigee akan berperan sebagai server otorisasi.
  • Pemberian otorisasi: Memberi aplikasi izin untuk mengambil token akses atas nama pengguna akhir. OAuth 2.0 menentukan empat "jenis pemberian" tertentu. Lihat Apa saja jenis pemberian izin OAuth 2.0.
  • Token akses: String karakter panjang yang berfungsi sebagai kredensial yang digunakan untuk mengakses resource yang dilindungi. Lihat Apa itu token akses?.
  • Resource yang dilindungi: Data yang dimiliki oleh pemilik resource. Misalnya, daftar kontak, informasi akun, atau data sensitif lainnya milik pengguna.

Peran Apigee

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

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

Perhatikan bahwa server resource apa pun yang dipanggil proxy API aman Anda harus berada di balik firewall (yaitu, resource tidak boleh diakses melalui cara apa pun selain proxy API atau API lain yang diamankan dengan baik).

Apa saja jenis pemberian izin OAuth 2.0?

Anggap jenis pemberian sebagai berbagai jalur atau interaksi 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 penting adalah kepercayaan aplikasi yang akan mengakses data Anda. Umumnya, aplikasi pihak ketiga kurang tepercaya daripada aplikasi yang dikembangkan dan digunakan dalam perusahaan.

Apigee mendukung empat jenis pemberian OAuth 2.0 utama:

  • kode otorisasi -- Dianggap sebagai jenis pemberian yang paling aman. Sebelum server otorisasi menerbitkan token akses, aplikasi harus menerima kode otorisasi dari server resource terlebih dahulu. 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 pemberian 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 ini juga disebut OAuth tiga kaki.

  • implisit -- Dianggap sebagai versi sederhana dari kode otorisasi. Biasanya, jenis pemberian ini digunakan saat aplikasi berada di klien. Misalnya, kode aplikasi diterapkan di browser menggunakan JavaScript atau bahasa skrip lain (bukan berada 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. Dalam beberapa kasus, pemberian izin implisit dapat meningkatkan responsivitas aplikasi, tetapi keuntungan ini perlu dipertimbangkan dengan kemungkinan implikasi keamanan seperti yang dijelaskan dalam spesifikasi IETF.
  • kredensial sandi pemilik resource -- Dalam alur ini, klien akan diberi token akses saat nama pengguna/sandi pengguna divalidasi oleh server otorisasi. Alur ini direkomendasikan untuk aplikasi yang sangat tepercaya. Keuntungan alur ini dibandingkan, misalnya, autentikasi dasar, adalah pengguna hanya memberikan nama pengguna/sandi mereka satu kali. Setelah itu, token akses akan digunakan.
  • kredensial klien -- Pertimbangkan untuk digunakan dalam situasi saat aplikasi klien bertindak atas namanya sendiri. Artinya, klien juga merupakan pemilik resource. Jenis grant ini biasanya digunakan saat aplikasi perlu mengakses layanan penyimpanan data backend, misalnya. Aplikasi perlu menggunakan layanan untuk melakukan tugasnya, dan layanan tersebut tidak jelas bagi pengguna akhir. Dengan jenis pemberian ini, aplikasi dapat menerima token akses dengan menampilkan client ID dan kunci rahasia klien ke server otorisasi. Anda tidak perlu melakukan tindakan lebih lanjut. menyediakan solusi kredensial klien siap pakai yang mudah diterapkan untuk proxy API apa pun.

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 pembawa) diteruskan di header Authorization, seperti ini:

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

Server resource memahami bahwa token akses menggantikan kredensial seperti nama pengguna dan sandi. 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 harus mendapatkan token akses baru untuk terus menggunakan aplikasi; namun, Anda tidak perlu mengubah nama pengguna atau sandi di server resource yang dilindungi (misalnya, Facebook atau Twitter).

Token akses biasanya memiliki masa berlaku (karena alasan keamanan). Beberapa jenis pemberian izin memungkinkan server otorisasi menerbitkan token refresh, yang memungkinkan aplikasi mengambil token akses baru saat masa berlaku token lama berakhir. Untuk mengetahui detail selengkapnya tentang token akses dan token refresh, lihat spesifikasi IETF OAuth 2.0.

Akses terbatas melalui cakupan

Melalui mekanisme cakupan, OAuth 2.0 dapat memberikan akses terbatas ke resource yang dilindungi kepada aplikasi. Misalnya, aplikasi mungkin hanya memiliki akses ke resource tertentu, dapat mengupdate resource, atau hanya diberi akses baca saja. Dalam alur OAuth yang disebut three-legged, pengguna biasanya menentukan tingkat akses melalui halaman izin (misalnya, halaman web tempat pengguna memilih cakupan dengan kotak centang atau mekanisme lainnya).

Mendaftarkan aplikasi

Semua klien (aplikasi) harus mendaftar ke server otorisasi OAuth 2.0 tempat mereka ingin meminta token akses. Saat mendaftarkan aplikasi, Anda akan menerima kembali sekumpulan kunci. Salah satunya adalah kunci publik yang disebut ID klien, dan yang lainnya adalah kunci rahasia yang disebut secret klien. Tanpa kunci ini, aplikasi tidak dapat mengeluarkan permintaan untuk kode otorisasi atau token akses ke server otorisasi. Perhatikan bahwa meskipun spesifikasi OAuth IETF menyebut kunci ini sebagai client ID dan secret klien, UI Apigee menyebutnya sebagai ID Konsumen dan secret Konsumen. Keduanya setara.

Ringkasan kasus penggunaan OAuth 2.0

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

Kasus Penggunaan Kredibilitas Jenis Pemberian Otorisasi OAuth 2.0 yang Disarankan Deskripsi
B2B (extranet), intranet, lainnya

Aplikasi yang sangat tepercaya, ditulis oleh developer internal atau developer dengan hubungan bisnis tepercaya 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
  • Memerlukan aplikasi untuk didaftarkan ke penyedia layanan
Situs intranet, portal

Aplikasi tepercaya yang ditulis oleh developer internal atau pihak ketiga tepercaya.

Contohnya adalah login ke situs SDM perusahaan Anda untuk membuat pilihan asuransi, mengirimkan ulasan, atau mengubah informasi pribadi.

  • Sandi
  • Implisit
  • Memerlukan client ID dan rahasia, serta nama pengguna dan sandi
  • Memerlukan aplikasi untuk 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 boleh dipercaya.
  • Kode otorisasi
  • Memerlukan pengguna untuk login ke penyedia resource pihak ketiga (misalnya, Twitter, Facebook)
  • Aplikasi tidak pernah melihat nama pengguna dan sandi pengguna
  • Memerlukan aplikasi untuk didaftarkan ke penyedia layanan
B2C Ada pengguna akhir individu (pengguna seluler) yang terlibat, dan kredensial pengguna disimpan di perangkat seluler.
  • Implisit
  • Memerlukan aplikasi untuk didaftarkan ke penyedia layanan.
  • Kredensial pengguna disimpan di perangkat yang menjalankan aplikasi.

Keamanan OAuth 2.0 vs. kunci API

Validasi kunci API mengharuskan aplikasi mengirim kunci ke Apigee. Kunci harus berupa kunci konsumen yang valid dari aplikasi developer Apigee 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 dapat 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 nanti. 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 informasi tentang cara menggunakan atribut kustom dengan token OAuth, lihat Menyesuaikan Token dan Kode Otorisasi.

Dampak masa berlaku token dan waktu penghapusan pada penyimpanan disk

Saat membuat token OAuth baru dengan kebijakan OAuthV2, Anda dapat menetapkan waktu habis masa berlaku untuk token dengan atribut ExpiresIn. Secara default, token dihapus dari penyimpanan tiga hari setelah masa berlaku token berakhir. Jika menetapkan waktu habis masa berlaku yang besar, seperti 48 jam, Anda mungkin melihat peningkatan penggunaan ruang disk yang tidak terduga untuk Cassandra. Untuk menghindari penggunaan ruang disk yang berlebih, Anda dapat menetapkan waktu habis masa berlaku yang lebih singkat (direkomendasikan satu jam) dan/atau menetapkan konfigurasi yang mengubah penundaan pasca-habis masa berlaku tiga hari menjadi jangka waktu yang lebih singkat.

Pelanggan Apigee hybrid dapat mengubah waktu penghapusan default dengan menetapkan konfigurasi berikut dalam file penggantian mereka:

runtime:
  cwcAppend:
    "conf_keymanagement_oauth.access.token.purge.after.seconds": "SECONDS"

Dengan SECONDS adalah jumlah detik yang akan ditunggu Apigee untuk menghapus token setelah masa berlakunya berakhir. Pastikan untuk menyertakan bait ini persis seperti yang ditulis, dengan tanda kutip disertakan.

Misalnya, untuk menetapkan waktu penghapusan menjadi satu jam setelah masa berlaku berakhir:

runtime:
  cwcAppend:
    "conf_keymanagement_oauth.access.token.purge.after.seconds": "3600"

Referensi yang direkomendasikan

Membaca

Lihat Pelajari OAuth 2.0.