Panduan Illustrated OAuth dan OpenID Connect

Catatan perev. : Posting blog Okta yang hebat ini menjelaskan cara kerja OAuth dan OIDC (OpenID Connect). Pengetahuan ini akan berguna bagi pengembang, administrator sistem, dan bahkan "pengguna biasa" dari aplikasi web populer yang kemungkinan besar juga bertukar data sensitif dengan layanan lain.

Di Zaman Batu Internet, berbagi informasi antar layanan itu mudah. Anda cukup memberikan nama pengguna dan kata sandi Anda dari satu layanan ke layanan lain sehingga ia masuk ke akun Anda dan menerima informasi yang diperlukan.


"Berikan rekening bankmu." “Kami berjanji bahwa semuanya akan baik-baik saja dengan kata sandi dan uang. Itu jujur ​​jujur! ”* Hee hee *

Horor! Tidak seorang pun boleh meminta pengguna untuk membagikan nama pengguna dan kata sandi, kredensial mereka, dengan layanan lain. Tidak ada jaminan bahwa organisasi di balik layanan ini akan menyimpan data dengan aman dan tidak akan mengumpulkan lebih banyak informasi pribadi daripada yang diperlukan. Ini mungkin tampak liar, tetapi beberapa aplikasi masih menggunakan praktik ini!

Saat ini ada satu standar yang memungkinkan satu layanan untuk menggunakan data yang lain dengan aman. Sayangnya, standar semacam itu menggunakan banyak jargon dan istilah, yang mempersulit pemahaman mereka. Tujuan dari bahan ini adalah untuk menjelaskan bagaimana mereka bekerja dengan ilustrasi sederhana (Apakah Anda berpikir bahwa gambar saya menyerupai baby memulas? Ya, oke!).



Omong-omong, panduan ini juga tersedia dalam format video:

Saudara-saudara, ketemu: OAuth 2.0

OAuth 2.0 adalah standar keamanan yang memungkinkan satu aplikasi mendapatkan izin untuk mengakses informasi di aplikasi lain. Urutan langkah-langkah untuk mengeluarkan izin (izin ) sering disebut otorisasi atau bahkan otorisasi yang didelegasikan . Dengan menggunakan standar ini, Anda mengizinkan aplikasi membaca data atau menggunakan fungsi aplikasi lain atas nama Anda tanpa memberi tahu kata sandi Anda. Kelas!

Sebagai contoh, bayangkan Anda menemukan situs yang disebut “ Pun Mengerikan Hari Ini” dan memutuskan untuk mendaftarkannya untuk menerima permainan kata-kata harian dalam bentuk pesan teks di ponsel Anda. Anda sangat menyukai situs ini, dan Anda memutuskan untuk membaginya dengan semua teman Anda. Bagaimanapun, permainan kata-kata yang mengerikan seperti semua orang, bukan?


"Permainan kata yang gagal pada hari itu: Pernahkah kamu mendengar tentang seorang pria yang kehilangan separuh tubuhnya?" Sekarang dia selalu benar! "(Perkiraan terjemahan, karena aslinya memiliki permainan kata sendiri, - kira-kira. Terjemahan)

Jelas bahwa menulis kepada setiap orang dari daftar kontak bukanlah suatu pilihan. Dan, jika Anda sedikit seperti saya, maka Anda akan melakukan apa saja untuk menghindari pekerjaan yang tidak perlu. Untungnya Pun of the Day Terrible dapat mengundang semua teman Anda sendiri! Untuk melakukan ini, Anda hanya perlu memberinya akses ke email kontak - situs itu sendiri akan mengirimi mereka undangan (drive OAuth)!


"Semua orang suka permainan kata-kata!" - Sudah masuk? - Ingin berbagi situs web Pun of the Terrible dengan daftar kontak Anda? - Terima kasih! Sekarang, setiap hari kami akan mengirimkan pengingat kepada semua orang yang Anda kenal sampai akhir waktu! Kamu adalah teman terbaik! "

1. Pilih layanan email Anda.
2. Jika perlu, buka situs surat dan masuk ke akun Anda.
3. Berikan izin Pun of the Day Mengerikan untuk mengakses kontak Anda.
4. Kembali ke situs web Pun of the Terrible.

Jika Anda berubah pikiran, aplikasi yang menggunakan OAuth juga menyediakan cara untuk mencabut akses. Setelah memutuskan bahwa Anda tidak lagi ingin berbagi kontak dengan Pun of the Day Terrible, Anda dapat pergi ke situs surat dan menghapus situs dengan permainan kata-kata dari daftar aplikasi resmi.

Aliran OAuth

