🥇Panduan Bergambar untuk OAuth dan OpenID Connect

Catatan. terjemah: Artikel hebat oleh Okta ini menerangkan cara OAuth dan OIDC (OpenID Connect) berfungsi dengan cara yang mudah dan jelas. Pengetahuan ini akan berguna kepada pembangun, pentadbir sistem, dan juga "pengguna biasa" aplikasi web popular, yang kemungkinan besar turut bertukar data sulit dengan perkhidmatan lain.

Pada Zaman Batu Internet, berkongsi maklumat antara perkhidmatan adalah mudah. Anda hanya memberikan log masuk dan kata laluan anda dari satu perkhidmatan ke perkhidmatan yang lain, supaya dia memasuki akaun anda dan menerima sebarang maklumat yang diperlukannya.

"Beri saya akaun bank anda." “Kami berjanji bahawa semuanya akan baik-baik saja dengan kata laluan dan wang. Itu jujur, jujur!" *Hee hee*

Seram! Tiada sesiapa pun sepatutnya memerlukan pengguna untuk berkongsi nama pengguna dan kata laluan, kelayakan, dengan perkhidmatan lain. Tiada jaminan bahawa organisasi di sebalik perkhidmatan ini akan memastikan data selamat dan tidak akan mengumpul lebih banyak maklumat peribadi daripada yang diperlukan. Ia mungkin kedengaran gila, tetapi sesetengah apl masih menggunakan amalan ini!

Hari ini terdapat satu standard yang membenarkan satu perkhidmatan menggunakan data yang lain dengan selamat. Malangnya, piawaian tersebut menggunakan banyak jargon dan istilah, yang merumitkan pemahaman mereka. Tujuan bahan ini adalah untuk menerangkan cara ia berfungsi menggunakan ilustrasi mudah (Adakah anda fikir lukisan saya menyerupai daubing kanak-kanak? Oh well!).

By the way, panduan ini juga tersedia dalam format video:

Tuan-tuan dan puan-puan, dialu-alukan: OAuth 2.0

OAuth 2.0 ialah standard keselamatan yang membolehkan satu aplikasi mendapat kebenaran untuk mengakses maklumat dalam aplikasi lain. Urutan langkah untuk mengeluarkan permit [kebenaran] (Atau persetujuan [persetujuan]) sering menelefon kebenaran [kebenaran] atau bahkan kuasa yang diwakilkan [diwakilkan kebenaran]. Dengan piawaian ini, anda membenarkan aplikasi membaca data atau menggunakan fungsi aplikasi lain bagi pihak anda tanpa memberikan kata laluan anda. Kelas!

Sebagai contoh, katakan anda menemui tapak yang dipanggil "Unlucky Pun of the Day" [Perkataan Mengerikan Hari Ini] dan memutuskan untuk mendaftar di atasnya untuk menerima permainan harian dalam bentuk mesej teks di telefon. Anda sangat menyukai tapak tersebut, dan anda memutuskan untuk berkongsinya dengan semua rakan anda. Lagipun, semua orang suka permainan yang menyeramkan, bukan?

“Perkataan malang pada hari ini: Pernahkah anda mendengar tentang lelaki yang kehilangan separuh kiri badannya? Sekarang dia sentiasa betul!” (terjemahan anggaran, kerana asal mempunyai kata-kata sendiri - lebih kurang transl.)

Adalah jelas bahawa menulis kepada setiap orang daripada senarai kenalan bukanlah satu pilihan. Dan, jika anda sedikit seperti saya, maka anda akan melakukan apa-apa cara untuk mengelakkan kerja yang tidak perlu. Nasib baik, Terrible Pun of the Day boleh menjemput semua rakan anda dengan sendirinya! Untuk melakukan ini, anda hanya perlu membuka akses kepada e-mel kenalan anda - tapak itu sendiri akan menghantar jemputan kepada mereka (peraturan OAuth)!

“Semua orang suka permainan kata-kata! - Sudah mendaftar masuk? “Adakah anda ingin membenarkan laman web Terrible Pun of the Day mengakses senarai kenalan anda? - Terima kasih! Mulai sekarang, kami akan menghantar peringatan setiap hari kepada semua orang yang anda kenali, sehingga akhir zaman! Awak adalah kawan terbaik!"

Pilih perkhidmatan e-mel anda.
Jika perlu, pergi ke tapak mel dan log masuk ke akaun anda.
Beri Kebenaran pada Hari Ini untuk mengakses kenalan anda.
Kembali ke tapak Terrible Pun of the Day.

Sekiranya anda berubah fikiran, aplikasi yang menggunakan OAuth juga menyediakan cara untuk membatalkan akses. Sebaik sahaja anda memutuskan bahawa anda tidak mahu lagi berkongsi kenalan dengan Terrible Pun of the Day, anda boleh pergi ke tapak mel dan mengalih keluar tapak pun daripada senarai aplikasi yang dibenarkan.

