Beranda

Think

Topik

OAuth

Apa itu OAuth (otorisasi terbuka)?
Jelajahi solusi autentikasi canggih IBM Berlangganan buletin Think
Piktogram awan, ponsel, sidik jari, tanda centang.

Diterbitkan: 29 Juli 2024
Kontributor: Gregg Lindemulder, Matt Kosinski

Apa itu otorisasi terbuka (OAuth)?

Otorisasi terbuka (OAuth) adalah kerangka kerja otorisasi standar terbuka yang memberikan aplikasi akses ke sumber daya pengguna akhir yang dilindungi, seperti foto, kalender, atau postingan media sosial, tanpa memerlukan login atau kata sandi akun pengguna.

Situs web dan aplikasi pihak ketiga yang meminta pengguna untuk "Masuk dengan Google?" atau "Izinkan akses ke informasi akun Anda?" adalah contoh penggunaan umum untuk OAuth. Protokol OAuth memungkinkan pengguna untuk dengan mudah memberi aplikasi ini akses ke data akun mereka tanpa membagikan kredensial pengguna mereka.

Selain aplikasi web, OAuth juga dapat memberikan akses sumber daya ke API, aplikasi sisi server, aplikasi asli OS, aplikasi seluler, dan perangkat seperti TV pintar dan peralatan. Dalam beberapa kasus, tidak ada pengguna manusia yang terlibat karena OAuth dapat mengotorisasi akses aplikasi atas nama organisasi atau akun bisnis.

KuppingerCole Access Management Leadership Compass

Pelajari mengapa KuppingerCole mengatakan bahwa IBM adalah pemimpin dalam menyediakan solusi autentikasi perusahaan yang matang, dapat diskalakan, dan aman.

Mengapa OAuth penting?

OAuth menawarkan manfaat manajemen akses yang penting bagi pengguna, pengembang, dan bisnis dengan menjaga agar data login tidak dapat diakses dan membatasi akses ke informasi sensitif lainnya. Hal ini juga memudahkan aplikasi untuk mengakses informasi akun yang diperlukan tanpa kerentanan keamanan dari berbagi kredensial pengguna.

Sebuah tim kecil pengembang perangkat lunak merilis OAuth 1.0 pada tahun 2007. Versi pertama protokol ini dirancang sebagai alternatif autentikasi berbasis web, yang mengharuskan pengguna untuk membagikan nama pengguna dan kata sandi mereka dengan layanan pihak ketiga. Namun, OAuth 1.0 menyediakan aliran otorisasi untuk situs web saja.

Pada tahun 2012, Internet Engineering Task Force (IETF) merilis OAuth 2.0 sebagai RFC 6749 dan RFC 6750. RFC (Request for Comments) adalah dokumen IETF yang menjelaskan protokol komunikasi internet. RFC 6749 adalah kerangka kerja inti untuk OAuth 2.0, dan RFC 6750 mendefinisikan bagaimana kerangka kerja menggunakan token akses.

Versi terbaru OAuth ini memperluas protokol di luar peramban web untuk menyertakan kemampuan otorisasi untuk aplikasi, API, dan perangkat. OAuth 2.0 menggantikan OAuth 1.0 dan sekarang menjadi standar industri.

Cara kerja OAuth

Tidak seperti kerangka kerja lain yang mengandalkan nama pengguna dan kata sandi, OAuth adalah protokol otorisasi yang didasarkan pada token akses. Token akses adalah potongan informasi yang menentukan sumber daya spesifik yang diizinkan untuk diakses aplikasi. Protokol OAuth mendefinisikan bagaimana setiap komponen dalam proses permintaan otorisasi menyetujui, mendefinisikan, dan mengelola token akses.

Token OAuth biasanya menggunakan standar JSON Web Token (JWT) karena kemampuannya untuk mengirimkan data dengan aman.

Komponen utama kerangka kerja OAuth adalah:

  • Pemilik sumber daya
  • Server sumber daya
  • Klien
  • Server otorisasi
  • Mempelajari
Pemilik sumber daya

