Apa itu OAuth & Bagaimana cara kerjanya

Setiap kali Anda mengklik 'Masuk dengan Google' or 'Hubungkan dengan Microsoft', Anda menggunakan OAuth. Tapi apa itu OAuth? OAuth adalah kerangka kerja otorisasi berstandar terbuka yang memungkinkan Anda memberi satu aplikasi izin untuk mengakses informasi Anda di layanan lain, tanpa perlu membagikan kata sandi Anda. Itulah cara kerja OAuth. OAuth memverifikasi identitas Anda tanpa membagikan kata sandi, hanya memberikan informasi terbatas ke aplikasi, cukup untuk mengonfirmasi bahwa Anda sah. OAuth adalah jabat tangan senyap yang mendukung proses masuk yang aman dan modern.

Saat ini, di mana hampir setiap karyawan mengakses aplikasi cloud dari perangkat pribadi atau di luar kantor, login tradisional tidak lagi efektif. Autentikasi OAuth mengatasi masalah ini dengan memungkinkan pengguna memberikan akses terbatas kepada aplikasi tanpa membagikan kata sandi. Alih-alih kredensial, aplikasi mendapatkan token yang tercakup. Artinya, kontrol yang lebih baik, risiko yang lebih rendah, dan titik kegagalan yang lebih sedikit.

Jadi, apa perbedaan autentikasi OAuth? OAuth memisahkan identitas dari akses dan memberikan visibilitas serta kontrol kepada tim TI tanpa menimbulkan hambatan bagi pengguna. 

Panduan ini menguraikan makna OAuth, cara kerjanya, dan cara menggunakannya untuk mengamankan akses di seluruh organisasi Anda, ditambah satu atau dua contoh praktis OAuth untuk mewujudkannya.

Apa itu OAuth?

Pada intinya, OAuth adalah sebuah protokol. Protokol ini memungkinkan aplikasi untuk meminta akses terbatas ke data pengguna yang dihosting oleh layanan lain (seperti Google, Microsoft, atau GitHub). Pengguna dapat menyetujui atau menolak permintaan ini.

Sederhananya, autentikasi OAuth adalah cara aman bagi pengguna untuk mengizinkan aplikasi mengakses data mereka tanpa memberikan kata sandi. Alih-alih menyerahkan kredensial login lengkap, pengguna menyetujui akses melalui token. Token tersebut berfungsi seperti slip izin, terbatas pada tindakan dan data tertentu.

Berikut ide sederhana di baliknya: Anda memberikan akses, bukan kredensial Anda.

Bagaimana cara kerja OAuth?

OAuth dalam praktiknya? Pengguna dapat mengizinkan aplikasi kebugaran membaca langkah mereka dari akun Apple Health, tanpa mengizinkan aplikasi tersebut mengubah apa pun atau mengakses data yang tidak terkait.

Idenya terdengar sederhana: biarkan aplikasi mengakses data tanpa harus memberikan kata sandi. Tapi bagaimana cara kerja autentikasi OAuth di balik layar?

Berikut contoh OAuth langkah demi langkah menggunakan kasus umum, masuk ke aplikasi pihak ketiga dengan Google:

1. Aplikasi meminta akses: Pengguna membuka aplikasi dan mengklik "Masuk dengan Google". Aplikasi akan mengarahkan pengguna ke Google dengan permintaan akses ke data tertentu (seperti email atau kontak).

2. Pengguna memberikan izinGoogle menunjukkan kepada pengguna apa yang diminta aplikasi. Pengguna setuju. Tidak ada kata sandi yang dibagikan dengan aplikasi.

3. Aplikasi mendapatkan tokenSetelah disetujui, Google mengirimkan token aman kepada aplikasi. Token ini berfungsi sebagai bukti bahwa aplikasi memiliki izin untuk mengakses data.

4. Token digunakan untuk aksesAplikasi menggunakan token untuk mengambil data pengguna dari Google. Token ini memiliki cakupan terbatas, waktu terbatas, dan dapat dibatalkan.

Ini adalah autentikasi OAuth dalam tindakan, sederhana bagi pengguna, kuat untuk keamanan.

Mengapa OAuth penting untuk keamanan dan kontrol akses

