Implementasi titik otentikasi tunggal


8

Saya sedang membangun serangkaian aplikasi web yang terhubung ke satu titik otentikasi. Pada dasarnya, pengguna mencoba mengakses situs, jika tidak diautentikasi mereka akan diarahkan ke halaman login sistem auth pusat. Setelah mereka berhasil masuk, mereka akan diarahkan ke aplikasi mereka. Sejak saat itu, jika mereka mengakses aplikasi lain, mereka akan secara otomatis masuk.

Beberapa detail tambahan: 1) semua aplikasi akan berjalan di bawah domain yang sama, jadi saya dapat menggunakan cookie domain, yang membuat segalanya lebih mudah; 2) pengguna dapat diberikan akses ke beberapa aplikasi dan bukan yang lain, sehingga perlu diperhitungkan; 3) pengguna harus dapat mengambil izin khusus untuk setiap aplikasi.

Saya telah mengimplementasikan sesuatu, tetapi saya tidak 100% senang dengannya. Saat ini, inilah yang saya miliki: 1) aplikasi web memeriksa keberadaan sesi (khusus untuk aplikasi) dan cookie yang merupakan token JWT yang dikirim dari sistem autentisasi terpusat; 2) jika cookie tidak ada, saya mengarahkan ulang ke halaman login pada sistem auth; 3) setelah pengguna login, mereka akan diarahkan ke aplikasi mereka lewat token JWT; 4) aplikasi memverifikasi token melalui panggilan REST API ke sistem auth (membuat panggilan REST API ini bergantung pada token akses terpisah), jika itu valid, maka token JWT akan disimpan sebagai cookie dan sesi dimulai dengan pengguna masuk; 5) jika sesi aplikasi berakhir, ia memeriksa apakah cookie ada dan jika itu terjadi maka aplikasi melakukan hal yang sama seperti langkah # 4, memverifikasi token dan memulai kembali sesi; 6) pada saat logout, sistem hanya menghapus cookie, memastikan pengguna keluar dari semua aplikasi; 7) jika token berakhir, aplikasi menggunakan token yang kadaluarsa untuk meminta yang baru, di mana tanda tangan token dan klaim lainnya divalidasi sebelum mengeluarkan yang baru, satu-satunya hal yang tidak dapat divalidasi adalah klaim kedaluwarsa.

Untuk memperjelas, keberadaan sesi khusus untuk aplikasi digunakan sehingga Anda tidak harus terus membuat panggilan REST API terus-menerus untuk memverifikasi token. Tetapi mengingat token diverifikasi sekali, apakah aman menggunakan cookie itu sebagai indikator bahwa ada sesi yang valid?

Satu hal yang saya tidak yakin tentang hal itu adalah token saya perlu memiliki sesuatu yang menunjukkan untuk apa aplikasi itu karena panggilan REST API lainnya dapat dibuat menggunakan token untuk mendapatkan beberapa sumber daya yang spesifik untuk aplikasi. Tetapi jika saya mendapatkan token untuk app1 dan kemudian masuk ke app2, app2 akan bergantung pada cookie yang dihasilkan oleh app2. Jadi sepertinya saya ingin memiliki dua token, satu yang dapat disimpan sebagai cookie domain untuk menunjukkan pengguna diautentikasi, dan satu lagi yang sebenarnya akan spesifik aplikasi dan dapat digunakan untuk membuat panggilan REST API untuk aplikasi lain- sumber daya spesifik.

Apakah saya terlalu rumit, atau apakah garis pemikiran saya cocok dengan apa yang dilihat / dilakukan orang lain di sana? Atau ada cara yang lebih elegan untuk melakukan ini? Saya sudah memikirkan untuk mengimplementasikan sesuatu seperti Open ID, tetapi sepertinya sedikit berlebihan untuk kebutuhan kita. Saya ingin ini sesederhana mungkin sehingga saya dapat mendokumentasikan proses dan tim pengembang lain dapat mengembangkan aplikasi yang terhubung ke sistem auth tanpa perlu terlalu banyak bantuan.

Jawaban:


5

Jangan menjadi gila. Tidak ada orang waras yang akan mencoba menulis sesuatu seperti ini dari awal. Gunakan OAuth. Anda dapat menggunakan spesifikasi token JWT Bearer untuk token dan menggunakan cakupan untuk menentukan aplikasi atau sumber daya mana yang dapat diakses pengguna. Ini bukan area yang baik untuk mulai menciptakan kembali roda!


0

Saya baru saja mengikuti panduan di sini yang menjelaskan proses pengaturan untuk otentikasi berbasis token. Salah satu cara yang saya bisa bayangkan melewati beberapa bentuk identifikasi spesifik aplikasi akan menggunakan klaim.

Jadi Anda memiliki situs web A yang mengarahkan Anda ke halaman sistem login Anda. Situs web A juga menyampaikan beberapa data lain seperti ke mana harus mengambil pengguna setelah masuk dan di mana Situs Web A berada. Sistem autentikasi Anda melihat data ini dan menggunakan sakelar dari beberapa formulir yang Anda tambahkan klaim ke token pengguna yang mengidentifikasi ruang lingkup aplikasi mereka saat ini.

Juga untuk membantu memerangi pengguna beralih aplikasi sangat cepat dan masih memiliki akses ke sumber daya aplikasi untuk app1 sementara di app2 membuat access_token Anda berakhir dengan sangat cepat. Dalam menjalankan situs web demo saya dibangun menggunakan panduan di atas tambang berakhir setiap menit, juga penerapan refresh_token membuat semuanya lebih mudah. Langkah lain yang bisa membantu adalah ketika menambahkan klaim kepada pengguna juga menambahkan peran kepada pengguna yang menyatakan mereka ada di situs web.

Kemudian pada app1's / api / endpoint / getData mengatur [Otorisasi (Peran = "App1")], ini akan memastikan bahwa hanya access_token yang berisi peran = App1 dapat menggunakan titik akhir itu kemudian di dalam javascript Anda atau apa pun sisi klien yang menulis skrip Anda menggunakan lakukan pemeriksaan logis untuk kesalahan seperti tidak mengakses titik akhir spesifik dan mungkin pengguna perlu mendapatkan access_token baru menggunakan token penyegaran dan seterusnya dan seterusnya.

Menggunakan panduan yang sama yang saya sebutkan di atas, ikuti tautan itu dan cari ini:

var identity = new ClaimsIdentity (context.Options.AuthenticationType);

Seperti yang Anda lihat identitasnya menambahkan klaim yang pada dasarnya hanya nilai-nilai yang akan dienkapsulasi di dalam access_token.

Sekarang ketika pengguna memanggil api web Anda yang memiliki atribut resmi di atasnya, Anda cukup melakukan pengecekan pada klaim yang diklaim pengguna.

Contoh dari ini dapat ditemukan di sini .

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.