Otentikasi tenang


745

Apa yang dimaksud dengan RESTful Authentication dan bagaimana cara kerjanya? Saya tidak dapat menemukan ikhtisar yang baik di Google. Satu-satunya pengertian saya adalah Anda melewatkan kunci sesi (remeberal) di URL, tetapi ini bisa sangat salah.


3
Ketika saya google Otentikasi Restful saya menemukan selusin plugin RoR. Saya berasumsi itu BUKAN yang Anda cari. Jika tidak RoR, lalu bahasa apa? Server web apa?
S.Lott

2
Tidak akan salah besar jika Anda menggunakan HTTPS. Permintaan HTTP lengkap bersama dengan URL akan dienkripsi.
Bharat Khatri

4
@ BharatKhatri: Ya itu akan. Saya tidak akan pernah memberikan informasi sensitif di URL yang terlihat oleh pengguna. Informasi ini jauh lebih mungkin bocor untuk tujuan praktis. HTTPS tidak dapat membantu untuk kebocoran yang tidak disengaja.
Jo So

2
@ jcoffland: Apa yang Anda maksud dengan otentikasi TENANG nyata? Saya tertarik karena saya baru saja menerapkan cara ketiga dari jawaban yang diterima, namun saya tidak senang dengan itu (saya tidak suka param tambahan di URL).
BlueLettuce16

4
beberapa orang menggunakan jwt.io/introduction untuk menyelesaikan ini .. Saya melakukan penelitian tentang ini sekarang untuk menyelesaikan kasus saya: stackoverflow.com/questions/36974163/… >> Semoga ini akan bekerja dengan baik.
toha

Jawaban:


586

Bagaimana menangani otentikasi dalam arsitektur RESTful Client-Server adalah masalah perdebatan.

Secara umum, ini dapat dicapai, dalam SOA melalui dunia HTTP melalui:

  • Autentikasi dasar HTTP melalui HTTPS;
  • Cookie dan manajemen sesi;
  • Token dalam tajuk HTTP (mis. OAuth 2.0 + JWT);
  • Otentikasi kueri dengan parameter tanda tangan tambahan.

Anda harus beradaptasi, atau bahkan lebih baik mencampur teknik-teknik itu, agar sesuai dengan arsitektur perangkat lunak Anda.

Setiap skema otentikasi memiliki PRO dan Kontra sendiri, tergantung pada tujuan kebijakan keamanan dan arsitektur perangkat lunak Anda.

Autentikasi dasar HTTP melalui HTTPS

Solusi pertama ini, berdasarkan pada protokol HTTPS standar, digunakan oleh sebagian besar layanan web.

GET /spec.html HTTP/1.1
Host: www.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Sangat mudah untuk diimplementasikan, tersedia secara default di semua browser, tetapi memiliki beberapa kelemahan yang diketahui, seperti jendela otentikasi mengerikan yang ditampilkan pada Browser, yang akan bertahan (tidak ada fitur seperti LogOut di sini), beberapa konsumsi CPU tambahan sisi server, dan fakta bahwa nama pengguna dan kata sandi ditransmisikan (melalui HTTPS) ke Server (seharusnya lebih aman untuk membiarkan kata sandi tetap hanya di sisi klien, selama entri keyboard, dan disimpan sebagai hash aman di Server) .

Kami dapat menggunakan Otentikasi Digest , tetapi juga memerlukan HTTPS, karena rentan terhadap serangan MiM atau Putar Ulang , dan khusus untuk HTTP.

Sesi melalui Cookie

Sejujurnya, sesi yang dikelola di Server tidak benar-benar tanpa kewarganegaraan.

Satu kemungkinan bisa mempertahankan semua data dalam konten cookie. Dan, berdasarkan desain, cookie ditangani di sisi Server (Klien, pada kenyataannya, bahkan tidak mencoba untuk menafsirkan data cookie ini: cookie hanya dikembalikan ke server pada setiap permintaan berturut-turut). Tetapi data cookie ini adalah data status aplikasi, jadi klien harus mengelolanya, bukan server, di dunia Stateless murni.

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123

Teknik cookie itu sendiri adalah HTTP-linked, jadi itu tidak benar-benar tenang, yang seharusnya protokol-independen, IMHO. Ini rentan terhadap serangan MiM atau Replay .

Diberikan melalui Token (OAuth2)

Alternatifnya adalah dengan meletakkan token di dalam header HTTP sehingga permintaan dikonfirmasi. Inilah yang dilakukan OAuth 2.0. Lihat RFC 6749 :

 GET /resource/1 HTTP/1.1
 Host: example.com
 Authorization: Bearer mF_9.B5f-4.1JqM

Singkatnya, ini sangat mirip dengan cookie dan menderita masalah yang sama: tidak stateless, bergantung pada detail transmisi HTTP, dan tunduk pada banyak kelemahan keamanan - termasuk MiM dan Replay - sehingga harus digunakan hanya melalui HTTPS. Biasanya, JWT digunakan sebagai token.

Otentikasi Permintaan

Otentikasi kueri terdiri atas penandatanganan setiap permintaan RESTful melalui beberapa parameter tambahan pada URI. Lihat artikel referensi ini .

Itu didefinisikan seperti itu dalam artikel ini:

Semua kueri REST harus diautentikasi dengan menandatangani parameter kueri yang diurutkan dalam huruf kecil, urutan abjad menggunakan kredensial pribadi sebagai token penandatanganan. Penandatanganan harus terjadi sebelum URL menyandikan string kueri.

Teknik ini mungkin lebih kompatibel dengan arsitektur Stateless, dan juga dapat diimplementasikan dengan manajemen sesi ringan (menggunakan sesi di-memori alih-alih kegigihan DB).

Misalnya, berikut ini adalah sampel URI generik dari tautan di atas:

GET /object?apiKey=Qwerty2010

harus ditransmisikan seperti itu:

GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789

String yang ditandatangani adalah /object?apikey=Qwerty2010&timestamp=1261496500dan tanda tangannya adalah hash SHA256 dari string yang menggunakan komponen pribadi dari kunci API.

Caching data sisi server selalu tersedia. Misalnya, dalam kerangka kerja kami, kami menyimpan tanggapan di tingkat SQL, bukan di tingkat URI. Jadi menambahkan parameter tambahan ini tidak merusak mekanisme cache.

Lihat artikel ini untuk beberapa detail tentang RESTful otentikasi dalam kerangka klien-server ORM / SOA / MVC kami, berdasarkan JSON dan REST. Karena kami mengizinkan komunikasi tidak hanya melalui HTTP / 1.1, tetapi juga memberi nama pipa atau pesan GDI (lokal), kami mencoba menerapkan pola otentikasi yang benar-benar tenang, dan tidak bergantung pada kekhususan HTTP (seperti header atau cookie).