Coba pikirkan, kata sandi tidak berubah. Begitu kata sandi terkirim, penyerang langsung masuk.

Tapi OAuth? Itu bukan sekadar metode login biasa.

Ini cara yang lebih cerdas untuk mengelola kepercayaan, akses, dan kontrol saat segala sesuatunya terjadi, secara real-time. Ini bukan hanya tentang mempermudah hidup; ini adalah peningkatan menyeluruh untuk sistem keamanan Anda.

Inilah mengapa autentikasi OAuth penting:

1. Penegakan hukum secara real-time

Sistem akses tradisional tidak mampu menangani ancaman yang bergerak cepat. OAuth memungkinkan Anda mencabut akses secara instan. Jika token terlihat mencurigakan atau peran pengguna berubah, Anda akan menutup akses secara langsung, tanpa perlu menyetel ulang kata sandi, dan tanpa penundaan.

2. Konfigurasi jarak jauh

Dengan OAuth, izin tidak dikodekan secara kaku. Izin dikonfigurasi dan diberikan oleh server otorisasi, yang berarti Anda dapat menyesuaikan cakupan, menetapkan masa berlaku, dan memperbarui kebijakan secara terpusat. Tim TI tidak perlu menyentuh titik akhir untuk mengubah akses.

3. Penyaringan berdasarkan lokasi

OAuth bekerja dengan lancar dengan alat keamanan berbasis lokasi. Jika permintaan akses berasal dari wilayah berisiko tinggi atau IP yang tidak dikenal, Anda dapat menolak atau membatasi penerbitan token. Ini merupakan lapisan kontrol kontekstual tambahan yang terintegrasi dalam alur.

4. Skalabilitas

Seiring berkembangnya lingkungan Anda, model akses statis akan mengalami perubahan. OAuth dapat diskalakan dengan mudah di berbagai aplikasi, perangkat, dan pengguna. Satu identitas dapat mengotorisasi banyak layanan, dan kebijakan berlaku secara konsisten di seluruh lini, tanpa menambah hambatan bagi tim TI atau pengguna akhir.

Manfaat utama OAuth

OAuth lebih dari sekadar metode login. OAuth adalah cara yang fleksibel dan aman untuk mengelola akses lintas pengguna, aplikasi, dan sistem. Inilah alasannya mengapa OAuth menjadi standar untuk otorisasi yang aman dan fleksibel dalam lingkungan TI hibrida masa kini.

• Kontrol akses terperinci: Tentukan secara tepat apa yang dapat diakses oleh pengguna atau aplikasi. Jadi, aplikasi dapat membaca kalender Anda, tetapi tidak dapat membaca email Anda.
• Lebih sedikit kata sandi, UX lebih baik: Pengguna memberikan izin satu kali. OAuth menangani akses aman, sehingga tidak ada login berulang atau kredensial bersama.
• Dirancang untuk prinsip zero trust: Mendukung pengecekan token secara real-time, akses berdasarkan konteks, dan pencabutan.
• Proses offboarding yang mudah: Cabut akses secara instan tanpa menyentuh data identitas. Paling cocok untuk mengelola vendor, kontraktor, dan aplikasi sementara.
• Bekerja dengan penyedia identitas: Terintegrasi secara rapi dengan Entra ID, Google, Okta, dan lainnya; membuatnya mudah untuk ditambahkan ke tumpukan yang sudah ada.

Kasus Penggunaan OAuth Umum

1. Akses BYOD untuk tim jarak jauh: Seorang karyawan jarak jauh mengakses aplikasi perusahaan dari perangkat pribadi.

Aliran OAuth:

• Masuk menggunakan penyedia identitas perusahaan (misalnya, Google Workspace atau Entra ID)
• Menyetujui akses khusus aplikasi ke email dan kalender
• Token dikeluarkan dengan cakupan yang ditentukan (tidak ada kata sandi yang disimpan)

Digunakan untuk: Akses yang aman dan terbatas ke alat kerja pada perangkat BYOD.

2. Integrasi SaaS pihak ketiga:Tim pemasaran menghubungkan alat proyek ke CRM mereka.

Aliran OAuth:

• Permintaan OAuth dikirim ke CRM (misalnya, Salesforce)
• Pengguna memberikan akses baca saja ke data prospek
• Token dikeluarkan; aplikasi tidak pernah melihat kredensial

