Panduan Pemula untuk JWT di Java

Baru mengenal otentikasi token, OAuth, atau Token Web JSON? Ini adalah tempat yang bagus untuk memulai!

Pertama, apa itu Token Web JSON, atau JWT (diucapkan “jot”)? Singkatnya, JWT adalah standar yang aman dan dapat dipercaya untuk otentikasi token. JWT memungkinkan Anda untuk menandatangani informasi secara digital (disebut sebagai klaim) dengan tanda tangan dan dapat diverifikasi di lain waktu dengan kunci penandatanganan rahasia.

Apa itu Otentikasi Token?

Proses dimana aplikasi mengkonfirmasi identitas pengguna disebut otentikasi . Secara tradisional, aplikasi memiliki identitas yang bertahan melalui cookie sesi yang mengandalkan ID sesi yang disimpan di sisi server. Dalam struktur ini, pengembang dipaksa untuk membuat penyimpanan sesi yang unik dan khusus untuk server, atau diimplementasikan sebagai lapisan penyimpanan sesi yang benar-benar terpisah.

Otentikasi token adalah pendekatan yang lebih modern, yang dirancang untuk memecahkan masalah yang tidak dapat dilakukan oleh ID sesi sisi server. Menggunakan token sebagai pengganti ID sesi dapat menurunkan beban server Anda, menyederhanakan manajemen izin, dan menyediakan alat yang lebih baik untuk mendukung infrastruktur terdistribusi atau berbasis cloud. Dalam metode ini, token dibuat untuk pengguna Anda setelah mereka menunjukkan kredensial yang dapat diverifikasi. Otentikasi awal bisa dengan kredensial nama pengguna/kata sandi, kunci API atau bahkan token dari layanan lain.

Anatomi JWT

Jika Anda menemukan JWT di alam liar, Anda akan melihat bahwa itu dipisahkan menjadi tiga bagian, header, payload, dan tanda tangan. Berikut ini contoh JWT tipikal:

<code>

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9eyJzdWIiOiJ1c2Vycy9Uek1Vb2NNRjRwIiwibmFtZSI6IlJvYmVydCBUb2tlbiBNYW4iLCJzY29wZSI6InNlbGYgZ3JvdXBzL2FkbWlucyIsImV4cCI6IjEzMDA4MTkzODAifQ1pVOLQduFWW3muii1LExVBt2TK1-MdRI4QjhKryaDwc

</code>

Dalam contoh ini, Bagian 1 adalah header yang menjelaskan token. Bagian 2 adalah muatan, yang berisi klaim JWT, dan Bagian 3 adalah hash tanda tangan yang dapat digunakan untuk memverifikasi integritas token (jika Anda memiliki kunci rahasia yang digunakan untuk menandatanganinya).

Saat kami mendekode payload, kami mendapatkan objek JSON yang bagus dan rapi ini yang berisi klaim JWS:

<code>

{

  "sub": "users/TzMUocMF4p",

  "name": "Robert Token Man",

  "scope": "self groups/admins",

  "exp": "1300819380"

}

</code>

Klaim memberi tahu Anda, setidaknya:

• Siapa orang ini dan URI ke sumber daya penggunanya (subklaim)
• Apa yang dapat diakses orang ini dengan token ini (klaim cakupan)
• Ketika token kedaluwarsa. API Anda harus menggunakan ini saat memverifikasi token.

Karena token ditandatangani dengan kunci rahasia, Anda dapat memverifikasi tanda tangannya dan secara implisit mempercayai apa yang diklaim.

JWE, JWS, dan JWT

Per Spesifikasi JWT , "JWT mewakili serangkaian klaim sebagai objek JSON yang dikodekan dalam struktur JWS dan/atau JWE." Istilah "JWT" ​​secara teknis hanya menggambarkan token yang tidak ditandatangani; apa yang kita sebut sebagai JWT paling sering adalah JWS atau JWS + JWE.

JWS — Tanda Tangan Web JSON

Dalam skema JWS , server menandatangani JWT dan mengirimkannya ke klien dengan tanda tangan. Tanda tangan tersebut memberikan jaminan bahwa klaim JWT tidak dipalsukan atau dirusak. Namun, JWT tidak dienkripsi (isinya pada dasarnya adalah teks biasa).

JWE — Enkripsi Web JSON