Nanti Catatan : menambahkan tanda tangan di URI dapat dilihat sebagai praktik buruk (karena misalnya akan muncul di log server http) sehingga harus dimitigasi, misalnya dengan TTL yang tepat untuk menghindari replay. Tetapi jika log http Anda terganggu, Anda pasti akan memiliki masalah keamanan yang lebih besar.

Dalam praktiknya, Autentikasi Token MAC yang akan datang untuk OAuth 2.0 mungkin merupakan peningkatan besar sehubungan dengan skema saat ini "Diberikan oleh Token". Tapi ini masih dalam proses dan terkait dengan transmisi HTTP.

Kesimpulan

Layak untuk menyimpulkan bahwa REST tidak hanya berbasis HTTP, bahkan jika, dalam praktiknya, itu juga sebagian besar diimplementasikan melalui HTTP. REST dapat menggunakan lapisan komunikasi lainnya. Jadi otentikasi TENANG bukan hanya sinonim dari otentikasi HTTP, apa pun yang dijawab Google. Bahkan seharusnya tidak menggunakan mekanisme HTTP sama sekali tetapi harus diabstraksi dari lapisan komunikasi. Dan jika Anda menggunakan komunikasi HTTP, berkat inisiatif Let's Encrypt, tidak ada alasan untuk tidak menggunakan HTTPS yang tepat, yang diperlukan selain skema otentikasi apa pun.


5
Jika Anda menggunakan Cookiesebagai pengganti yang lebih baik, HTTP Basic AuthAnda dapat melakukan otentikasi yang benar-benar tanpa kewarganegaraan dengan metode untuk mengakhiri otentikasi dan kemampuan untuk keluar. Contoh implementasi dapat menggunakan cookie yang disebut Emulated-HTTP-Basic-Authdengan nilai yang mirip dengan HTTP Basic Auth yang sebenarnya dan sebagai tambahan waktu kedaluwarsa. Logout kemudian dapat diterapkan dengan menghapus cookie itu. Saya kira setiap klien yang dapat mendukung HTTP Basic Auth juga dapat mendukung otentikasi cookie yang dilakukan dengan cara ini.
Mikko Rantalainen

4
@MikkoRantalainen Tapi cookie ini masih akan dikelola oleh server, seperti yang saya tulis. Ini semacam negara tanpa kewarganegaraan, tetapi bukan tanpa kewarganegaraan "murni". Dalam semua kasus, Anda memerlukan kode JavaScript yang didedikasikan untuk login / logout klien, yang sangat mungkin misalnya dengan HTTP Digest Auth - ide yang bagus, tetapi tidak ada manfaat besar, di sini, untuk menemukan kembali roda.
Arnaud Bouchez

4
Saya akan mengklaim bahwa server mengimplementasikan UI dan logika untuk mengkonfigurasi header tetapi header itu sendiri tanpa kewarganegaraan. Klien yang dirancang untuk API dapat melompati menggunakan bantuan server untuk mengonfigurasi header dan hanya meneruskan informasi yang diperlukan yang mirip dengan HTTP Basic Auth. Maksud saya adalah bahwa UAS umum (browser) memiliki implementasi Basic Auth yang buruk sehingga tidak dapat digunakan. Server yang menyediakan emulasi untuk hal-hal yang sama di header lain ( Cookie) dapat digunakan sebagai gantinya.
Mikko Rantalainen

6
Saya kira jawaban yang benar adalah stackoverflow.com/questions/6068113/…
graffic

7
Prompt kata sandi jelek untuk otorisasi HTTP hanya akan muncul jika server memintanya dengan mengirimkan kembali 401 Respons tidak sah. Jika Anda tidak menyukainya, kirimkan saja 403 Forbidden saja. Halaman kesalahan dapat mencakup metode untuk masuk atau tautan ke sana. Namun, tetapi argumen terbesar terhadap cookie DAN otentikasi http (terlepas dari apakah negara adalah sisi server atau sisi klien) adalah bahwa mereka rentan terhadap pemalsuan permintaan lintas situs. Untuk alasan ini, pendekatan terbaik adalah skema Otorisasi kustom, header otorisasi kustom, atau parameter GET atau POST kustom.
Dobes Vandermeer

418

Saya ragu apakah orang-orang dengan antusias meneriakkan "HTTP Authentication" pernah mencoba membuat aplikasi berbasis browser (alih-alih layanan web mesin-ke-mesin) dengan REST (jangan ada pelanggaran yang dimaksudkan - saya hanya berpikir mereka tidak pernah menghadapi komplikasi) .

Masalah yang saya temukan dengan menggunakan Otentikasi HTTP pada layanan RESTful yang menghasilkan halaman HTML untuk dilihat di browser adalah:

  • pengguna biasanya mendapatkan kotak masuk buatan browser yang jelek, yang sangat tidak ramah pengguna. Anda tidak dapat menambahkan pencarian kata sandi, kotak bantuan, dan sebagainya.
  • keluar atau masuk dengan nama lain adalah masalah - browser akan terus mengirim informasi otentikasi ke situs sampai Anda menutup jendela
  • batas waktu itu sulit

Artikel yang sangat mendalam yang membahas poin-poin ini ada di sini , tetapi ini menghasilkan banyak peretasan javascript khusus browser, solusi untuk penyelesaian masalah, dan lain-lain. Karena itu, ini juga tidak kompatibel dengan maju sehingga akan membutuhkan pemeliharaan konstan saat browser baru dirilis. Saya tidak menganggap desain yang bersih dan jernih, ditambah lagi saya merasa ini adalah pekerjaan ekstra dan sakit kepala hanya supaya saya dapat dengan antusias menunjukkan lencana-SISA saya kepada teman-teman saya.

Saya percaya cookie adalah solusinya. Tapi tunggu, kue itu jahat, bukan? Tidak, mereka tidak, cara cookie sering digunakan adalah kejahatan. Cookie itu sendiri hanya sepotong informasi sisi klien, sama seperti info otentikasi HTTP yang akan dilacak oleh browser saat Anda menjelajah. Dan informasi sisi klien ini dikirim ke server pada setiap permintaan, lagi-lagi sama seperti info Otentikasi HTTP. Secara konsep, satu-satunya perbedaan adalah bahwa konten dari bagian sisi klien ini dapat ditentukan oleh server sebagai bagian dari responsnya.