Digunakan untuk: Memberikan akses terbatas ke aplikasi pihak ketiga tanpa risiko berbagi kata sandi.

3. Kontrol akses berbasis konteks: Pengguna masuk dari jaringan terbatas pada perangkat yang tidak dikelola.

Perilaku OAuth:

• Permintaan akses dievaluasi secara real time
• Perangkat gagal mematuhi; akses diblokir
• Tindakan dicatat untuk audit

Digunakan untuk: Menegakkan kebijakan Zero Trust dan kontrol kepatuhan.

4. Login vendor atau kontraktor: Vendor eksternal memerlukan akses ke alat internal untuk sementara.

Proses OAuth:

• Token bercakupan yang dikeluarkan dengan akses terbatas waktu
• Tidak ada perubahan yang dibuat pada direktori inti
• Akses dapat dicabut secara instan

Digunakan untuk: Akses aman dan sementara tanpa perlu masuk ke sistem internal.

OAuth 1.0 vs OAuth 2.0: Apa yang berubah, dan mengapa itu penting

Ketika orang membicarakan autentikasi OAuth saat ini, mereka hampir selalu merujuk pada OAuth 2.0. Namun, protokolnya tidak dimulai di sana, dan memahami apa yang berubah dari OAuth 1.0 membantu menjelaskan mengapa OAuth 2.0 menjadi pilihan utama untuk akses yang aman dan skalabel di aplikasi modern.

Mari kita jabarkan.

OAuth 1.0: aman namun kaku

OAuth 1.0, yang diperkenalkan pada tahun 2007, dirancang untuk memungkinkan aplikasi mengakses data pengguna di layanan lain tanpa perlu menyimpan nama pengguna atau sandi. Ide intinya, mendelegasikan akses melalui token, masih mendefinisikan arti OAuth hingga saat ini.

Namun spesifikasi asli memiliki beberapa ciri utama:

• Setiap permintaan harus ditandatangani secara kriptografi. Hal ini menambah beban dan kompleksitas, terutama untuk aplikasi berbasis seluler atau browser.
• Alirannya terstruktur dengan ketat. Penerapan OAuth 1.0 memerlukan jabat tangan multi-langkah yang kaku dan sulit diadaptasi ke berbagai platform.
• Tidak ada dukungan bawaan untuk kebutuhan pengalaman pengguna modern. Tidak ada cara yang bersih untuk mendukung hal-hal seperti token seluler, akses jangka pendek, atau pihak ketiga penyedia identitas.

Siapa yang masih menggunakan OAuth 1.0? Kebanyakan sistem lama yang belum ditransisikan. Jika Anda membangun sesuatu yang baru, sistem tersebut jarang relevan.

OAuth 2.0 membuat akses aman menjadi lebih sederhana, lebih cerdas, dan lebih terukur

OAuth 2.0 dirilis pada tahun 2012 sebagai penulisan ulang lengkap, bukan revisi, dari spesifikasi aslinya. Versi ini mengatasi banyak tantangan yang diperkenalkan OAuth 1.0 dengan berfokus pada:

• Implementasi yang disederhanakanTidak ada lagi penandatanganan kriptografi. OAuth 2.0 mengandalkan HTTPS untuk keamanan transportasi dan menggunakan token pembawa untuk akses.
• Alur otorisasi yang fleksibel:OAuth 2.0 memperkenalkan beberapa “jenis hibah” untuk mendukung berbagai kasus penggunaan:
  • Kode Otorisasi (untuk aplikasi sisi server)
  • Implisit (untuk aplikasi berbasis browser)
  • Kredensial Klien (untuk mesin-ke-mesin)
  • Kata Sandi Pemilik Sumber Daya (sekarang tidak digunakan lagi)
• Arsitektur berbasis token: OAuth 2.0 menggunakan token akses jangka pendek dan token penyegaran untuk meningkatkan keamanan dan mendukung sesi jangka panjang tanpa login berulang.
• Kemungkinan diperpanjangOAuth 2.0 mudah diintegrasikan dengan penyedia identitas, aplikasi seluler, dan layanan cloud. Hal ini juga meletakkan dasar bagi Koneksi OpenID (OIDC), yang menambahkan autentikasi di atas otorisasi.

