🥇Panduan Bergambar untuk OAuth dan OpenID Connect

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

Di Zaman Batu Internet, berbagi informasi antar layanan itu mudah. Anda cukup memberikan login dan kata sandi Anda dari satu layanan ke layanan lain, sehingga dia masuk ke akun Anda dan menerima informasi apa pun yang dia butuhkan.

"Beri aku rekening bankmu." “Kami berjanji bahwa semuanya akan baik-baik saja dengan kata sandi dan uang. Itu jujur, jujur!" *hihihi*

Kengerian! Tidak seorang pun boleh meminta pengguna untuk membagikan nama pengguna dan kata sandi, kredensial, dengan layanan lain. Tidak ada jaminan bahwa organisasi di balik layanan ini akan menjaga keamanan data dan tidak akan mengumpulkan lebih banyak informasi pribadi dari yang diperlukan. Ini mungkin terdengar gila, tetapi beberapa aplikasi masih menggunakan praktik ini!

Saat ini ada satu standar yang memungkinkan satu layanan menggunakan data layanan lain dengan aman. Sayangnya, standar tersebut banyak menggunakan jargon dan istilah yang mempersulit pemahaman mereka. Tujuan dari materi ini adalah untuk menjelaskan cara kerjanya menggunakan ilustrasi sederhana (Apakah menurut Anda gambar saya mirip dengan coretan anak-anak? Baiklah!).

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

Hadirin sekalian, selamat datang: 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] (Atau izin [izin]) sering menelepon otorisasi [otorisasi] atau bahkan otorisasi yang didelegasikan [otorisasi yang didelegasikan]. Dengan standar ini, Anda mengizinkan aplikasi untuk membaca data atau menggunakan fungsi aplikasi lain atas nama Anda tanpa memberikan kata sandi Anda. Kelas!

Sebagai contoh, katakanlah Anda menemukan situs yang disebut "Permainan Sial Hari Ini" [Pelajaran Mengerikan Hari Ini] dan memutuskan untuk mendaftar untuk menerima permainan kata-kata harian dalam bentuk pesan teks di telepon. Anda sangat menyukai situs ini, dan Anda memutuskan untuk membaginya dengan semua teman Anda. Lagi pula, semua orang suka permainan kata-kata menyeramkan, bukan?

“Permainan kata yang tidak menguntungkan hari ini: Pernah mendengar tentang pria yang kehilangan separuh tubuh kirinya? 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, Terrible Pun of the Day bisa mengundang semua temanmu dengan sendirinya! Untuk melakukan ini, Anda hanya perlu membuka akses ke email kontak Anda - situs itu sendiri akan mengirimi mereka undangan (aturan OAuth)!

“Semua orang suka permainan kata-kata! - Telah masuk? “Apakah Anda ingin mengizinkan situs web Terrible Pun of the Day untuk mengakses daftar kontak Anda? - Terima kasih! Mulai sekarang, kami akan mengirimkan pengingat setiap hari kepada semua orang yang Anda kenal, hingga akhir zaman! Kamu adalah teman terbaik!"

Pilih layanan email Anda.
Jika perlu, buka situs email dan masuk ke akun Anda.
Berikan izin Pun Terrible of the Day untuk mengakses kontak Anda.
Kembali ke situs Pun of the Day yang Mengerikan.

Jika Anda berubah pikiran, aplikasi yang menggunakan OAuth juga menyediakan cara untuk mencabut akses. Setelah Anda memutuskan bahwa Anda tidak lagi ingin berbagi kontak dengan Pun yang Mengerikan Hari Ini, Anda dapat membuka situs email dan menghapus situs pun dari daftar aplikasi resmi.

Alur OAuth

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

Sebelum menyelami detail tentang cara kerja OAuth, mari kita bicara tentang arti beberapa istilah:

Pemilik Sumber Daya:

Itu adalah kamu! Anda memiliki kredensial, data, dan mengontrol semua aktivitas yang mungkin dilakukan di akun Anda.
Pelanggan:

Sebuah aplikasi (misalnya, layanan Terrible Pun of the Day) yang ingin mengakses atau melakukan tindakan tertentu atas nama Pemilik Sumber Daya'а.
Server Otorisasi:

Aplikasi yang tahu Pemilik Sumber Daya'a dan di mana u Pemilik Sumber Daya'a sudah punya akun.
server sumber daya:

Antarmuka pemrograman aplikasi (API) atau layanan itu Pelanggan ingin menggunakan atas nama Pemilik Sumber Daya'а.
Arahkan ulang URI:

Tautan itu Server Otorisasi akan mengarahkan ulang Pemilik Sumber Daya'dan setelah memberikan izin Pelanggan'pada. Kadang-kadang disebut sebagai "URL Panggilan Balik".
Jenis Respons:

Jenis informasi yang diharapkan diterima Pelanggan. Yang paling umum Jenis Respons'ohm adalah kode, yaitu Pelanggan mengharapkan untuk menerima Kode Otorisasi.
Cakupan:

Ini adalah penjelasan rinci tentang izin yang diperlukan Pelanggan'y, seperti mengakses data atau melakukan tindakan tertentu.
Persetujuan:

Server Otorisasi dibutuhkan Scopesdiminta Pelanggan'om, dan bertanya Pemilik Sumber Daya'a, apakah dia siap menyediakan Pelanggan'memiliki izin yang sesuai.
ID pelanggan:

ID ini digunakan untuk mengidentifikasi Pelanggan'a on Server Otorisasi'e.
Rahasia Klien:

Ini adalah kata sandi yang hanya diketahui Pelanggan'kamu dan Server Otorisasi'pada. Ini memungkinkan mereka untuk berbagi informasi secara pribadi.
Kode Otorisasi:

Kode sementara dengan masa berlaku singkat, yaitu Pelanggan menyediakan Server Otorisasi'y sebagai gantinya akses Token.
akses Token:

Kunci yang akan digunakan klien untuk berkomunikasi server sumber daya'om. Semacam lencana atau kartu kunci yang menyediakan Pelanggan'memiliki izin untuk meminta data atau melakukan tindakan pada server sumber daya'e atas nama Anda.

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

Sekarang setelah kita membahas konsep inti OAuth 2.0, mari kembali ke contoh kita dan lihat lebih dekat apa yang terjadi di alur OAuth.

Anda, Pemilik Sumber Daya, Anda ingin menyediakan layanan Pun Hari Ini yang Mengerikan (Pelanggany) akses ke kontak Anda sehingga mereka dapat mengirim undangan ke semua teman Anda.
Pelanggan mengalihkan browser ke halaman Server Otorisasi'a dan sertakan dalam kueri ID pelanggan, Arahkan ulang URI, Jenis Respons dan satu atau lebih Scopes (izin) yang dibutuhkan.
Server Otorisasi memverifikasi Anda, meminta nama pengguna dan kata sandi jika perlu.
Server Otorisasi menampilkan formulir Persetujuan (konfirmasi) dengan daftar semua Scopesdiminta Pelanggan'om. Anda setuju atau menolak.
Server Otorisasi mengarahkan Anda ke situs Pelanggan'a, menggunakan Arahkan ulang URI dengan Kode Otorisasi (kode otorisasi).
Pelanggan berkomunikasi langsung dengan Server Otorisasi'ohm (melewati browser Pemilik Sumber Daya'a) dan aman mengirim ID pelanggan, Rahasia Klien и Kode Otorisasi.
Server Otorisasi memeriksa data dan merespon dengan akses Token'om (token akses).
Sekarang Pelanggan bisa menggunakan akses Token untuk mengirim permintaan ke server sumber daya untuk mendapatkan daftar kontak.

ID dan Rahasia Klien

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

"- Halo! Saya ingin bekerja sama dengan Anda! - Tentu, bukan masalah! Ini ID dan Rahasia Klien Anda!”

Namanya mengisyaratkan bahwa Rahasia Klien harus dirahasiakan sehingga hanya Klien dan Server Otorisasi yang mengetahuinya. Lagi pula, dengan bantuannya Server Otorisasi mengkonfirmasi kebenaran Klien.

Tapi bukan itu saja... Sambutlah OpenID Connect!

OAuth 2.0 hanya dirancang untuk otorisasi - untuk menyediakan akses ke data dan fungsi dari satu aplikasi ke aplikasi lainnya. OpenID Connect (OIDC) adalah lapisan tipis di atas OAuth 2.0 yang menambahkan info masuk dan detail profil pengguna yang masuk ke akun. Organisasi sesi login sering disebut sebagai autentikasi [autentikasi], dan informasi tentang pengguna yang masuk ke sistem (yaitu tentang Pemilik Sumber Daya'e), - data pribadi [identitas]. Jika Server Otorisasi mendukung OIDC, terkadang disebut sebagai penyedia data pribadi [penyedia identitas]karena menyediakan Pelanggan'memiliki informasi tentang Pemilik Sumber Daya'e.

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

Aliran (aliran) OpenID Connect terlihat sama seperti dalam kasus OAuth. Satu-satunya perbedaan adalah bahwa dalam permintaan utama, cakupan spesifik yang digunakan adalah openid, - A Pelanggan akhirnya menjadi seperti akses TokenDan Token ID.

Sama seperti di aliran OAuth, akses Token di OpenID Connect, ini adalah beberapa nilai yang tidak jelas Pelanggan'pada. Dari sudut pandang Pelanggan'A akses Token mewakili serangkaian karakter yang diteruskan bersama dengan setiap permintaan ke server sumber daya'y, yang menentukan apakah token itu valid. Token ID mewakili hal yang sama sekali berbeda.

Token ID adalah JWT

Token ID adalah string karakter yang diformat khusus yang dikenal sebagai JSON Web Token atau JWT (terkadang token JWT diucapkan seperti "jots"). Bagi pengamat luar, JWT mungkin tampak seperti omong kosong yang tidak bisa dipahami, tapi Pelanggan dapat mengekstrak berbagai informasi dari JWT, seperti ID, nama pengguna, waktu masuk, tanggal kedaluwarsa Token ID'a, adanya upaya mengganggu JWT. Data di dalam Token ID'a disebut aplikasi [klaim].

Dalam kasus OIDC, ada juga cara standar yang digunakan Pelanggan dapat meminta informasi tambahan tentang individu tersebut [identitas] dari Server Otorisasi'a, misalnya, alamat email menggunakan akses Token.

Pelajari lebih lanjut tentang OAuth dan OIDC

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

Seperti biasa, jangan ragu untuk berkomentar. Untuk tetap up to date dengan berita terbaru kami, berlangganan Twitter и Youtube Okta untuk pengembang!

Panduan Bergambar untuk OAuth dan OpenID Connect