Dengan menjadikan sesi sebagai sumber yang tenang dengan hanya aturan berikut:

  • Sebuah sesi memetakan sebuah kunci untuk user id (dan mungkin terakhir aksi-timestamp untuk timeout)
  • Jika ada sesi , maka itu berarti bahwa kunci tersebut valid.
  • Login berarti POSTing ke / sesi, kunci baru ditetapkan sebagai cookie
  • Logout berarti HAPUS / Sesi / {kunci} (dengan POST yang kelebihan beban, ingatlah, kami adalah browser, dan HTML 5 masih jauh dari dulu)
  • Otentikasi dilakukan dengan mengirimkan kunci sebagai cookie di setiap permintaan dan memeriksa apakah sesi ada dan valid

Satu-satunya perbedaan untuk Otentikasi HTTP, sekarang, adalah bahwa kunci otentikasi dihasilkan oleh server dan dikirim ke klien yang terus mengirimkannya kembali, alih-alih klien yang menghitungnya dari kredensial yang dimasukkan.

converter42 menambahkan bahwa ketika menggunakan https (yang seharusnya), cookie harus disetel dengan aman sehingga info otentikasi tidak pernah dikirim melalui koneksi yang tidak aman. Poin bagus, belum melihatnya sendiri.

Saya merasa bahwa ini adalah solusi yang cukup yang berfungsi dengan baik, tetapi saya harus mengakui bahwa saya tidak cukup ahli keamanan untuk mengidentifikasi lubang potensial dalam skema ini - yang saya tahu adalah bahwa ratusan aplikasi web non-TENANG menggunakan pada dasarnya sama protokol masuk ($ _SESSION dalam PHP, HttpSession di Java EE, dll.). Konten header cookie hanya digunakan untuk membahas sumber daya sisi-server, seperti bahasa terima yang dapat digunakan untuk mengakses sumber daya terjemahan, dan sebagainya. Saya merasa itu sama, tetapi mungkin orang lain tidak? Bagaimana menurutmu, kawan?


68
Ini adalah jawaban pragmatis dan solusi yang diusulkan berhasil. Namun, menggunakan istilah "SISA" dan "sesi" dalam kalimat yang sama hanya salah (kecuali ada juga "tidak" di antaranya;). Dengan kata lain: setiap layanan web yang menggunakan sesi BUKAN ISTIRAHAT (menurut definisi). Jangan salah paham - Anda masih dapat menggunakan solusi ini (YMMV), tetapi istilah "RESTful" tidak dapat digunakan untuk itu. Saya merekomendasikan buku O'Reilly tentang REST yang sangat mudah dibaca dan menjelaskan subjek secara mendalam.
johndodo

23
@ skrebbel: solusi REST murni akan mengirim data otentikasi setiap kali meminta sumber daya, yang kurang sempurna (HTTP Auth melakukan ini). Solusi yang diusulkan berfungsi dan lebih baik untuk sebagian besar kasus penggunaan, tetapi tidak tenang. Tidak perlu perang, saya menggunakan solusi ini juga. Saya hanya tidak mengklaim itu tenang. :)
johndodo

94
Oh ayolah, berikan contoh. Apa itu cara lain, yang bekerja dengan baik? Saya benar-benar ingin tahu. HTTP Auth jelas tidak, Anda tidak dapat keluar tanpa menutup browser dan Anda tidak dapat menawarkan UX login yang layak tanpa banyak JS yang tidak kompatibel dengan browser yang khusus di masa mendatang. Saya tidak terlalu peduli tentang "murni RESTful" vs "hampir RESTful" dan seluruh perdebatan agama yang terkait, tetapi jika Anda mengatakan ada beberapa cara, Anda harus menjelaskannya.
skrebbel

15
Otentikasi benar-benar tenang dengan agen pengguna dunia nyata (alias "browser") terdiri dari cookie yang berisi nilai Otentikasi HTTP. Dengan cara ini server dapat menyediakan UI untuk memasukkan login dan kata sandi dan server dapat memaksa keluar (dengan menghapus cookie). Selain itu, alih-alih merespons 401 untuk meminta login saat otentikasi gagal, server harus menggunakan redirect sementara ke layar login dan setelah login sukses gunakan redirect sementara kembali ke lokasi sebelumnya. Plus server harus menyematkan tindakan logout (formulir POST) ke hampir setiap halaman untuk pengguna yang masuk.
Mikko Rantalainen

15
Saya tidak melihat ada yang salah dengan menggunakan "istirahat" dan "sesi" dalam kalimat yang sama selama jelas bahwa sesi hanya ada di sisi klien. Saya tidak yakin mengapa masalah besar dibuat tentang konsep ini.
Joe Phillips

140

Sudah cukup dikatakan tentang topik ini oleh orang-orang baik di sini. Tapi ini 2 sen saya.

Ada 2 mode interaksi:

  1. manusia-ke-mesin (HTM)
  2. mesin-ke-mesin (MTM)

Mesin adalah penyebut umum, dinyatakan sebagai API REST, dan aktor / kliennya adalah manusia atau mesin.

Sekarang, dalam arsitektur yang benar-benar tenang, konsep kewarganegaraan menyiratkan bahwa semua status aplikasi yang relevan (artinya status sisi klien) harus disertakan dengan setiap permintaan. Yang relevan, ini berarti bahwa apa pun yang diperlukan oleh REST API untuk memproses permintaan dan melayani respons yang sesuai.

Ketika kami mempertimbangkan ini dalam konteks aplikasi manusia-ke-mesin, "berbasis browser" seperti yang ditunjukkan Skrebbel di atas, ini berarti bahwa aplikasi (web) yang berjalan di browser akan perlu mengirimkan statusnya dan informasi yang relevan dengan setiap permintaan itu membuat ke REST API back end.

Pertimbangkan ini: Anda memiliki aset data yang terpapar platform data / API REST. Mungkin Anda memiliki platform BI swalayan yang menangani semua kubus data. Tetapi Anda ingin pelanggan (manusia) Anda mengakses ini melalui (1) aplikasi web, (2) aplikasi seluler, dan (3) beberapa aplikasi pihak ketiga. Pada akhirnya, bahkan rantai MTM mengarah ke HTM - benar. Jadi pengguna manusia tetap berada di puncak rantai informasi.

Dalam 2 kasus pertama, Anda memiliki kasus untuk interaksi manusia-ke-mesin, informasi yang sebenarnya dikonsumsi oleh pengguna manusia. Dalam kasus terakhir, Anda memiliki program mesin yang mengonsumsi API REST.