Ini adalah pengguna akhir yang memiliki akun yang ingin diakses aplikasi, seperti akun Facebook atau Google. Pemilik sumber daya memberikan persetujuan bagi aplikasi untuk mengakses sumber daya tertentu yang dilindungi dalam akun tersebut, seperti foto atau data pribadi. Dalam beberapa kasus, pemilik sumber daya mungkin merupakan perusahaan atau akun bisnis.

Server sumber daya

Ini adalah server yang menyimpan sumber daya yang dilindungi atas nama pengguna. Server sumber daya menerima dan memvalidasi token OAuth yang diterimanya dari klien, kemudian memberikan data pengguna yang telah disetujui oleh pemilik sumber daya untuk dirilis.

Klien

Klien adalah aplikasi, situs web, API atau perangkat yang meminta akses. Ini meminta otorisasi dari server otorisasi dengan menyajikan ID klien. Kemudian, setelah pemilik sumber daya memberikan persetujuan, klien menerima token akses yang dapat digunakan untuk mengakses sumber daya yang dilindungi di server sumber daya.

Server otorisasi

Ini adalah server utama yang menggerakkan protokol OAuth. Ini mengoperasikan dua titik akhir untuk memberikan akses ke server sumber daya.

Titik akhir otorisasi meminta pemilik sumber daya untuk memberikan persetujuan untuk sumber daya yang dilindungi secara spesifik.  Titik akhir token kemudian menerima permintaan token dari klien OAuth dan menghasilkan token akses baru yang memberikan akses ke sumber daya.

Lingkup

Cakupan adalah parameter akses untuk sumber daya yang dilindungi pada server sumber daya.

Misalnya, pemilik sumber daya mungkin diminta untuk memberikan persetujuan akses ke data seperti email, file, atau foto. Cakupan membatasi akses klien ke item tersebut saja.

Contoh alur OAuth

Berikut adalah ringkasan dasar tentang cara kerja alur OAuth:

  1. Jim (pemilik sumber daya) ingin mengizinkan situs media sosial ( klien) untuk mengakses kontak emailnya (sumber daya).

  2. Server otorisasi email meminta Jim untuk memberikan persetujuan untuk akses ini.

  3. Setelah menerima persetujuan Jim, server otorisasi memberikan token akses kepada situs media sosial.

  4. Situs media sosial memberikan token akses ke server sumber daya yang menyimpan informasi akun email Jim.

  5. Server sumber daya mengenali token akses dan memberikan akses situs media sosial ke kontak email Jim. Karena token akses termasuk dalam cakupan persetujuan Jim, situs media sosial tidak dapat mengakses data lain dari akun Jim.
Jenis izin OAuth

Prosedur untuk memberikan token akses ke aplikasi disebut pemberian otorisasi atau alur otorisasi. Ada berbagai jenis pemberian izin dan aliran OAuth yang dapat digunakan untuk berbagai jenis aplikasi, perangkat, atau API, seperti:

  • Kode otorisasi
  • Kunci Bukti untuk Pertukaran Kode (PKCE)
  • Kredensial klien
  • Pemberian izin implisit
  • Token penyegaran
Kode otorisasi

Jenis pemberian izin ini biasanya digunakan untuk aplikasi web dan aplikasi seluler. Dalam aliran kode otorisasi, server otorisasi memberikan kode otorisasi satu kali ke klien. Klien kemudian dapat menukarkan kode otorisasi tersebut dengan token akses dari titik akhir token server otorisasi.

Kunci Bukti untuk Pertukaran Kode (PKCE)

Alur ini menambah keamanan ekstra pada pemberian kode otorisasi untuk melindungi aplikasi dari serangan injeksi kode. Jenis serangan ini dapat mengelabui aplikasi agar menjalankan kode berbahaya yang mengubah cara mereka beroperasi.

PKCE menambahkan 'rahasia klien' yang mengautentikasi klien dengan server otorisasi sebelum token akses dikeluarkan. Karena hanya klien yang sah yang memiliki rahasia tersebut, pelaku kejahatan tidak dapat berpura-pura menjadi klien dan memasukkan kode berbahaya.

Kredensial klien