Aliran OAuth

Kami baru sahaja melalui apa yang biasa dipanggil aliran [aliran] OAuth. Dalam contoh kami, aliran ini terdiri daripada langkah yang boleh dilihat, serta beberapa langkah yang tidak kelihatan, di mana dua perkhidmatan bersetuju untuk pertukaran maklumat yang selamat. Contoh Terrible Pun of the Day sebelumnya menggunakan aliran OAuth 2.0 yang paling biasa, yang dikenali sebagai aliran "kod kebenaran". [aliran "kod kebenaran"].

Sebelum menyelami butiran tentang cara OAuth berfungsi, mari kita bincangkan tentang maksud beberapa istilah:

Pemilik Sumber:

Ia adalah awak! Anda memiliki bukti kelayakan anda, data anda dan mengawal semua aktiviti yang mungkin dilakukan pada akaun anda.
Pelanggan:

Aplikasi (contohnya, perkhidmatan Terrible Pun of the Day) yang ingin mengakses atau melakukan tindakan tertentu bagi pihak Pemilik Sumber'tetapi.
Pelayan Kebenaran:

Aplikasi yang tahu Pemilik Sumber'a dan di mana u Pemilik Sumber'a sudah mempunyai akaun.
Pelayan Sumber:

Antara muka pengaturcaraan aplikasi (API) atau perkhidmatan yang Pelanggan mahu digunakan bagi pihak Pemilik Sumber'tetapi.
Ubah hala URI:

Pautan itu Pelayan Kebenaran akan mengubah hala Pemilik Sumber'dan selepas memberi kebenaran Pelanggan'pada. Ia kadangkala dirujuk sebagai "URL Panggilan Balik".
Jenis Respons:

Jenis maklumat yang dijangka diterima Pelanggan. Yang paling biasa Jenis Respons'ohm ialah kod, iaitu Pelanggan mengharapkan untuk menerima Kod Kebenaran.
Skop:

Ini adalah penerangan terperinci tentang kebenaran yang diperlukan Pelanggan'y, seperti mengakses data atau melakukan tindakan tertentu.
Persetujuan:

Pelayan Kebenaran mengambil masa Skopdiminta Pelanggan'om, dan bertanya Pemilik Sumber'a, adakah dia bersedia untuk menyediakan Pelanggan'mempunyai kebenaran yang sesuai.
ID pelanggan:

ID ini digunakan untuk mengenal pasti Pelanggan'a pada Pelayan Kebenaran'e.
Rahsia Pelanggan:

Ini adalah kata laluan yang hanya diketahui Pelanggan'u dan Pelayan Kebenaran'pada. Ia membolehkan mereka berkongsi maklumat secara peribadi.
Kod Kebenaran:

Kod sementara dengan tempoh sah yang singkat, yang Pelanggan menyediakan Pelayan Kebenaran'y sebagai pertukaran untuk Token akses.
Token akses:

Kunci yang pelanggan akan gunakan untuk berkomunikasi Pelayan Sumber'om. Sejenis lencana atau kad kunci yang disediakan Pelanggan'mempunyai kebenaran untuk meminta data atau melakukan tindakan pada Pelayan Sumber'e bagi pihak anda.

Nota: Kadangkala Pelayan Kebenaran dan Pelayan Sumber adalah pelayan yang sama. Walau bagaimanapun, dalam beberapa kes, ini mungkin pelayan yang berbeza, walaupun mereka bukan milik organisasi yang sama. Sebagai contoh, Pelayan Kebenaran mungkin perkhidmatan pihak ketiga yang dipercayai oleh Pelayan Sumber.

Memandangkan kita telah membincangkan konsep teras OAuth 2.0, mari kita kembali kepada contoh kita dan lihat dengan lebih dekat apa yang berlaku dalam aliran OAuth.

awak, Pemilik Sumber, anda ingin menyediakan perkhidmatan Pun of the Day yang Mengerikan (Pelanggany) akses kepada kenalan anda supaya mereka boleh menghantar jemputan kepada semua rakan anda.
Pelanggan mengubah hala pelayar ke halaman Pelayan Kebenaran'a dan masukkan dalam pertanyaan ID pelanggan, Ubah hala URI, Jenis Respons dan satu atau lebih Skop (keizinan) yang diperlukannya.
Pelayan Kebenaran mengesahkan anda, meminta nama pengguna dan kata laluan jika perlu.
Pelayan Kebenaran memaparkan borang Persetujuan (pengesahan) dengan senarai semua Skopdiminta Pelanggan'om. Anda bersetuju atau menolak.
Pelayan Kebenaran mengubah hala anda ke tapak Pelanggan'a, menggunakan Ubah hala URI dengan Kod Kebenaran (kod kebenaran).
Pelanggan berkomunikasi secara langsung dengan Pelayan Kebenaran'ohm (memintas pelayar Pemilik Sumber'a) dan selamat menghantar ID pelanggan, Rahsia Pelanggan и Kod Kebenaran.
Pelayan Kebenaran menyemak data dan bertindak balas dengan Token akses'om (token akses).
Sekarang Pelanggan boleh digunakan Token akses untuk menghantar permintaan kepada Pelayan Sumber untuk mendapatkan senarai kenalan.