Konsep otentikasi berlaku secara menyeluruh. Bagaimana Anda mendesain ini sehingga REST API Anda diakses dengan cara yang seragam dan aman? Cara saya melihat ini, ada 2 cara:

Cara-1:

  1. Tidak ada login, untuk memulai. Setiap permintaan melakukan login
  2. Klien mengirimkan parameter pengenalnya + parameter permintaan khusus dengan setiap permintaan
  3. API REST membawa mereka, berbalik, mem-ping pengguna yang menyimpan (apa pun itu) dan mengonfirmasi auth
  4. Jika auth didirikan, layanan permintaan; jika tidak, tolak dengan kode status HTTP yang sesuai
  5. Ulangi hal di atas untuk setiap permintaan di semua API REST di katalog Anda

Cara-2:

  1. Klien mulai dengan permintaan auth
  2. API REST login akan menangani semua permintaan tersebut
  3. Dibutuhkan dalam parameter auth (kunci API, uid / pwd atau apa pun yang Anda pilih) dan memverifikasi auth terhadap penyimpanan pengguna (LDAP, AD, atau MySQL DB dll.)
  4. Jika diverifikasi, buat token autentikasi dan serahkan kembali ke klien / pemanggil
  5. Penelepon kemudian mengirimkan token autentikasi + permintaan khusus ini dengan setiap permintaan berikutnya ke REST API bisnis lainnya, sampai keluar atau sampai masa sewa berakhir

Jelas, dalam Cara-2, API REST akan membutuhkan cara untuk mengenali dan mempercayai token sebagai valid. Login API melakukan verifikasi auth, dan oleh karena itu "kunci pelayan" perlu dipercaya oleh API REST lain dalam katalog Anda.

Ini, tentu saja, berarti bahwa kunci / token kunci perlu disimpan dan dibagikan di antara API REST. Repositori token yang dipercaya dan dibagikan ini dapat bersifat lokal / gabungan apa pun, yang memungkinkan REST API dari organisasi lain saling percaya.

Tapi saya ngelantur.

Intinya adalah, "keadaan" (tentang status terotentikasi klien) perlu dipertahankan dan dibagikan sehingga semua REST API dapat membuat lingkaran kepercayaan. Jika kita tidak melakukan ini, yang merupakan Cara-1, kita harus menerima bahwa tindakan otentikasi harus dilakukan untuk setiap / semua permintaan yang masuk.

Melakukan otentikasi adalah proses sumber daya intensif. Bayangkan mengeksekusi query SQL, untuk setiap permintaan yang masuk, terhadap toko pengguna Anda untuk memeriksa kecocokan uid / pwd. Atau, untuk mengenkripsi dan melakukan hash cocok (gaya AWS). Dan secara arsitektur, setiap API REST perlu melakukan ini, saya kira, menggunakan layanan login back-end yang umum. Karena, jika tidak, maka Anda membuang kode auth di mana-mana. Kekacauan besar.

Jadi lebih banyak lapisan, lebih banyak latensi.

Sekarang, ambil Way-1 dan terapkan ke HTM. Apakah pengguna (manusia) Anda benar-benar peduli jika Anda harus mengirim uid / pwd / hash atau apa pun dengan setiap permintaan? Tidak, selama Anda tidak mengganggunya dengan melemparkan halaman auth / login setiap detik. Semoga beruntung memiliki pelanggan jika Anda melakukannya. Jadi, yang akan Anda lakukan adalah menyimpan informasi login di suatu tempat di sisi klien, di browser, tepat di awal, dan mengirimkannya dengan setiap permintaan dibuat. Untuk pengguna (manusia), ia sudah masuk, dan "sesi" tersedia. Namun dalam kenyataannya, dia diautentikasi pada setiap permintaan.

Sama dengan Way-2. Pengguna (manusia) Anda tidak akan pernah melihat. Jadi tidak ada salahnya dilakukan.

Bagaimana jika kita menerapkan Way-1 ke MTM? Dalam hal ini, karena ini adalah mesin, kita dapat membuat orang ini bosan dengan memintanya mengirimkan informasi otentikasi dengan setiap permintaan. Tidak ada yang peduli! Performing Way-2 pada MTM tidak akan menimbulkan reaksi khusus; itu mesin sialan. Itu tidak peduli!

Jadi sungguh, pertanyaannya adalah apa yang sesuai dengan kebutuhan Anda. Kewarganegaraan memiliki harga yang harus dibayar. Bayar harganya dan lanjutkan. Jika Anda ingin menjadi seorang purist, maka bayar harganya juga, dan lanjutkan.

Pada akhirnya, filosofi tidak penting. Yang benar-benar penting adalah penemuan informasi, presentasi, dan pengalaman konsumsi. Jika orang menyukai API Anda, Anda melakukan pekerjaan Anda.


3
Pak, Anda telah menjelaskan ini dengan sangat indah sehingga saya memiliki gagasan yang jelas tentang masalah / pertanyaan mendasar yang ada. Anda seperti Buddha! Mungkin saya menambahkan bahwa dengan menggunakan HTTPS pada layer transport, kita bahkan dapat mencegah serangan Man In the Middle, sehingga tidak ada yang membajak kunci pengidentifikasi saya (jika Cara-1 dipilih)
Vishnoo Rath

Bukankah itu selalu mesin melakukan otentikasi? Manusia tidak memberikan omong kosong tentang kata sandi, itu adalah gangguan yang disayangkan bagi pengguna yang merasionalisasi keamanan dengan benar. Bagi saya itu adalah masalah pengembang bagaimana mereka ingin mesin melakukan tugasnya.
Todd Baur

9
Saya membaca jawaban Anda; dalam solusi Anda, untuk setiap permintaan web tunggal yang berasal dari browser dengan klik pengguna perlu mengirimkan "token auth" kembali ke API apa pun yang diklik oleh pengguna. Lalu bagaimana? API melakukan pemeriksaan pada token. Melawan apa? Terhadap semacam "token store" yang mempertahankan apakah token itu valid atau tidak. Apakah Anda tidak setuju bahwa "token store" itu kemudian menjadi penjaga "negara"? Sungguh, bagaimana pun Anda melihatnya, seseorang di suatu tempat harus mengetahui sesuatu tentang "token" yang dibagikan pada aktivitas pengguna. Itulah tempat tinggal informasi negara.
Kingz