Jenis hibah ini dirancang untuk situasi di mana tidak ada pengguna manusia yang terlibat, seperti proses otomatis, interaksi mesin ke mesin, dan layanan mikro.

Aplikasi diberikan akses ke sumber daya sistem yang diperlukan untuk menjalankan fungsi, tetapi tidak diberikan akses ke sumber daya pengguna akhir. Misalnya, pemberian kredensial klien mungkin mengizinkan aplikasi cuaca mengakses API untuk mengambil data pada perkiraan terbaru. 

Pemberian izin implisit

Jenis pemberian izin ini menyediakan alur yang lebih sederhana untuk aplikasi web JavaScript. Berbeda dengan pemberian kode otorisasi, alur implisit tidak memerlukan kode otorisasi sebelum token akses dikeluarkan.

Sebaliknya, setelah pengguna memberikan persetujuan, token akses disertakan dalam Uniform Resource Identifier (URI) pengalihan yang mengembalikan pengguna ke aplikasi yang meminta akses. Aplikasi memperoleh token akses dari URI.

Token penyegaran

Jika token akses telah kedaluwarsa, jenis pemberian izin ini menyediakan aplikasi dengan token penyegaran yang dapat ditukar dengan token akses baru. Tanpa token penyegaran, pengguna akhir harus sekali lagi memberikan persetujuan agar aplikasi dapat menerima token akses yang baru.

Apa perbedaan antara SSO dan OAuth?

Perbedaan mendasar adalah bahwa sistem masuk tunggal (SSO) adalah protokol autentikasi pengguna dan OAuth adalah protokol otorisasi.

SSO sering menggunakan penyedia identitas (IdP) dan Security Assertion Markup Language (SAML), yang didasarkan pada Extensible Markup Language (XML), untuk mengautentikasi identitas digital pengguna melalui nama pengguna dan kata sandi.

OAuth tidak mengautentikasi pengguna, tetapi mengotorisasi mereka untuk mengakses sumber daya sistem. Solusi SSO terkadang menggunakan OAuth untuk memberi pengguna yang diautentikasi akses mudah ke aplikasi dan layanan di seluruh perusahaan.

Apa itu OpenID Connect?

OpenID Connect (OIDC) adalah protokol autentikasi yang dibangun di atas OAuth 2.0. Bekerja bersama-sama, OpenID Connect dapat memverifikasi identitas pengguna, kemudian OAuth dapat memberi otorisasi kepada pengguna tersebut untuk mengakses sumber daya dan layanan. 

Solusi terkait
IBM Verify

Melindungi dan mengelola identitas pelanggan, tenaga kerja, dan hak istimewa di seluruh hybrid cloud yang tertanam AI.

Jelajahi IBM Verify

 IBM Verify (SaaS)

Tambahkan konteks mendalam, kecerdasan, dan keamanan ke akses pengguna terhadap data dan aplikasi Anda.

Jelajahi IBM Verify (SaaS)

IBM API Connect

Amankan, kontrol, dan mediasi akses ke API Anda untuk melindunginya dari ancaman yang semakin intensif. 

Jelajahi IBM API Connect
Sumber daya Laporan Biaya Pelanggaran Data

Dapatkan insight penting untuk membantu tim keamanan dan TI Anda mengelola risiko dan potensi kerugian dengan lebih baik.

Indeks X-Force Threat Intelligence

Pahami taktik serangan siber terbaru untuk melindungi karyawan, data, dan infrastruktur Anda dengan lebih baik.

Apa itu autentikasi?

Dalam sistem komputer, autentikasi (disingkat menjadi 'auth') adalah proses yang memverifikasi bahwa pengguna adalah orang yang mereka klaim.

Ambil langkah selanjutnya

IBM Security Verify adalah platform IAM terkemuka yang menyediakan kemampuan yang didukung AI untuk mengelola tenaga kerja dan kebutuhan pelanggan Anda. Menyatukan silo identitas, mengurangi risiko serangan berbasis identitas dan menyediakan autentikasi modern, termasuk kemampuan tanpa kata sandi.

Jelajahi Verify Coba Verify selama 90 hari