Kami baru saja melewati apa yang biasa disebut aliran [aliran] OAuth. Dalam contoh kami, aliran ini terdiri dari langkah-langkah yang terlihat, serta beberapa langkah yang tidak terlihat, di mana dua layanan menyetujui pertukaran informasi yang aman. Contoh Terrible Pun of the Day sebelumnya menggunakan aliran OAuth 2.0 yang paling umum, yang dikenal sebagai aliran "kode otorisasi" .

Sebelum mempelajari detail OAuth, mari kita bicara tentang arti beberapa istilah:

• Pemilik Sumber Daya :
  
  
  
  Ini kamu! Anda memiliki kredensial, data, dan mengelola semua tindakan yang dapat dilakukan dengan akun Anda.
• Klien :
  
  
  
  Sebuah aplikasi (misalnya, layanan Pun Mengerikan yang Mengerikan) yang ingin mengakses atau melakukan tindakan tertentu atas nama Pemilik Sumber Daya .
• Server Otorisasi :
  
  
  
  Aplikasi yang mengetahui Pemilik Sumber Daya dan pemilik Sumber Daya sudah memiliki akun.
• Server sumber daya :
  
  
  
  Antarmuka pemrograman aplikasi (API) atau layanan yang ingin digunakan Klien atas nama Pemilik Sumber Daya .
• Redirect URI :
  
  
  
  Tautan tempat Server Otorisasi mengalihkan Pemilik Sumber Daya ke 'setelah memberikan izin kepada Klien '. Kadang-kadang disebut sebagai Callback URL.
• Jenis Tanggapan :
  
  
  
  Jenis informasi yang diharapkan akan diterima oleh Klien . Jenis Respons yang paling umum adalah kode, yaitu, Klien mengharapkan untuk menerima Kode Otorisasi .
• Lingkup :
  
  
  
  Ini adalah uraian terperinci tentang izin yang diperlukan Klien , seperti mengakses data atau melakukan tindakan tertentu.
• Persetujuan :
  
  
  
  Server Otorisasi mengambil Ruang Lingkup yang diminta oleh Klien dan bertanya kepada Pemilik Sumber Daya apakah siap untuk memberikan izin yang sesuai kepada Klien .
• ID Klien :
  
  
  
  ID ini digunakan untuk mengidentifikasi Klien di Server Otorisasi .
• Rahasia Klien :
  
  
  
  Ini adalah kata sandi yang hanya diketahui oleh Klien dan Server Otorisasi . Ini memungkinkan mereka untuk bertukar informasi secara rahasia.
• Kode Otorisasi :
  
  
  
  Kode sementara jangka pendek yang diberikan Klien ke Server Otorisasi dengan imbalan Token Akses .
• Token Akses :
  
  
  
  Kunci yang akan digunakan klien untuk berkomunikasi dengan Server Sumber Daya . Ini adalah lencana atau kartu kunci yang memberikan izin kepada Klien untuk meminta data atau melakukan tindakan pada Server Sumber Daya atas nama Anda.

Catatan : terkadang Server Otorisasi dan Server Sumber Daya adalah server yang sama. Namun, dalam beberapa kasus, ini mungkin server yang berbeda, bahkan bukan milik organisasi yang sama. Misalnya, Server Otorisasi mungkin layanan pihak ketiga yang dipercaya oleh Resource Server.

Sekarang kita telah terbiasa dengan konsep dasar OAuth 2.0, mari kita kembali ke contoh kita dan melihat lebih dekat pada apa yang terjadi dalam aliran OAuth.

1. Anda, Pemilik Sumber Daya , ingin memberikan Pun of the Day yang Mengerikan ( Klien ) dengan akses ke kontak Anda sehingga ia dapat mengirim undangan ke semua teman Anda.
2. Klien mengalihkan browser ke halaman Server Otorisasi dan termasuk dalam permintaan ID Klien , URI Pengalihan , Jenis Respons, dan satu atau beberapa Lingkup (izin) yang diperlukan.
3. Server Otorisasi memeriksa Anda, jika perlu, meminta nama pengguna dan kata sandi.
4. Server Otorisasi menampilkan formulir Persetujuan dengan daftar semua Ruang Lingkup yang diminta oleh Klien . Anda setuju atau menolak.
5. Server Otorisasi mengarahkan Anda ke situs Klien menggunakan URI Pengalihan bersama dengan Kode Otorisasi .
6. Klien berkomunikasi langsung dengan Server Otorisasi (melewati peramban Pemilik Sumberdaya ) dan dengan aman mengirimkan ID Klien, Rahasia Klien, dan Kode Otorisasi .
7. Server Otorisasi memvalidasi data dan merespons dengan Token Akses .
8. Klien sekarang dapat menggunakan Token Akses untuk mengirim permintaan ke Server Sumber Daya untuk mendapatkan daftar kontak.