5
Dan dengan layanan "stateless", yang sebenarnya dimaksud adalah komponen server tertentu (API CRUD) tidak membawa status apa pun. Mereka tidak mengenali satu pengguna dari yang lain dan menyelesaikan permintaan pengguna secara keseluruhan dalam satu transaksi. Itu adalah kewarganegaraan. Tetapi seseorang di suatu tempat harus duduk dan memberikan penilaian apakah pengguna ini valid atau tidak. Tidak ada cara lain untuk melakukan ini; kunci atau kata sandi atau apa pun. Apa pun yang diedarkan dari sisi pengguna harus disahkan dan disahkan.
Kingz

1
Anda hilang Way-3, pendekatan hibrida. Klien masuk seperti pada Way-2tetapi, seperti pada Way-1, kredensial tidak diperiksa terhadap keadaan sisi server. Apapun, token autentik dibuat dan dikirim kembali ke klien seperti pada Way-2. Token ini kemudian diperiksa keasliannya menggunakan kripto asimetris tanpa melihat status spesifik klien.
jcoffland

50

Berikut ini adalah solusi otentikasi yang benar-benar dan sepenuhnya TENANG:

  1. Buat pasangan kunci publik / pribadi di server otentikasi.
  2. Bagikan kunci publik ke semua server.
  3. Ketika klien mengautentikasi:

    3.1. mengeluarkan token yang berisi yang berikut ini:

    • Waktu kedaluwarsa
    • nama pengguna (opsional)
    • pengguna IP (opsional)
    • kata sandi (opsional)

    3.2. Enkripsi token dengan kunci pribadi.

    3.3. Kirim token terenkripsi kembali ke pengguna.

  4. Ketika pengguna mengakses API apa pun, mereka juga harus memberikan token autentikasi.

  5. Server dapat memverifikasi bahwa token itu valid dengan mendekripsi menggunakan kunci publik server auth.

Ini adalah stateless / RESTful authentication.

Perhatikan, bahwa jika hash kata sandi dimasukkan, pengguna juga akan mengirim kata sandi yang tidak dienkripsi bersama dengan token otentikasi. Server dapat memverifikasi bahwa kata sandi cocok dengan kata sandi yang digunakan untuk membuat token otentikasi dengan membandingkan hash. Koneksi aman menggunakan sesuatu seperti HTTPS akan diperlukan. Javascript di sisi klien dapat menangani mendapatkan kata sandi pengguna dan menyimpannya di sisi klien, baik dalam memori atau cookie, mungkin dienkripsi dengan kunci publik server .


5
Bagaimana jika seseorang memegang token autentikasi itu dan memohon API dengan itu berpura-pura menjadi klien?
Abidi

2
@Idiidi, ya itu masalah. Anda dapat meminta kata sandi. Hash kata sandi dapat dimasukkan dalam token otentikasi. Jika seseorang bisa mencuri token itu akan rentan terhadap serangan brute force offline. Jika frasa sandi yang kuat dipilih, itu tidak akan menjadi masalah. Perhatikan, bahwa jika Anda menggunakan https, pencurian token membutuhkan penyerang untuk mendapatkan akses ke mesin klien terlebih dahulu.
jcoffland

1
Karena hanya server otentikasi yang mengetahui kunci privat. Server lain dapat mengautentikasi pengguna dengan hanya mengetahui kunci publik dan token pengguna.
jcoffland

1
Enkripsi dan dekripsi asimetris adalah urutan besarnya lebih lambat (lebih intensif komputasi) daripada enkripsi simetris. Memiliki server menggunakan kunci publik untuk mendekripsi token pada setiap panggilan akan menjadi hambatan kinerja yang sangat besar .
Craig

3
@ jcoffland Anda benar-benar mempromosikan jawaban Anda di sini (berulang kali :-) Tapi saya tidak bisa berhenti berkomentar tentang masalah kinerja (intensitas komputasi) menggunakan enkripsi asimetris pada setiap panggilan. Saya tidak bisa melihat solusi yang memiliki kemampuan untuk mengukur. Cari HTTPS dan protokol SPDY. Berlanjut untuk menjaga koneksi tetap terbuka (HTTP keep-alives, yang merupakan state), dan melayani banyak sumber daya dalam batch melalui koneksi yang sama (lebih banyak state), dan tentu saja SSL sendiri hanya menggunakan enkripsi asimetris untuk bertukar kunci cipher simetris ( juga nyatakan).
Craig

37

Jujur dengan Anda, saya telah melihat jawaban yang bagus di sini, tetapi sesuatu yang sedikit mengganggu saya adalah ketika seseorang akan mengambil seluruh konsep Stateless ke ekstrem di mana itu menjadi dogmatis. Ini mengingatkan saya pada penggemar Smalltalk lama yang hanya ingin merangkul OO murni dan jika ada sesuatu yang bukan objek, maka Anda salah melakukannya. Beri aku istirahat.

Pendekatan RESTful seharusnya membuat hidup Anda lebih mudah dan mengurangi biaya overhead dan sesi, cobalah untuk mengikutinya karena itu adalah hal yang bijak untuk dilakukan, tetapi begitu Anda mengikuti disiplin (disiplin / pedoman apa pun) hingga ke titik ekstrim di mana ia tidak lagi memberikan manfaat yang dimaksudkan, maka Anda salah melakukannya. Beberapa bahasa terbaik saat ini memiliki keduanya, pemrograman fungsional dan orientasi objek.

Jika cara termudah bagi Anda untuk menyelesaikan masalah Anda adalah dengan menyimpan kunci otentikasi dalam cookie dan mengirimkannya ke header HTTP, maka lakukan, jangan menyalahgunakannya. Ingat bahwa sesi itu buruk ketika menjadi berat dan besar, jika semua sesi Anda terdiri dari string pendek yang berisi kunci, lalu apa masalahnya?

Saya terbuka untuk menerima koreksi dalam komentar, tetapi saya hanya tidak melihat titik (sejauh ini) dalam membuat hidup kita sengsara untuk menghindari menyimpan kamus besar hash di server kami.


2
Orang tidak berusaha melarang Anda menggunakan sesi. Anda bebas melakukannya. Tetapi jika Anda melakukannya, itu bukan ISTIRAHAT.
André Caldas

6
@ AndréCaldas bukan ISTIRAHAT dengan cara yang sama yang memiliki fungsi atau tipe primitif dalam bahasa bukan oop. Saya tidak mengatakan memiliki sesi disarankan. Saya hanya memberikan pendapat saya tentang mengikuti serangkaian praktik sampai taraf mereka tidak lagi memberikan manfaat kepada seseorang. (Btw, perhatikan saya tidak menentang pernyataan Anda, namun, saya tidak akan mengatakan itu bukan REST, saya akan mengatakan itu bukan REST murni ).
arg20