The JWE skema, di sisi lain, mengenkripsi isi tanpa menandatanganinya. Ini membawa kerahasiaan ke JWT Anda, tetapi bukan keamanan menandatangani dan melampirkan JWE di dalam JWS.

Apa sih OAuth itu?

OAuth 2.0 adalah kerangka kerja untuk interaksi dengan layanan yang dapat mendelegasikan otentikasi atau memberikan otorisasi. Ini diadopsi secara luas di banyak aplikasi seluler dan web. OAuth 2.0 tidak menentukan format token, tetapi JWT dengan cepat menjadi standar de facto di industri.

Dalam paradigma OAuth, ada dua jenis token: Token Akses dan Segarkan. Saat Anda pertama kali mengautentikasi, aplikasi Anda (dan juga pengguna Anda), biasanya diberikan kedua token, tetapi Token Akses diatur kedaluwarsa setelah beberapa saat (durasi ini dapat dikonfigurasi dalam aplikasi). Setelah Token Akses awal telah kedaluwarsa, Token Penyegaran akan memungkinkan aplikasi Anda untuk mendapatkan Token Akses baru. Token Refresh memiliki masa berlaku yang ditetapkan, memungkinkan penggunaan tanpa batas hingga titik kedaluwarsa tercapai. Baik Access dan Refresh Token memiliki keamanan bawaan (saat ditandatangani) untuk mencegah gangguan dan hanya berlaku untuk durasi tertentu.

Stormpath menggunakan OAuth karena merupakan standar industri yang dapat dimanfaatkan oleh perpustakaan yang sesuai. Stormpath saat ini mendukung tiga jenis hibah OAuth:

• Jenis Pemberian Kata Sandi: Memberikan kemampuan untuk mendapatkan Token Akses berdasarkan nama pengguna dan kata sandi
• Jenis Hibah Penyegaran: Memberikan kemampuan untuk menghasilkan Token Akses lain berdasarkan Token Penyegaran khusus
• Jenis Hibah Kredensial Klien: Menyediakan kemampuan untuk menukar Pasangan Kunci API dengan Token Akses. Ini didukung melalui fitur Manajemen Kunci API

Apakah Token Aman?

Pertanyaan sebenarnya di sini adalah, apakah Anda menggunakannya dengan aman? Di Stormpath, kami mengikuti praktik terbaik ini, dan mendorong klien kami untuk melakukan hal yang sama:

• Simpan JWT Anda di cookie HttpOnly yang aman . Ini mencegah serangan Cross-Site Scripting (XSS) .
• Jika Anda menggunakan cookie untuk mengirimkan JWT Anda, perlindungan CSRF sangat penting! Cookie Anda dapat digunakan secara jahat oleh domain lain yang membuat permintaan ke situs web Anda tanpa persetujuan pengguna Anda. Jika server Anda secara membabi buta mengotentikasi pengguna, hanya karena mereka memiliki cookie, maka Anda memiliki lebih banyak masalah daripada ukuran hard drive Anda. Anda juga mengizinkan serangan CSRF, di mana situs web lain memicu tindakan perubahan status di server Anda tanpa persetujuan pengguna Anda. Ini dimungkinkan karena browser akan selalu mengirim cookie pengguna secara otomatis, terlepas dari bagaimana permintaan dipicu. Gunakan salah satu dari banyak tindakan Pencegahan CSRF untuk mengurangi risiko ini.
• Tanda tangani token Anda dengan kunci kuat yang HANYA tersedia untuk layanan otentikasi. Setiap kali Anda menggunakan token untuk mengautentikasi pengguna, server Anda HARUS memverifikasi bahwa token telah ditandatangani dengan kunci rahasia Anda.
• Jangan menyimpan data sensitif apa pun di JWT. Token ini biasanya ditandatangani untuk melindungi dari manipulasi (tidak dienkripsi) sehingga data dalam klaim dapat dengan mudah didekode dan dibaca. Enkripsikan token Anda jika Anda harus memasukkan informasi sensitif dan tidak buram ke dalamnya. Kunci penandatanganan rahasia hanya boleh diakses oleh penerbit dan konsumen; seharusnya tidak dapat diakses di luar kedua pihak ini.
• Jika Anda khawatir tentang serangan replay, sertakan nonce (klaim jti), waktu kedaluwarsa (klaim exp), dan waktu pembuatan (klaim iat) dalam klaim. Ini didefinisikan dengan baik dalam JWT Spec .