OAuth vs SAML vs OIDC vs FIDO2

modern identitas dan manajemen akses Ini bukan tentang memilih satu protokol; ini tentang menggunakan alat yang tepat untuk pekerjaan yang tepat. Berikut perbandingan autentikasi OAuth dengan SAML, OIDC, dan FIDO2, serta apa yang ditawarkan (atau tidak) masing-masing protokol di lingkungan TI dunia nyata.

OAuth vs. SAML: Akses terdelegasi vs. identitas terpusat

SAML (Security Assertion Markup Language) adalah protokol berbasis XML yang memungkinkan pengguna untuk masuk sekali (SSO) dan mengakses banyak aplikasi web. SAML diadopsi secara luas pada awal tahun 2000-an oleh perusahaan-perusahaan yang menjalankan sistem TI tradisional.

OAuth, di sisi lain, adalah kerangka kerja berbasis token yang memungkinkan aplikasi mengakses data pengguna terbatas dari layanan lain, tanpa mengungkap kata sandi.

Insight: SAML cocok untuk portal lama. OAuth mendukung aplikasi modern. OAuth menyediakan akses berbasis token yang aman, dirancang untuk seluler, API, dan layanan seperti Google Workspace atau Microsoft Graph.

OAuth vs. OpenID Connect (OIDC): Akses vs. Identitas

OAuth 2.0 murni merupakan protokol otorisasi. Protokol ini tidak memverifikasi identitas pengguna—melainkan hanya memungkinkan aplikasi untuk mengakses data atas nama pengguna. OIDC (Koneksi OpenID) adalah lapisan yang dibangun di atas OAuth 2.0 yang menambahkan otentikasi, sehingga aplikasi tidak hanya mendapatkan izin untuk bertindak, tetapi juga mengetahui siapa penggunanya.

Insight: Anggap saja OIDC sebagai OAuth 2.0 + identitas. Anda menggunakan OAuth ketika ingin aplikasi mengakses sumber daya pengguna. Anda menggunakan OIDC ketika aplikasi juga perlu mengetahui siapa penggunanya; kebutuhan umum dalam SSO alur kerja.

OAuth vs. FIDO2: Akses token vs. login tanpa kata sandi

FIDO2 adalah kategori yang sama sekali berbeda. Fokusnya adalah autentikasi tanpa kata sandi, menggunakan kriptografi kunci publik-swasta dan keamanan yang didukung perangkat keras (seperti biometrik atau kunci keamanan). FIDOXNUMX bukan pengganti OAuth, melainkan pelengkap.

Insight: FIDO2 membantu Anda masuk dengan aman. OAuth membantu mengontrol apa yang dapat Anda lakukan setelah masuk. Gabungkan keduanya untuk alur menyeluruh yang lebih kuat: FIDO2 untuk autentikasi, OAuth untuk akses terbatas dan dapat dibatalkan.

Kapan harus menggunakan setiap protokol

• OAuth memungkinkan kontrol akses berbasis token yang aman untuk aplikasi dan API, tetapi tidak memverifikasi identitas.
• OIDC menambahkan identitas di atas OAuth, gunakan saat aplikasi Anda memerlukan login dan akses.
• SAML efektif untuk lingkungan SSO lama, tetapi kurang cocok untuk alur kerja API-first dan seluler.
• FIDO2 menggantikan kata sandi, bukan otorisasi. Padukan dengan OAuth atau OIDC untuk keamanan yang kuat dan menyeluruh.

Memilih protokol yang tepat untuk tujuan yang tepat sering kali berarti menggunakan OAuth bersama dengan protokol lain untuk membangun sistem akses yang aman, terukur, dan mudah digunakan.

Kesalahpahaman umum tentang autentikasi OAuth

1. OAuth untuk login.
   Realitanya: OAuth menangani otorisasi, bukan autentikasi. Ini memungkinkan aplikasi mengakses data, bukan mengonfirmasi siapa pengguna.
2. OAuth dan SSO adalah sama.
   Realita: SSO memverifikasi identitas; OAuth memberikan akses. Mereka sering bekerja bersama-sama, tetapi memiliki tujuan yang berbeda.