Jadi apa yang kita sebut jika tidak TENANG? Dan tentu saja jika permintaan menyertakan ID sesi, maka apakah itu kewarganegaraan seperti permintaan termasuk ID pengguna? Mengapa ID pengguna dan negara tidak memiliki status sesi?
mfhholmes

1
Cookie rentan terhadap pemalsuan permintaan lintas situs, sehingga membuatnya lebih mudah untuk mengalami pelanggaran keamanan. Lebih baik menggunakan sesuatu yang tidak secara otomatis dikirim oleh browser seperti header khusus atau skema Otorisasi kustom.
Dobes Vandermeer

1
Sebenarnya, berusaha menjadi tanpa kewarganegaraan bukan tentang dogmatisme, tetapi tentang satu konsepsi umum SOA itu sendiri. Layanan harus selalu mendapat manfaat dari tidak terpisahkan, dan tidak memiliki kewarganegaraan: dalam praktiknya, ini memudahkan penskalaan, ketersediaan, dan pemeliharaan. Tentu saja, itu harus sebanyak mungkin, dan pada akhirnya Anda akan memerlukan beberapa "layanan orkestra" untuk mengelola layanan stateless ke dalam pendekatan pragmatis stateful.
Arnaud Bouchez

32

Pertama dan yang terpenting, layanan web yang tenang adalah NEGARA (atau dengan kata lain, SESSIONLESS). Oleh karena itu, layanan RESTful tidak memiliki dan tidak boleh memiliki konsep sesi atau cookie yang terlibat. Cara untuk melakukan otentikasi atau otorisasi dalam layanan RESTful adalah dengan menggunakan header HTTP Authorization seperti yang didefinisikan dalam spesifikasi HTTP RFC 2616. Setiap permintaan tunggal harus berisi tajuk Otorisasi HTTP, dan permintaan tersebut harus dikirim melalui koneksi HTTP (SSL). Ini adalah cara yang benar untuk melakukan otentikasi dan untuk memverifikasi otorisasi permintaan dalam layanan web HTTP RESTful. Saya telah mengimplementasikan layanan web RESTful untuk aplikasi Cisco PRIME Performance Manager di Cisco Systems. Dan sebagai bagian dari layanan web itu, saya telah menerapkan otentikasi / otorisasi juga.


5
Otentikasi HTTP masih mengharuskan server untuk melacak id dan kata sandi pengguna. Ini bukan sepenuhnya tanpa kewarganegaraan.
jcoffland

21
Ini adalah kewarganegaraan dalam arti bahwa setiap permintaan valid sendiri tanpa persyaratan dari permintaan sebelumnya. Bagaimana ini diterapkan pada server adalah masalah lain, jika otentikasi mahal Anda bisa melakukan beberapa caching dan otentikasi ulang pada cache miss. Sangat sedikit server yang benar-benar tanpa kewarganegaraan di mana outputnya murni fungsi dari input. Ini biasanya permintaan atau pembaruan untuk beberapa negara.
Erik Martino

3
Tidak benar. Dalam hal ini semua permintaan Anda memerlukan status dari transaksi sebelumnya, yaitu pendaftaran pengguna. Saya tidak mengerti mengapa orang terus berusaha mengatakan bahwa nama pengguna dan kata sandi yang disimpan di server bukan keadaan sisi server. Lihat jawaban saya.
jcoffland

1
@ jcoffland Juga, solusi Anda sangat bergantung pada kemampuan server API untuk mendekripsi token yang ditandatangani. Saya pikir pendekatan ini tidak hanya terlalu spesifik, tetapi juga agak terlalu canggih untuk dianggap sebagai THE approah R. Fielding ada dalam pikiran untuk mengatasi masalah otentikasi TENANG.
Michael Ekoka

2
@ jcoffland, apakah Anda mengerti betapa asimetris enkripsi asimetris yang jauh lebih komputif (dan karenanya intensif sumber daya)? Anda sedang berbicara tentang skema yang akan menggunakan enkripsi asimetris pada setiap permintaan tunggal. Aspek paling lambat dari HTTPS, tidak ada, adalah jabat tangan awal yang melibatkan pembuatan kunci publik / pribadi untuk mengenkripsi rahasia bersama secara asimetris yang kemudian digunakan untuk mengenkripsi secara simetris semua komunikasi yang terjadi kemudian.
Craig

22

Ini tentu saja bukan tentang "kunci sesi" karena umumnya digunakan untuk merujuk ke otentikasi tanpa sesi yang dilakukan dalam semua kendala REST. Setiap permintaan menggambarkan sendiri, membawa informasi yang cukup untuk mengotorisasi permintaan sendiri tanpa keadaan aplikasi sisi server.

Cara termudah untuk mendekati ini adalah dengan memulai dengan mekanisme otentikasi bawaan HTTP di RFC 2617 .


Otentikasi HTTP mengharuskan server untuk menyimpan nama pengguna dan kata sandi. Ini adalah keadaan sisi server dan karenanya tidak sepenuhnya REST. Lihat jawaban saya.
jcoffland

3
@ jcoffland: Itu tidak benar, di kedua akun. HTTP Auth pertama tidak memerlukan server untuk menyimpan kata sandi. Sebagai gantinya, kata sandi hash disimpan (bcrypt dengan 8+ putaran disarankan). Kedua, server tidak memiliki status apa-apa sejak header otorisasi dikirim dengan setiap permintaan. Dan jika Anda menganggap hash kata sandi yang disimpan sebagai status , mereka tidak lebih dari kunci publik tersimpan.
Boris B.

1
@ Boris B., ya saya mengerti bahwa kata sandi disimpan sebagai hash. Kata sandi hash masih merupakan kondisi khusus klien. Perbedaannya dengan menyimpan kunci publik, seperti yang dijelaskan dalam solusi saya, adalah bahwa hanya ada satu kunci publik, kunci publik dari server otentikasi. Ini sangat berbeda dari menyimpan hash kata sandi per pengguna. Tidak peduli bagaimana Anda mendandani jika server menyimpan kata sandi untuk setiap pengguna maka ia menyimpan per negara pengguna dan bukan 100% REST.
jcoffland

7
Saya tidak berpikir menyimpan kata sandi pengguna di server harus dianggap sebagai sisi server. Pengguna adalah sumber daya, yang mengandung informasi seperti nama, alamat, atau kata sandi hash.
Codepunkt

15

