OpenID Connect memiliki spesifikasi , ada tutorial, artikel tentang hub dan bukan hub Agak ada gunanya memahat instruksi selangkah demi selangkah lainnya, mulai dari kebingungan mendalam hingga bekerja melalui otorisasi dan otentikasi. Tugas teks di bawah ini berbeda, untuk menggambarkan ide-ide yang mendasari spesifikasi (ada lebih dari satu).
Saya tidak akan langsung membahas topik artikel, tetapi saya akan mulai dengan hal-hal sederhana dan banyak yang jelas. Saya akan melanjutkan dengan cara mereka berkembang dan apa yang mereka bungkus sesuai dengan kebutuhan pelanggan. Saya akan mendekatinya secara historis, yaitu dengan cara dia dilahirkan.
1.
Tugas minimum adalah tidak membiarkan siapa pun mencapai sumber dayanya. Kami menutupnya dengan nama pengguna / kata sandi, yang tahu pasangan nama pengguna dan kata sandi yang tepat akan sampai ke sumber daya, yang tidak - tidak. Hal ini disebut otentikasi , untuk itu Anda dapat menggunakan tidak hanya login dengan kata sandi (kode SMS, misalnya, atau kunci USB perangkat keras), tetapi detail ini tidak penting untuk topik kita. Saya juga akan menghilangkan paragraf wajib tentang bahaya pengiriman kata sandi melalui Internet dalam bentuk terbuka, yang kita semua tidak suka otentikasi akses dasar .
Lebih baik untuk mencatat ini: tidak ada pengguna yang suka memasukkan login dengan kata sandi. Kode dalam SMS tidak lebih baik, dan kunci USB dibenci sama sekali. Agar tidak memaksa pengguna untuk memasukkan login dengan kata sandi untuk setiap permintaan, server dalam menanggapi mereka mengirim garis omong kosong yang disebut kunci sesi . Dan kemudian kunci ini melekat pada setiap permintaan server oleh klien (biasanya dengan header HTTP, tetapi ini tidak penting), dan server memeriksa apakah ada sesi seperti itu.
Sesi dengan kunci - fenomena, menurut definisi, bersifat sementara, rasio emas untuk seumur hidup sesi adalah sekitar "saat tab browser terbuka, tetapi tidak lebih dari satu hari"
2.
Mereka membiarkan siapa pun masuk - itu bagus. Sekarang Anda perlu memahami dengan tepat siapa yang kami lepaskan. Dan tidak hanya untuk menyimpulkan apa yang dia masukkan sebagai nama di sudut kanan atas, tetapi juga untuk memutuskan apa yang membiarkannya masuk dan apa yang tidak.
Dan semua ini disebut - otorisasi . Dan saya tidak yakin tentang Anda, tetapi saya selalu bingung dengan otentikasi. Agar tidak membingungkan - aturan yang relatif mnemonik, "otorisasi" - dari kata "penulis", "penulis" mereka menulis di sampul buku, dan mereka tidak pernah menulis "anggota yang sah dari Persatuan Penulis" di sana. Seorang penulis selalu orang yang sangat spesifik. Jadi otorisasi adalah proses ketika kita memahami siapa sebenarnya yang kita luncurkan dengan login dan kata sandi.
3.
Ok Kami memiliki situs, ada sesuatu rahasia di situs, di pintu masuk ke bagian rahasia kami memerlukan kata sandi, masing-masing hanya ditampilkan rahasianya, dan kami tidak menunjukkan kepada orang asing. Hidup tidak tinggal diam, dan kami memiliki situs lain. Dan di sini kita kembali menemui masalah dari poin 1, tidak ada yang suka memasukkan nama pengguna dan kata sandi! Anda dapat menggabungkan basis pengguna dan ini akan menyelamatkan mereka dari keharusan mendaftar dua kali, tetapi bagaimana cara menyimpannya dari memasukkan kembali login dan kata sandi di pintu masuk? Dengan adanya hal yang sama seperti Kebijakan Asal yang Sama (dan situs kami berada, tentu saja, pada domain yang berbeda, maka cookie dengan kunci sesi tidak saling terlihat)? Di sini, untuk memberikan arti penting saat ini, saya akan memulai poin baru.
4.
SSO , Single Sign On - apa pun implementasinya, Microsoft Kerberos, SAML atau semacamnya OAuth 2.0 , di atasnya OpenID Connect dibuat, tentang yang saya tulis kepada Anda di sini, pada kenyataannya, di bawah tenda selalu ada hal yang sama: ada server terpisah otorisasi , dan siapa pun yang ingin mengotorisasi pengguna mengalihkan pengguna ke sana. Jika pengguna sudah diotorisasi, sesi diambil, dan ia segera terbang kembali dari server otorisasi dan mendapatkan di mana ia ingin. Jika tidak diotorisasi, server otorisasi menyelesaikan masalah ini sebaik mungkin, dengan meminta nama pengguna dengan kata sandi, sebagai aturan, dan jika berhasil, mengirim pengguna kembali.
Selain itu, SAML saat ini solusinya, sehingga untuk mengatakan, sudah ketinggalan zaman. Dan Kerberos umumnya merupakan Microsoft magic tertutup yang sepenuhnya terpisah yang jauh melampaui ruang lingkup protokol HTTP. Baiklah, kita akan fokus pada hal itu. Dan kemudian kita sampai pada masalah berikutnya.
Sudah ada skenario kerja yang dapat dipahami - dalam situasi yang tidak dapat dipahami, kirim pengguna ke server otorisasi, biarkan dia memutuskan apa yang harus dilakukan dengannya dan mengembalikan jawaban yang siap. Tapi bagaimana tepatnya server otorisasi memberi tahu server lain bahwa pengguna diotorisasi? Di sini kita kembali lagi ke ide-ide paragraf satu, yaitu, ke kunci sesi. Mari kita kembali ke dasar-dasar: kehadiran kunci sesi adalah tanda otorisasi, kunci sesi itu sendiri membuka pintu untuk informasi pengguna, dan, Anda tidak akan percaya, untuk informasi sesi. Jadi server otorisasi mengotorisasi dan memberikan kunci sesi ke server lain.
Namun, sekarang tidak lagi disebut kunci sesi, tetapi token .
Lebih tepatnya, (sesuai dengan protokol OAuth 2.0 , yang di atasnya tertulis OpenID Connect), ini adalah dua token sekaligus - Access Token , untuk mengaitkannya ke semua permintaan saat kakek memotong kunci sesi, dan Refresh Token , untuk memperbarui Access Token saat keluar.
Untuk meringkas subtotal. Alih-alih meminta pengguna untuk nama pengguna dan kata sandi, server mengirimkannya ke server lain, server otorisasi terpisah. Dia melakukan semua pekerjaan, dan kemudian memberikan token pertama. Dalam skenario ini, aplikasi diotorisasi, seluler, dan terkadang desktop., Mereka hanya tidak melakukan pengalihan, mereka hanya mengirim server otorisasi JSON dengan nama pengguna dan kata sandi, dan ia mengirim mereka token sebagai tanggapan.
Aplikasi seluler dan desktop dapat melakukan ini. Untuk beberapa alasan mereka dianggap lebih aman daripada web, tetapi web memiliki kehidupan yang lebih rumit.
6.
Di satu sisi, ini tidak lebih rumit, tetapi sebaliknya lebih sederhana. Anda dapat membuat arahan ulang dan tidak mengganggu diri Anda dengan memberikan formulir kata sandi masuk. Di sisi lain, saya benar-benar tidak ingin menyeret token melalui browser secara jelas. Ini hampir sama menjijikkannya dengan kata sandi yang tidak terenkripsi dalam otentikasi akses Dasar . Tapi tidak ada yang mau mengulangi kesalahan mengerikan yang lama itu.
Tidak ada solusi untuk masalah itu sehingga sangat elegan, tetapi berfungsi. Pertama, semuanya berjalan seperti biasa, beralih ke otorisasi, otorisasi itu sendiri. Kemudian, ketika tiba saatnya untuk kembali dengan token, pengalihan terbalik terjadi. Tetapi alih-alih token, kode satu kali dilampirkan ke alamat pengirim. Kode satu kali baru saja dihasilkan oleh server otorisasi hanya untuk momen khusus ini. Dia memiliki waktu hidup yang sangat singkat. Setelah hampir tidak menerima kode satu kali, server lain harus menyodok rok, membesar-besarkan matanya dan bergegas ke server otorisasi lagi, untuk menerima token yang didambakan dari kode satu kali.
Ada sumber daya khusus untuk perjalanan dengan kode token di server otorisasi. Ia menerima, berdasarkan spesifikasi, bukan MENDAPATKAN, tetapi POST. Entah bagaimana itu mengisyaratkan kepada kita bahwa permintaan ini harus dibuat bukan dari browser, tetapi dari server ke server.
Untuk alasan yang sama, pada server otorisasi CORS yang menghargai diri sendiri, permintaan POST dilarang.
7.
Omong-omong, apakah Anda masih ingat tentang otentikasi dan otorisasi? Otentikasi adalah ketika seseorang diizinkan masuk dengan login dan kata sandi, atau tidak diizinkan. Dan otorisasi adalah ketika sudah mulai, mereka mulai mengerti siapa sebenarnya mereka memulai.
Apakah Anda ingat OAuth 2.0 ? Saya menyebutkannya beberapa kali di atas, sebagai semacam fondasi untuk OpenID Connect.
Apakah Anda ingat OpenID Connect ? Artikel ini hanya dia bodoh.
Jadi, OAuth 2.0 adalah otentikasi. Seluruh prosedur yang sebelumnya dijelaskan sedikit membingungkan dengan tiga peserta, kata sandi, kode dan token adalah semua tentang otentikasi, hanya tentang membiarkan seseorang menjalankan suatu tempat. Protokol OAuth 2.0.
OpenID Connect adalah otorisasi. Artinya, dia menambahkan ke OAuth bagian mana itu ternyata siapa yang mereka lepaskan.
Untuk melakukan ini, satu lagi ditambahkan ke daftar token, itu disebut ID Token . Mereka yang mengikuti tautan mungkin terkejut melihat tidak ada Token ID di dalamnya. Biarkan kejutan tidak berubah menjadi ketakutan, ID Token ini adalah JWT yang dikembalikan sebagai boneka bersarang base64 yang dikodekan dalam JSON yang sama dengan Access Token dan Refresh Token. Bagaimanapun, segala sesuatu yang Anda ingin tahu tentang pengguna ada di dalam dirinya.
Dan ada juga sumber daya khusus pada server otorisasi yang disebut userinfo, di mana Anda dapat mengetuk dengan Access Token dan mendapatkan JSON yang sama sebagai respons seperti pada ID Token. Tapi mengapa itu diperlukan jika Token ID sudah ada di sana? Pertanyaan kepada penulis spec.
OpenID Connect juga berisi deskripsi berbagai bidang informasi pengguna. Bagaimana saya bisa mendapatkan informasi ini, tepat selama otorisasi atau kapan saja setelahnya. Dan deskripsi tentang bagaimana dan kapan pengguna akan memungkinkan Anda untuk menggunakan informasi ini.
Atau tidak mengizinkannya. Singkatnya, OpenID Connect 1.0 dirancang.
8.
Perada kecil dalam protokol. Saya harap Anda cukup lelah membaca artikel saat ini, agar tidak terlalu memperhatikan item ini, hanya dengan menjalankannya melalui mata. Di sini saya akan menyebutkan parameter yang ada dalam spesifikasi, dan mereka membawa beberapa beban semantik, tetapi mereka tidak terkait langsung dengan implementasi ide itu sendiri. Pada dasarnya, mereka menambah keamanan, baik, atau hanya memungkinkan Anda untuk mentransfer beberapa informasi dari salah satu peserta dalam proses ke yang lain, jika perlu.
ID Klien dan Rahasia Klien . Klien dalam bahasa protokol OpenID Connect bukanlah browser sama sekali, tetapi server lain yang perlu memberi otorisasi kepada pengguna. Misalkan Anda memiliki situs web, dan Anda ingin melampirkan otorisasi modis ke sana melalui Facebook. Dan melalui googol. Dan tidak begitu modis melalui Twitter. Menerapkan protokol dalam kode tidak akan cukup. Anda juga harus mendaftar di Facebook, dan di Google, dan di Twitter, tetapi bukan sebagai pengguna, tetapi sebagai klien yang, sebagai server, dapat menggunakan otorisasi mereka. Saat mendaftar, Anda akan menerima ID klien dan Rahasia Klien dari facebook bersyarat. Dan ketika meminta otorisasi, antara lain, kirim ID Klien. Dan ketika Anda menggunakan kode satu kali untuk token, Rahasia Klien juga akan meminta Anda.
Arahkan ulang URI . Semuanya sederhana di sini. Saat mengirim pengguna ke facebook bersyarat untuk masuk, Anda harus memberi tahu Facebook tempat mengembalikan kode dan token kepadanya setelah otorisasi. Tentu saja, Anda masih memberinya ID Klien Anda. Tetapi URI Pengalihan terpisah memungkinkan Anda untuk mengarahkan kembali setelah mengotorisasi pengguna yang berbeda ke halaman yang berbeda, misalnya admin ke panel admin, dan pengguna biasa ke halaman pribadi mereka. Praktis. Selain itu, daftar yang diizinkan dari URI Pengalihan yang mungkin ditentukan dalam pengaturan klien di facebook bersyarat adalah keamanan tambahan.
Lingkup Ini adalah daftar yang ingin diketahui server tentang pengguna dari server otorisasi. Nilai-nilai dalam daftar dipisahkan oleh spasi, openid harus wajib di antara mereka, dan kemudian membaca spesifikasinya.
Negara . Ingat kode satu kali, dengan token mana dikeluarkan, seperti tiket dalam antrian elektronik? Jadi, negara adalah kode, sebaliknya, jika server otorisasi mengeluarkan kode ke server lain sehingga mengembalikannya segera, negara itu memberikan server otorisasi lain ke server itu untuk mengembalikannya ketika mengarahkan ulang. Dia diperlukan, seperti yang saya mengerti, jika server lain sudah berhasil membuat sesi sendiri sehingga tidak hilang di semua pengalihan ini.
Ada parameter lain, seperti jenis permintaan otorisasi dan token seumur hidup, tetapi untuk memahami mengapa Anda tidak membutuhkannya.
Kesimpulannya. Saya benar-benar berharap bahwa pembacaan teks di atas yang terlalu bijaksana dan tidak terpusat membantu Anda menangkap ide-ide yang mendasari beberapa protokol kontrol akses modern. Tetapi mulai untuk mengimplementasikan, atau hanya untuk mengkonfigurasi salah satunya, buka spesifikasi, temukan tutorial yang bagus, dan ikuti setiap kata dan setiap huruf dengan hati-hati. Dan biarkan pemahaman ide membangkitkan intuisi dalam diri Anda. Dan intuisi, biarkan ia menggigit Anda di mahkota setiap kali Anda melewatkan parameter yang tidak begitu signifikan pada pandangan pertama, atau pengaturan, dan biarkan lubang ini untuk tangan kecil yang berkeringat.
Ingatlah bahwa ini semua adalah keamanan yang sama, dan peraturannya, tidak peduli seberapa bodoh dan tidak berarti kelihatannya, ditulis dengan darah. Yah, mungkin tidak dengan darah, toh itu bukan ukuran keamanan di pengecoran, setelah semua, tetapi uang dan reputasi pasti, dan uang dan reputasi juga bukan hal-hal yang harus mudah Anda lempar seperti itu.
Terima kasih kepada JM untuk fakta bahwa teks yang Anda baca jauh lebih baik daripada yang saya tulis.
Selamat mencoba, dan jangan lupa untuk memperbarui sertifikat Anda tepat waktu.