3. OAuth menggantikan MFA.
   Realitas: OAuth tidak memverifikasi pengguna atau menambahkan lapisan keamanan tambahan. Ia dapat mendukung MFA, tetapi tidak menyediakannya.
4. OAuth berperilaku sama di seluruh platform.
   Realitanya: Setiap penyedia menerapkannya sedikit berbeda. Cakupan, alur, dan penanganan token bervariasi antara sistem.
5. OAuth aman secara default.
   Realita: Kesalahan konfigurasi menjadikannya berisiko. Token yang lemah atau cakupan yang luas dapat mengekspos data jika tidak disiapkan dengan benar.

Menggabungkan semuanya: OAuth, konteks, dan kontrol dengan Scalefusion OneIdP

OAuth membangun fondasi untuk autentikasi modern berbasis standar. Namun, OAuth tidak menentukan apakah perangkat aman, jaringan tepercaya, atau perilaku pengguna sesuai dengan kebijakan. Scalefusion OneIdP menambahkan konteks tersebut ke lapisan dalam postur keamanan Anda. 

OAuth mengelola akses. Kebijakan zero trust menentukan apakah akses akan terjadi. 

Dengan mengevaluasi setiap permintaan token terhadap sinyal konteks langsung seperti:

• Kesehatan perangkat dan kepatuhan MDM
• Reputasi IP dan geolokasi
• Pola perilaku berbasis peran

Pendekatan yang sadar konteks ini memungkinkan SatuIdP untuk mengizinkan, membatasi, atau mencabut akses, bahkan setelah autentikasi berhasil.

Dengan menghubungkan token OAuth ke lingkungan yang terverifikasi dan sesuai kebijakan, OneIdP menerapkan akses bersyarat tanpa menambah hambatan. Hal ini menyederhanakan konfigurasi yang rumit dan menghilangkan ketergantungan pada metode autentikasi yang sudah ketinggalan zaman.

Jika pengaturan OAuth Anda saat ini berhenti saat login, itu bukan Zero Trust. OneIdP menjembatani kesenjangan tersebut dengan presisi, skalabilitas, dan keamanan bawaan.

Hadirkan Zero Trust ke lingkungan OAuth Anda dengan Scalefusion OneIdP.

Daftar untuk uji coba gratis selama 14 hari.

Coba Gratis

Pertanyaan Umum Demo Slot

1. Kapan menggunakan OAuth?

Gunakan OAuth ketika Anda membutuhkan akses delegasi yang aman ke sumber daya pengguna tanpa perlu berbagi sandi. OAuth ideal untuk mengotorisasi aplikasi pihak ketiga, klien seluler atau web, dan API untuk mengakses data atas nama pengguna. Autentikasi OAuth memastikan kontrol izin yang terperinci, meminimalkan paparan kredensial, dan mendukung alur kerja modern seperti akses masuk tunggal dan BYOD.

2. Apa itu OAuth dalam rest API?

OAuth dalam REST API adalah protokol yang memberikan akses aman dan terbatas ke sumber daya API melalui token, alih-alih kata sandi. Autentikasi OAuth memungkinkan REST API untuk memverifikasi izin klien sebelum mengizinkan akses data. Ini berarti aplikasi dapat berinteraksi dengan API atas nama pengguna secara aman, menggunakan token akses yang mengontrol cakupan dan kedaluwarsa.

3. Apa itu OAuth vs SAML?

OAuth dan SAML keduanya merupakan kerangka kerja otorisasi, tetapi OAuth berfokus pada akses delegasi (otorisasi) terutama untuk API dan aplikasi seluler. SAML adalah protokol berbasis XML yang terutama digunakan untuk Single Sign-On (autentikasi) dalam aplikasi web perusahaan. OAuth tidak menyediakan pernyataan identitas, sedangkan SAML menyediakan autentikasi pengguna dan informasi atribut.

4. Apa perbedaan antara OAuth dan JWT?

OAuth adalah protokol otorisasi yang menerbitkan token untuk akses yang didelegasikan, sementara JWT (JSON Web Token) adalah format token ringkas yang sering digunakan dalam OAuth. JWT membawa informasi yang dikodekan seperti identitas pengguna dan cakupan token. OAuth dapat menggunakan JWT sebagai token akses atau ID, tetapi JWT sendiri bukanlah protokol autentikasi atau otorisasi.