Artikel 'sangat berwawasan' yang disebutkan oleh @skrebel ( http://www.berenddeboer.net/rest/authentication.html ) membahas metode otentikasi yang berbelit-belit tetapi benar-benar rusak.

Anda dapat mencoba mengunjungi halaman (yang seharusnya hanya dapat dilihat oleh pengguna yang diautentikasi) http://www.berenddeboer.net/rest/site/authenticated.html tanpa kredensial login.

(Maaf saya tidak bisa mengomentari jawabannya.)

Saya akan mengatakan REST dan otentikasi hanya tidak tercampur. REST berarti tanpa kewarganegaraan tetapi 'disahkan' adalah suatu keadaan. Anda tidak dapat memiliki keduanya di lapisan yang sama. Jika Anda seorang advokat yang tenang dan tidak menyukai keadaan, maka Anda harus menggunakan HTTPS (yaitu meninggalkan masalah keamanan ke lapisan lain).


Stripe.com akan mengatakan sebaliknya pada komentar Anda tentang REST dan Otentikasi tidak bercampur ..
Erik

Stateless hanya merujuk ke server, bukan klien. Klien dapat mengingat semua keadaan sesi dan mengirim apa yang relevan dengan setiap permintaan.
Dobes Vandermeer

Akhirnya seseorang berbicara dengan akal sehat, tetapi otentikasi stateless dimungkinkan menggunakan kunci publik kripto. Lihat jawaban saya.
jcoffland

1
Server tidak memiliki status "terotentikasi". Ia menerima informasi melalui hypermedia dan harus bekerja dengannya untuk mengembalikan apa yang diminta. Tidak kurang, tidak lebih. Jika sumber daya dilindungi dan memerlukan otentikasi dan otorisasi, hypermedia yang disediakan harus menyertakan informasi itu. Saya tidak tahu dari mana gagasan bahwa mengautentikasi pengguna sebelum mengembalikan sumber daya berarti bahwa server melacak keadaan berasal. Memberikan nama pengguna dan kata sandi dapat dianggap sebagai sekadar memberikan lebih banyak parameter pemfilteran.
Michael Ekoka

"Saya akan mengatakan REST dan otentikasi tidak tercampur." Kedengarannya seperti akal sehat. Kecuali bahwa sistem yang tidak kompatibel dengan otentikasi ("diotentikasi" itu sendiri, tentu saja, keadaan) memiliki kegunaan terbatas. Saya merasa seperti kita semua berdebat di persimpangan kepraktisan dan dogmatisme murni, dan sejujurnya kepraktisan harus menang. Ada banyak aspek REST yang sangat bermanfaat tanpa masuk ke dalam contortions mencoba menghindari keadaan sehubungan dengan otentikasi, bukan?
Craig

12

Saya pikir otentikasi tenang melibatkan pengalihan token otentikasi sebagai parameter dalam permintaan. Contohnya adalah penggunaan apikeys oleh api. Saya tidak percaya penggunaan cookie atau http auth memenuhi syarat.


Cookies dan HTTP Auth harus dihindari karena kerentanan CSRF.
Dobes Vandermeer

@DobesVandermeer Bisakah Anda melihat pertanyaan saya jika Anda dapat membantu? stackoverflow.com/questions/60111743/…
Hemant Metalia

12

Pembaruan pada 16-Feb-2019

Pendekatan yang disebutkan sebelumnya di bawah ini pada dasarnya adalah jenis hibah "Resource Owner Password Credential" dari OAuth2.0 . Ini adalah cara mudah untuk bangkit dan berlari. Namun, dengan pendekatan ini setiap aplikasi dalam organisasi akan berakhir dengan autentikasi dan mekanisme otorisasi sendiri. Pendekatan yang disarankan adalah jenis hibah "Kode Otorisasi". Selain itu, dalam jawaban saya sebelumnya di bawah ini saya merekomendasikan browser localStorage untuk menyimpan token auth. Namun, saya mulai percaya bahwa cookie adalah opsi yang tepat untuk tujuan ini. Saya telah merinci alasan saya, pendekatan implementasi jenis hibah kode otorisasi, pertimbangan keamanan dll. Dalam jawaban StackOverflow ini .


Saya pikir pendekatan berikut dapat digunakan untuk otentikasi layanan REST:

  1. Buat API ISTIMEWA untuk menerima nama pengguna dan kata sandi untuk otentikasi. Gunakan metode HTTP POST untuk mencegah caching dan SSL untuk keamanan selama transit Pada otentikasi yang berhasil, API mengembalikan dua JWT - satu token akses (validitas lebih pendek, katakan 30 menit) dan satu token refresh (validitas lebih lama, katakan 24 jam)
  2. Klien (UI berbasis web) menyimpan JWT di penyimpanan lokal dan di setiap panggilan API berikutnya melewati token akses di header "Otorisasi: Bearer #access token"
  3. API memeriksa validitas token dengan memverifikasi tanda tangan dan tanggal kedaluwarsa. Jika token itu valid, periksa apakah pengguna (Ini mengartikan klaim "sub" di JWT sebagai nama pengguna) memiliki akses ke API dengan pencarian cache. Jika pengguna berwenang untuk mengakses API, jalankan logika bisnis
  4. Jika token telah kedaluwarsa, API mengembalikan kode respons HTTP 400
  5. Klien, saat menerima 400/401, memanggil API REST lain dengan token penyegaran di header "Otorisasi: Bearer #refresh token" untuk mendapatkan token akses baru.
  6. Saat menerima panggilan dengan token refresh, periksa apakah token refresh valid dengan memeriksa tanda tangan dan tanggal kedaluwarsa. Jika token refresh valid, segarkan cache hak akses pengguna dari DB dan kembalikan token akses baru dan segarkan token. Jika token penyegaran tidak valid, kembalikan kode respons HTTP 400
  7. Jika token akses baru dan token refresh dikembalikan, lanjutkan ke langkah 2. Jika kode respons HTTP 400 dikembalikan, klien menganggap bahwa token refresh telah kedaluwarsa dan meminta nama pengguna dan kata sandi dari pengguna.
  8. Untuk keluar, bersihkan penyimpanan lokal

Dengan pendekatan ini, kami melakukan operasi pemuatan cache yang mahal dengan rincian hak akses khusus pengguna setiap 30 menit. Jadi jika akses dicabut atau akses baru diberikan, dibutuhkan 30 menit untuk mencerminkan atau logout diikuti oleh login.


jadi apakah Anda akan menggunakan ini untuk api dengan situs web statis yang dibuat dengan sudut misalnya? dan bagaimana dengan aplikasi seluler?
Yazan Rawashdeh

8

Itulah cara melakukannya: Menggunakan OAuth 2.0 untuk Login .

Anda dapat menggunakan metode otentikasi lain selain Google selama mendukung OAuth.


1
OAuth2 tidak aman tanpa HTTPS, atau stateless.
Arnaud Bouchez

4
Tidak ada yang aman tanpa HTTPS.
Craig

1
@Craig Dan HTTPS juga mungkin tidak aman, jika rantai sertifikat rusak, yang mungkin untuk kebaikan yang lebih besar - en.wikipedia.org/wiki/Bullrun_(decryption_program) ;)
Arnaud Bouchez