ID Pelanggan dan Rahsia

Lama sebelum anda membenarkan Terrible Pun of the Day mengakses kenalan anda, Pelanggan dan Pelayan Kebenaran telah mewujudkan hubungan kerja. Pelayan Kebenaran menjana ID Pelanggan dan Rahsia Pelanggan (kadangkala dipanggil app ID и Rahsia Apl) dan menghantarnya kepada Klien untuk interaksi lanjut dalam OAuth.

"- Hello! Saya ingin bekerja dengan anda! - Sudah tentu, tidak menjadi masalah! Inilah ID Pelanggan dan Rahsia anda!”

Nama itu membayangkan bahawa Rahsia Pelanggan mesti dirahsiakan supaya hanya Pelanggan dan Pelayan Kebenaran yang mengetahuinya. Lagipun, dengan bantuannya, Pelayan Kebenaran mengesahkan kebenaran Klien.

Tetapi bukan itu sahaja... Sila mengalu-alukan OpenID Connect!

OAuth 2.0 hanya direka untuk kebenaran - untuk menyediakan akses kepada data dan fungsi dari satu aplikasi ke aplikasi yang lain. OpenID Connect (OIDC) ialah lapisan nipis di atas OAuth 2.0 yang menambahkan butiran log masuk dan profil pengguna yang dilog masuk ke akaun. Organisasi sesi log masuk sering dirujuk sebagai pengesahan [pengesahan], dan maklumat tentang pengguna yang log masuk ke dalam sistem (iaitu tentang Pemilik Sumber'e), - data peribadi [identiti]. Jika Pelayan Kebenaran menyokong OIDC, ia kadangkala dirujuk sebagai pembekal data peribadi [pembekal identiti]kerana ia menyediakan Pelanggan'mempunyai maklumat tentang Pemilik Sumber'e.

OpenID Connect membolehkan anda melaksanakan senario di mana satu log masuk boleh digunakan dalam berbilang aplikasi - pendekatan ini juga dikenali sebagai log masuk tunggal (SSO). Sebagai contoh, aplikasi mungkin menyokong integrasi SSO dengan rangkaian sosial seperti Facebook atau Twitter, membenarkan pengguna menggunakan akaun yang telah mereka miliki dan lebih suka menggunakannya.

Aliran (aliran) OpenID Connect kelihatan sama seperti dalam kes OAuth. Satu-satunya perbezaan ialah dalam permintaan utama, skop khusus yang digunakan ialah openid, - A Pelanggan akhirnya menjadi seperti Token aksesDan Token ID.

Sama seperti dalam aliran OAuth, Token akses dalam OpenID Connect, ini adalah beberapa nilai yang tidak jelas Pelanggan'pada. Dari sudut pandangan Pelanggan'A Token akses mewakili rentetan aksara yang dihantar bersama setiap permintaan kepada Pelayan Sumber'y, yang menentukan sama ada token itu sah. Token ID adalah agak berbeza.

Token ID ialah JWT

Token ID ialah rentetan aksara yang diformat khas yang dikenali sebagai JSON Web Token atau JWT (kadangkala token JWT disebut seperti "jots"). Bagi pemerhati luar, JWT mungkin kelihatan seperti omong kosong yang tidak dapat difahami, tetapi Pelanggan boleh mengekstrak pelbagai maklumat daripada JWT, seperti ID, nama pengguna, masa log masuk, tarikh tamat tempoh Token ID'a, kehadiran percubaan untuk mengganggu JWT. Data di dalam Token ID'a dipanggil aplikasi [tuntutan].

Dalam kes OIDC, terdapat juga cara standard Pelanggan boleh meminta maklumat tambahan tentang individu tersebut [identiti] daripada Pelayan Kebenaran'a, sebagai contoh, alamat e-mel menggunakan Token akses.

Ketahui lebih lanjut tentang OAuth dan OIDC

Jadi, kami menyemak secara ringkas cara OAuth dan OIDC berfungsi. Bersedia untuk menggali lebih dalam? Berikut ialah sumber tambahan untuk membantu anda mengetahui lebih lanjut tentang OAuth 2.0 dan OpenID Connect:

Seperti biasa, sila komen. Untuk mengikuti perkembangan berita terkini kami, langgan Twitter и Youtube Okta untuk pemaju!

Panduan Berilustrasi untuk OAuth dan OpenID Connect