ID dan Rahasia Klien

Jauh sebelum Anda mengizinkan Pun of the Day Mengerikan untuk mengakses kontak Anda, Klien dan Server Otorisasi menjalin hubungan kerja. Server Otorisasi menghasilkan ID Klien dan Rahasia Klien (kadang-kadang disebut ID Aplikasi dan Rahasia Aplikasi ) dan mengirimkannya ke Klien untuk interaksi lebih lanjut dalam OAuth.


"Halo! Saya ingin bekerja sama dengan Anda! - Ya, tidak ada pertanyaan! Ini ID Klien dan Rahasia Anda! "

Nama ini mengisyaratkan bahwa Rahasia Klien harus dirahasiakan sehingga hanya Klien dan Server Otorisasi yang mengetahuinya. Memang, dengan bantuannya Server Otorisasi mengkonfirmasi kebenaran Klien.

Tapi itu belum semuanya ... Selamat datang di OpenID Connect!

OAuth 2.0 dirancang hanya untuk otorisasi - untuk menyediakan akses ke data dan fitur dari satu aplikasi ke aplikasi lainnya. OpenID Connect (OIDC) adalah lapisan tipis di atas OAuth 2.0 yang menambahkan informasi tentang nama pengguna dan profil pengguna yang masuk ke dalam akun. Organisasi sesi login sering disebut otentikasi , dan informasi tentang pengguna yang masuk (yaitu, tentang Pemilik Sumber Daya ) disebut identitas . Jika Server Otorisasi mendukung OIDC, kadang-kadang disebut penyedia identitas karena menyediakan Klien dengan informasi tentang Pemilik Sumber Daya .

OpenID Connect memungkinkan Anda untuk mengimplementasikan skenario ketika satu login dapat digunakan di banyak aplikasi - pendekatan ini juga dikenal sebagai sistem masuk tunggal (SSO). Misalnya, aplikasi dapat mendukung integrasi SSO dengan jejaring sosial seperti Facebook atau Twitter, memungkinkan pengguna untuk menggunakan akun yang sudah mereka miliki dan yang mereka sukai.



Aliran OpenID Connect terlihat sama dengan OAuth. Satu-satunya perbedaan adalah bahwa dalam permintaan awal, cakupan spesifik yang digunakan adalah openid , dan Klien akhirnya menerima Token Akses dan Token ID .



Sama seperti dalam aliran OAuth, Token Akses di OpenID Connect adalah nilai yang tidak dipahami oleh Klien . Dari sudut pandang Klien , Access Token mewakili serangkaian karakter tertentu yang dikirimkan bersama dengan setiap permintaan ke Server Sumber Daya , yang menentukan apakah token itu valid. ID Token sangat berbeda.

ID Token adalah JWT

ID Token adalah string karakter yang diformat khusus yang dikenal sebagai JSON Web Token atau JWT (terkadang token JWT diucapkan “jots”) . JWT mungkin tampak seperti omong kosong yang tidak dapat dipahami oleh orang luar, tetapi Klien dapat mengekstraksi berbagai informasi dari JWT, seperti ID, nama pengguna, waktu login akun, tanggal kedaluwarsa ID Token , dan upaya untuk campur tangan dalam JWT. Data di dalam Token ID disebut klaim .



Dalam kasus OIDC, ada juga cara standar di mana Klien dapat meminta informasi identitas tambahan dari Server Otorisasi , misalnya, alamat email menggunakan Token Akses .

Pelajari lebih lanjut tentang OAuth dan OIDC.

Jadi, kami meninjau secara singkat bagaimana OAuth dan OIDC bekerja. Siap menggali lebih dalam? Berikut adalah sumber daya tambahan untuk membantu Anda mempelajari lebih lanjut tentang OAuth 2.0 dan OpenID Connect:

• Apa-apaan itu OAuth?
• Tidak ada yang Peduli Tentang OAuth atau OpenID Connect
• Menerapkan Kode Otorisasi OAuth 2.0 dengan Aliran PKCE
• Apa Jenis Hibah OAuth 2.0?
• OAuth 2.0 Dari Baris Perintah
• Membangun Aplikasi Node.js Aman dengan SQL Server

Seperti biasa, jangan ragu untuk berkomentar. Untuk mengikuti inovasi terbaru kami, berlangganan Okta untuk Twitter dan YouTube untuk pengembang!

PS dari penerjemah

Baca juga di blog kami:

• " ABC keamanan di Kubernetes: otentikasi, otorisasi, audit ";
• " Pengguna dan otorisasi RBAC di Kubernetes ";
• " 33+ Alat Keamanan Kubernetes ";
• " Keamanan untuk wadah Docker ."