1
@ArnaudBouchez Tolong jelaskan bagaimana memiliki rantai sertifikat yang rusak adalah untuk kebaikan yang lebih besar? Saya tidak mengerti ke mana Anda akan pergi dengan itu. ;)
Craig

@Craig Silakan ikuti tautannya, dan selamat menikmati! Pendekatan "kebaikan yang lebih besar" ini jelas sinis dalam komentar saya: Sistem seperti bullrun dimaksudkan untuk "kebaikan kita sendiri" oleh pemerintah kita yang tercinta dan dapat dipercaya.
Arnaud Bouchez

3

Menggunakan infrastruktur kunci Publik di mana pendaftaran kunci melibatkan pengikatan yang tepat memastikan bahwa kunci publik terikat dengan individu yang ditugaskan dengan cara yang memastikan non-repudiation

Lihat http://en.wikipedia.org/wiki/Public_key_infrastructure . Jika Anda mengikuti standar PKI yang tepat, orang atau agen yang menggunakan kunci curian secara tidak tepat dapat diidentifikasi dan dikunci. Jika agen diminta untuk menggunakan sertifikat, ikatan menjadi sangat ketat. Seorang pencuri yang pintar dan bergerak cepat dapat melarikan diri, tetapi mereka meninggalkan lebih banyak remah.


2

Untuk menjawab pertanyaan ini dari pemahaman saya ...

Sistem otentikasi yang menggunakan REST sehingga Anda tidak perlu melacak atau mengelola pengguna di sistem Anda. Ini dilakukan dengan menggunakan metode HTTP POST, GET, PUT, DELETE. Kami menggunakan 4 metode ini dan menganggapnya dalam hal interaksi basis data sebagai CREATE, READ, UPDATE, DELETE (tetapi di web kami menggunakan POST dan GET karena itulah yang didukung tag anchor tag saat ini). Jadi memperlakukan POST dan GET sebagai CREATE / READ / UPDATE / DELETE (CRUD) kami maka kami dapat merancang rute dalam aplikasi web kami yang akan dapat menyimpulkan tindakan CRUD apa yang kami capai.

Misalnya, dalam aplikasi Ruby on Rails kita dapat membangun aplikasi web kita sehingga jika pengguna yang masuk mengunjungi http://store.com/account/logout maka GET dari halaman tersebut dapat dilihat sebagai pengguna yang mencoba untuk keluar. . Di pengontrol rel kami, kami akan membuat aksi dalam log pengguna keluar dan mengirimkannya kembali ke halaman rumah.

GET pada halaman login akan menghasilkan formulir. POST pada halaman login akan dilihat sebagai upaya login dan mengambil data POST dan menggunakannya untuk login.

Bagi saya, ini adalah praktik menggunakan metode HTTP yang dipetakan ke makna basis datanya dan kemudian membangun sistem otentikasi dengan itu dalam pikiran Anda tidak perlu melewati id sesi atau sesi trek apa pun.

Saya masih belajar - jika Anda menemukan sesuatu yang saya katakan salah, tolong perbaiki saya, dan jika Anda mempelajari lebih lanjut, kembalikan di sini. Terima kasih.


2

Kiat yang valid untuk mengamankan aplikasi web apa pun

Jika Anda ingin mengamankan aplikasi Anda, maka Anda harus memulai dengan menggunakan HTTPS alih-alih HTTP , ini memastikan terciptanya saluran aman antara Anda & pengguna yang akan mencegah mengendusnya data yang dikirim kembali & keluar kepada pengguna & akan membantu menjaga data ditukar rahasia.

Anda dapat menggunakan JWT (JSON Web Tokens) untuk mengamankan API RESTful , ini memiliki banyak manfaat jika dibandingkan dengan sesi sisi server, manfaatnya terutama:

1- Lebih scalable, karena server API Anda tidak harus mengelola sesi untuk setiap pengguna (yang bisa menjadi beban besar ketika Anda memiliki banyak sesi)

2 - JWT mandiri & memiliki klaim yang menentukan peran pengguna misalnya & apa yang dapat dia akses & dikeluarkan pada tanggal & tanggal kedaluwarsa (setelah itu JWT tidak akan valid)

3 - Lebih mudah untuk menangani lintas-penyeimbang & jika Anda memiliki beberapa server API karena Anda tidak perlu berbagi data sesi atau mengkonfigurasi server untuk merutekan sesi ke server yang sama, setiap kali permintaan dengan JWT mengenai server mana pun, itu dapat diautentikasi & resmi

4- Lebih sedikit tekanan pada DB Anda dan Anda tidak perlu terus-menerus menyimpan & mengambil id sesi & data untuk setiap permintaan

5- JWT tidak dapat dirusak jika Anda menggunakan kunci yang kuat untuk menandatangani JWT, sehingga Anda dapat mempercayai klaim dalam JWT yang dikirim dengan permintaan tanpa harus memeriksa sesi pengguna & apakah dia berwenang atau tidak , Anda cukup memeriksa JWT & kemudian Anda siap untuk mengetahui siapa & apa yang dapat dilakukan pengguna ini.

Banyak perpustakaan menyediakan cara mudah untuk membuat & memvalidasi JWT di sebagian besar bahasa pemrograman, misalnya: di node.js salah satu yang paling populer adalah jsonwebtoken

Karena REST API umumnya bertujuan untuk menjaga agar server tidak memiliki kewarganegaraan, maka JWT lebih kompatibel dengan konsep itu karena setiap permintaan dikirim dengan token Otorisasi yang mandiri (JWT) tanpa server harus melacak sesi pengguna dibandingkan dengan sesi yang membuat server stateful sehingga ia mengingat pengguna & perannya, namun, sesi juga banyak digunakan & memiliki pro mereka, yang dapat Anda cari jika Anda mau.

Satu hal penting yang perlu diperhatikan adalah Anda harus mengirimkan JWT dengan aman ke klien menggunakan HTTPS & menyimpannya di tempat yang aman (misalnya di penyimpanan lokal).

Anda dapat mempelajari lebih lanjut tentang JWT dari tautan ini

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.