Forem: Muhammad Faqih Muntashir

Hal Yang Saya Pelajari Selama Menjadi Project Manager di Perusahaan IT

Muhammad Faqih Muntashir — Sun, 20 Nov 2022 02:24:34 +0000

Sebelum menjadi seorang Manager, saya sama sekali tidak memiliki pengalaman manajerial secara profesional, dan hanya pernah berperan sebagai IC (Individual Contributor) Software Developer melalui freelance dan magang.

Jujur saja, selama jadi IC dulu, tidak jarang saya ditimpa rasa ragu dan ketidakpuasan terhadap kemampuan Manager saya. Entah itu dari segi kemampuan teknis, maupun dari segi kemampuan manajemen.
"Harusnya begini, harusnya begitu", pikir saya.

Saya yakin, saya tidak sendiri dalam hal ini karena saya juga sering melihat meme di laman media sosial tentang IC yang kesal dengan kelakukan Manager yang tidak tahu apa-apa soal pekerjaan teknis.

Namun setelah merasakan berada di posisi mereka, saya pun menyadari bahwa keputusan buruk yang mereka buat, micromanagement yang mereka lakukan, atau perlawanan terhadap batasan teknis itu tidak selalu berasal dari diri mereka sendiri, melainkan sistem manajemen perusahaan yang "rusak".

Sistem Manajemen Perusahaan yang "Rusak"

Saya sebut "rusak" dengan kutip karena dari pengamatan saya, mayoritas perusahaan berjalan seperti ini. Jadi saya tidak tahu apakah ini memang benar rusak, atau cuma masalah perbedaan mindset saja.

Ketika kendaraanmu rusak, dan kamu tidak dapat memperbaikinya sendiri, tentu kamu perlu membawanya ke bengkel.

Ketika kamu terkena penyakit yang kamu tidak tahu bagaimana cara mengatasinya, tentu kamu perlu pergi ke dokter.

Hal-hal yang tidak bisa kita lakukan sendiri, kita percayakan kepada ahlinya. Tentu saja ini adalah sebuah pengetahuan umum. Namun, pengetahuan umum ini justru malah tidak diterapkan di banyak perusahaan.

Investor yang tidak memiliki pengalaman menjalankan bisnis malah membuat keputusan bisnis untuk perusahaan.

CEO yang tidak memiliki pengalaman product management malah mengubah-ubah backlog dan roadmap yang sudah dirancang oleh Product Manager.

Manager yang tidak memiliki pengalaman desain malah memaksa pandangan desainnya ke UI/UX Designer.

Secara hierarki, memang posisi mereka lebih tinggi, dan memang itu hak mereka, karena mereka juga memegang tanggung jawab yang lebih besar.

Tapi, meski pun kamu membayar, dan kamu yang akan menanggung risiko, tentu kamu tidak akan memaksa pendapatmu ke dokter yang memeriksamu kan?

Inilah yang maksud dengan kerusakan yang ada pada manajemen perusahaan.

Keputusan-keputusan yang seharusnya dipercayakan pada ahlinya, malah dibuat oleh atasan yang mungkin tidak memiliki kompetensi di bidang tersebut.

Efek Domino dari Sistem yang "Rusak"

Inilah salah satu kemungkinan penyebab mengapa Manager-mu membuat keputusan yang buruk; keputusan buruk tersebut dibuat oleh Manager-nya Manager-mu.

Kurang lebih seperti ini gambarannya:

Investor meminta X kepada CEO
CEO yang takut kehilangan Investor pun mematuhi permintaan Investor meskipun permintaannya bisa memperburuk bisnis
Manager yang takut kehilangan pekerjaan mematuhi instruksi CEO meskipun mengacaukan strategi dan rencana yang sudah dibuat
Individual Contributor yang takut kehilangan pekerjaan mematuhi instruksi Manager meskipun melawan harga diri dan intuisi seorang profesional

Namun, tentu tidak menutup kemungkinan arahan yang diberikan oleh Manager-mu bukan berasal dari atas, namun Manager-mu sendiri.

Jika kamu seorang Manager yang begini, tenang saja, kamu tidak sendiri kok. Menurut saya, dorongan micromanagement itu memang sudah jadi kodratnya para Manager, karena Manager ingin ikut berperan dalam pekerjaan yang mereka kelola.

Saya juga tidak suka dengan perasaan ketika melihat para IC menghasilkan keluaran yang terlihat, sedangkan saya tidak ikut serta dalam prosesnya secara langsung.

Nah, perasaan krisis eksistensi inilah yang menurut saya adalah akar dari sistem yang "rusak" a.k.a micromanagement.

Akar Sistem yang "Rusak" a.k.a Micromanagement dan Bagaimana Mengatasinya

Seperti halnya kita memercayai dokter yang memeriksa kita, bengkel yang memperbaiki kendaraan kita, kita harus sadar diri terhadap ketidakmampuan kita sendiri dan memercayakan pekerjaan pada ahlinya.

Secara hierarki, jabatan Manager memang berada di atas pada IC, dan Manager juga bertanggung jawab atas pekerjaan bawahannya. Namun, bukan berarti seorang Manager itu lebih mengerti tentang pekerjaan yang dikerjakan oleh IC itu sendiri.

Tugas Manager adalah sebagai koordinator dan pendukung para IC untuk mencapai suatu tujuan. Mereka memastikan bahwa para IC memahami visi dan bergerak ke arah yang sesuai direncanakan.

Jika kamu seorang Manager, dan sudah melakukan yang terbaik untuk itu, maka tidak perlu resah, karena kamu sudah memenuhi tanggung jawab yang diembankan kepadamu.

Jangan merasa apa yang kamu lakukan masih kurang, terlebih lagi sampai menginvasi pekerjaan para IC.

Percayalah, para IC akan lebih terbantu dan merasa senang ketika Manager-nya memercayai pekerjaan mereka.

Akan tetapi, seperti yang saya katakan di awal, "memercayakan pekerjaan pada ahlinya".

Kepercayaan tidak boleh terlahir dengan buta. Jadi, Manager juga perlu memastikan terlebih dahulu, apakah kemampuan IC yang dikelola memang sudah cukup mumpuni untuk membuat keputusan sendiri atau belum.

Jika belum, maka micromanagement bisa jadi hal yang perlu dilakukan.

Kapan Micromanagement Dibutuhkan

Sebelum mengambil kesimpulan "IC ini masih junior maka perlu micromanagement", ada hal-hal yang perlu dipertimbangkan lebih dahulu.

Tingkat urgensi pekerjaan

Ketika pekerjaan tersebut perlu diselesaikan secara cepat, dan IC terkait belum punya kepercayaandiri untuk mengambil keputusan terhadap pekerjaannya, maka micromanagement perlu dilakukan agar bisa mempercepat pengambilan keputusan.

Kemampuan dan pengetahuan Manager terhadap bidang pekerjaan

Tidak sedikit Manager yang sebelumnya bekerja sebagai IC, salah satunya karena masih banyak perusahaan yang mengatur jenjang karir IC diarahkan ke manajerial.

Biasanya, pada model perusahaan yang disebutkan di atas, Manager sudah melewati jabatan Senior, yang artinya memiliki cukup pengalaman dan pengetahuan sebagai IC.

Jika kamu adalah Manager tersebut, maka micromanagement yang dilakukan malah bisa menjadi manfaat bagi IC junior, dengan syarat:

Sesuai dengan bidang yang pernah ditempuh
Selalu menjelaskan alasan dari tiap keputusan yang dibuat. Lebih baiknya lagi jika di-backup data
Tetap interaktif, terbuka, mendengarkan, dan menghargai pendapat dari IC

Apabila tidak dilakukan memenuhi tiga syarat tersebut, maka kemungkinan buruk yang terjadi adalah IC akan kehilangan kepercayaan diri, namun juga akan sulit untuk menghormati dan menghargai kamu.

- - -

Menurut saya, pendapat seseorang yang tidak memiliki pengalaman maupun data itu tidak otomatis menjadi lebih bernilai atau benar hanya karena memiliki jabatan Manager.

Jika sama-sama tidak didukung pengalaman atau data, saya akan memilih solusi yang diberikan oleh IC, sehingga mereka bisa percaya diri saat bekerja tanpa khawatir akan adanya revisi tanpa alasan yang kuat.

Pun jika solusi tersebut ternyata salah, maka hanya perlu melakukan iterasi kembali, tanpa menyalahkan satu sama lain.

Membuat Otentikasi JWT dengan PHP Native

Muhammad Faqih Muntashir — Mon, 16 Nov 2020 07:45:39 +0000

Kode dari hasil tutorial ini bisa didownload di sini:
https://github.com/itsfaqih/jwt-php-native

Persiapan

Sebelum mengikuti tutorial ini, pastikan kalian sudah meng-install requirements di bawah ini.

Requirements

Composer (https://getcomposer.org/download)
PHP (https://php.net/downloads, atau dari XAMPP dan sejenisnya)
Apache (https://httpd.apache.org/download.cgi) (XAMPP sudah include)
Postman (https://www.postman.com/downloads/) atau sejenisnya

Catatan: Apache diperlukan karena penggunaan function getallheaders() untuk mendapatkan request header. Jika kalian ingin menggunakan web server lainnya, harap menyesuaikan.

Membuat Proyek

Install Library

Pertama, kita buat direktori untuk proyek ini:



mkdir jwt-php-native
cd jwt-php-native

Jika kalian menggunakan XAMPP, atau laragon, atau yang lainnya, bisa langsung dibuat di dalam direktorinya masing-masing (htdocs, www, dll).

Di tutorial ini saya hanya akan menggunakan built-in web server dari php saja.

Setelah masuk ke direktori, kita buat file composer.json melalui perintah di bawah.



composer init

Saat menjalankan perintah di atas, kamu akan mendapati prompt untuk mengisi nama package, deskripsi, author, dll, itu bisa kalian isi sesuai keinginan kalian, atau bisa juga langsung enter semua saja. Hingga bagian dependency, kita ketikkan "no" dulu.



Define your dependencies.

Would you like to define your dependencies (require) interactively [yes]? no
Would you like to define your dev dependencies (require-dev) interactively [yes]? no

Lalu tekan enter saat konfirmasi.



Do you confirm generation [yes]?

Kemudian kita install library yang dibutuhkan, yaitu library dotenv dan library untuk membuat jwt-nya:



composer require vlucas/phpdotenv firebase/php-jwt

Jika kalian penasaran mengapa kita juga butuh menginstall library dotenv, karena agar mempermudah kita menerapkan penggunaan environment variable, yang mana ini adalah cara terbaik untuk menyimpan data sensitif dari aplikasi. (Bisa baca detailnya di sini)

Selesai meng-install kedua library tersebut, maka akan ada direktori vendor dan file composer di dalam proyek kita:

Membuat Custom Environment Variable

Ini adalah fitur utama dari library dotenv tadi. Kita dapat membuat custom environment variable dengan mudah melalui file ".env".

Mari kita buat file tersebut, kemudian isi dengan ACCESS_TOKEN_SECRET dan REFRESH_TOKEN_SECRET:

Nilai dari kedua token tersebut sebenarnya bebas. Kalian bisa mengisinya dengan apapun yang kalian inginkan, dengan syarat keduanya tidak boleh sama.

Namun karena secret key di sini bersifat rahasia layaknya password, akan lebih baik menggunakan random string panjang yang sulit ditebak. Terlebih lagi kedua secret itu cukup disimpan dan tidak perlu diingat.

Dalam tutorial ini saya menggunakan password generator untuk membuat secret key-nya.

Membuat Endpoint Otentikasi (Login)

Kita buat file "login.php". File ini akan digunakan sebagai jalur user melakukan otentikasi JWT melalui request method POST.

Di sini saya hanya menggunakan data mock/dummy, tapi jika kalian cukup bersemangat, bisa juga buat database, buat tabel, buat koneksi, dst.

Import Library
Sebelum menulis apapun, baiknya kita mengimport library yang nantinya akan digunakan:



// Import script autoload agar bisa menggunakan library
require_once('./vendor/autoload.php');
// Import library
use Firebase\JWT\JWT;
use Dotenv\Dotenv;

Lalu kita load custom environment variable kita:



$dotenv = Dotenv::createImmutable(__DIR__);
$dotenv->load();

Atur Content-Type
Agar response yang dikirim ke user dibaca sebagai JSON, kita perlu mengatur response header bagian Content-Type seperti ini:



header('Content-Type: application/json');

Validasi Method Request
Karena proses login ini menggunakan method POST, yang perlu kita lakukan pertama kali adalah memeriksa apakah method yang digunakan oleh user sudah sesuai atau belum:



// Cek method request apakah POST atau tidak
if ($_SERVER['REQUEST_METHOD'] !== 'POST') {
  http_response_code(405);
  exit();
}

Dengan kode di atas, apabila user tidak mengakses login.php menggunakan method POST, maka akan mendapatkan error kode 405, "method not allowed", yang berarti method yang digunakan tidak diizinkan.

Validasi Format Data
Umumnya JWT diterapkan pada sistem microservice (menggunakan API) sehingga data yang diterima oleh backend saat proses login ini bukan lah berupa form data (karena tidak melalui form), melainkan JSON.

Nilai input form data diambil menggunakan variabel $_POST, sedangkan untuk raw JSON diambil menggunakan cara di bawah:



// Ambil JSON yang dikirim oleh user
$json = file_get_contents('php://input');
// Decode json tersebut agar mudah mengambil nilainya
$input = json_decode($json);

Setelah men-decode JSON tersebut, barulah kita melakukan validasi data yang ada di dalamnya:



// Jika tidak ada data email atau password
if (!isset($input->email) || !isset($input->password)) {
  http_response_code(400);
  exit();
}

Dengan kode di atas, apabila user tidak memasukkan email atau password, maka akan mendapatkan error kode 400, "bad request", yang berarti request yang dikirim oleh user tidak valid.

Otentikasi User
Seperti yang saya katakan sebelumnya, di sini saya menggunakan data mock, jadi untuk data user saya buat menjadi variabel seperti ini:



// Cuma data mock/dummy, bisa diganti dengan data dari database
$user = [
  'email' => 'johndoe@example.com',
  'password' => 'qwerty123'
];

Kemudian kita cocokkan dengan data yang dikirim oleh user tadi:



// Jika email atau password tidak sesuai
if ($input->email !== $user['email'] || $input->password !== $user['password']) {
  echo json_encode([
    'message' => 'Email atau password tidak sesuai'
  ]);
  exit();
}

Dengan demikian, jika data email atau password yang dikirim itu salah, maka user akan mendapatkan pesan "Email atau password tidak sesuai".

Selanjutnya kita tinggal perlu membuat dan mengirim JWT ke user saat login berhasil.

Buat variabel untuk menyimpan waktu kadaluarsa access token-nya:



// 15 * 60 (detik) = 15 menit
$expired_time = time() + (15 * 60);

Waktu kadaluarsa access token tidak perlu dibuat terlalu lama karena alasan keamanan.

Setelah itu kita buat variabel payload yang mana akan jadi payload token kita:



$payload = [
  'email' => $input->email,
  'exp' => $expired_time
];

Sebenarnya di dalam payload ini kita hanya perlu email saja, namun karena cara kerja dari library JWT yang kita pakai, kita perlu key 'exp' untuk mengatur waktu kadaluarsa token-nya.

Selanjutnya tinggal generate token menggunakan library-nya, dan kirim ke user:



$access_token = JWT::encode($payload, $_ENV['ACCESS_TOKEN_SECRET']);
echo json_encode([
  'accessToken' => $access_token,
  'expiry' => date(DATE_ISO8601, $expired_time)
]);

Sampai sini biasanya sudah cukup dan sudah bisa bekerja dengan baik.

Tapi jika kalian tertarik untuk lanjut mempelajari tentang in memory token, yang mana akan saya buat tutorial selanjutnya, kalian bisa ikuti langkah penambahan refresh token di bawah (opsional).

Menambahkan Refresh Token di Http-only Cookie



// Ubah waktu kadaluarsa lebih lama (1 jam)
$payload['exp'] = time() + (60 * 60);
$refresh_token = JWT::encode($payload, $_ENV['REFRESH_TOKEN_SECRET']);
// Simpan refresh token di http-only cookie
setcookie('refreshToken', $refresh_token, $payload['exp'], '', '', false, true);

Cookie adalah data yang disimpan oleh browser user dan akan selalu diselipkan setiap user membuat request selanjutnya tepat setelah cookie tersebut ditambahkan.

Menggunakan http-only berarti cookie tersebut tidak dapat diakses melalui javascript, sehingga bisa mencegah tercurinya refresh token.

Membuat Endpoint Protected Resource

Protected Resource di sini maksudnya adalah data yang dilindungi. Sebagai contoh: konten yang hanya bisa dilihat oleh user yang sudah login.

Dalam contoh ini, saya membuat file "games.php" yang isinya adalah daftar game. Daftar game ini nantinya hanya bisa diakses jika user mengirimkan access token yang valid.

Import Library
Sama seperti sebelumnya, kita import library-nya terlebih dahulu:



// Import script autoload agar bisa menggunakan library
require_once('./vendor/autoload.php');
// Import library
use Firebase\JWT\JWT;
use Dotenv\Dotenv;

Jangan lupa custom environment variable kita:



$dotenv = Dotenv::createImmutable(__DIR__);
$dotenv->load();

Atur Content-Type
Seperti sebelumnya juga, kita atur response header Content-Type-nya:



header('Content-Type: application/json');

Validasi Method Request
Seperti sebelumnya, kita juga memvalidasi method yang digunakan oleh user saat request. Bedanya di sini harus menggunakan GET:



if ($_SERVER['REQUEST_METHOD'] !== 'GET') {
  http_response_code(405);
  exit();
}

Verifikasi Token dan Mengembalikan Data
Jika saat login yang divalidasi adalah format data dan kebenaran email & passwordnya, di sini kita memverifikasi token yang dikirim oleh user.

User akan mengirim token melalui header authorization, yang berarti kita perlu membaca header request-nya:



$headers = getallheaders();
if (!isset($headers['Authorization'])) {
  http_response_code(401);
  exit();
}

Kode di atas akan memeriksa keberadaan header authorization. Jika tidak ada, maka user akan mendapatkan error 401, "Unauthorized", yang berarti tidak memiliki otoritas atau hak untuk mengaksesnya.

Kemudian kita ambil token yang ada pada header. Karena dalam header authorization berisi "Bearer ", maka kita perlu menghapus string "Bearer":



list(, $token) = explode(' ', $headers['Authorization']);

Lalu kita verifikasi token tersebut di dalam try catch statement, karena method verifikasi dan decode dari library yang kita gunakan akan melempar sebuah exception apabila tidak valid:



try {
  // Men-decode token. Dalam library ini juga sudah sekaligus memverfikasinya
  JWT::decode($token, $_ENV['ACCESS_TOKEN_SECRET'], ['HS256']);
// Data game yang akan dikirim jika token valid
  $games = [
    [
      'title' => 'Dota 2',
      'genre' => 'Strategy'
    ],
    [
      'title' => 'Ragnarok',
      'genre' => 'Role Playing Game']
    ]
  ];
echo json_encode($games);
} catch (Exception $e) {
  // Bagian ini akan jalan jika terdapat error saat JWT diverifikasi atau di-decode
  http_response_code(401);
  exit();
}

Menguji Proyek

Kita jalankan terlebih dahulu:



// Jalan di command prompt atau terminal
php -S localhost:8000

Jika kalian menggunakan XAMPP atau sejenisnya, dan sudah menyimpan di direktorinya (seperti htdocs), maka bisa cukup jalankan web servernya (Apache atau lainnya).

Kemudian buka Postman, dan langsung kita coba lakukan login melalui http://localhost:8000/login.php (jangan lupa sesuaikan port-nya), dengan method POST:

Lalu isi body dengan raw JSON berupa data email dan password, kemudian klik "Send":

Jika berhasil, maka kita akan mendapatkan response semacam ini:

Dari response itu, kita copy dan simpan accessToken. Kemudian kita coba buka endpoint "/games.php" tanpa mengatur apapun, maka kita akan mendapat status 401, yang berarti kita tidak memiliki akses ke resource tersebut:

Sekarang kita isi bagian authorization dengan type bearer dan diisi token tadi:

Hasilnya data game akan dikembalikan ke user:

Penutup

Sekian pembahasan yang cukup panjang ini tentang pembuatan otentikasi JWT dengan PHP native.

Jika kita perhatikan, belum ada peran refresh token di sini.

Fungsi refresh token sendiri adalah untuk memperbarui access token user, karena access token memiliki umur yang pendek (15 menit dalam tutorial ini).

Alasan mengapa belum ada penggunaan refresh tokennya, ini memang saya sengaja karena cara implementasi di sini (menggunakan http-only cookie) akan lebih masuk akal jika dibahas pada tutorial selanjutnya.

Terima kasih sudah membaca, semoga bisa bermanfaat.

Apa itu JWT (JSON Web Token)?

Muhammad Faqih Muntashir — Sat, 14 Nov 2020 14:14:38 +0000

Konsep Token JWT

Seperti namanya, JSON Web Token, yang berarti token ini menggunakan JSON (Javascript Object Notation), lalu token ini memungkinkan kita untuk mengirimkan data yang dapat diverifikasi oleh dua pihak atau lebih.

Agar lebih paham, mari kita bahas bagaimana JWT bekerja melalui contoh:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1hIjoiRmFxaWgifQ.jtYrULLMxWPWfy39r4Qm0gCxo-5–542VhsRDSO5cjQ

Jika kita perhatikan dalam teks acak di atas, terdapat titik yang memisahkan teks tersebut menjadi 3 bagian.

Header

Bagian pertama disebut dengan header. Header berisi informasi tentang algoritma dan jenis token yang digunakan.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Bagian ini hanyalah string yang di-encode menggunakan base64. Jadi kita bisa mendapatkan nilai asli dari teks tersebut dengan men-decodenya. Kalian bisa cari web decode base64 online untuk membuktikannya sendiri.

Nilai yang di dapat dari teks tersebut adalah:

{"alg":"HS256","typ":"JWT"}

Payload

Bagian kedua disebut dengan payload. Payload berisi data yang ingin dikirim melalui token.

eyJuYW1hIjoiRmFxaWgifQ

Bagian ini juga di-encode menggunakan base64, dan data yang didapat dari hasil decode-nya adalah:

{"nama":"Faqih"}

Dalam penerapannya di otentikasi atau pun otorisasi, biasanya data ini berupa data yang sifatnya unik bagi user, seperti: email, id/uuid, dan juga data yang berkaitan dengan otorisasi seperti role, karena data tersebut akan digunakan sebagai tanda pengenal si pengirim token.

Oh ya, jangan pernah menyelipkan data yang sifatnya konfidental atau sensitif ke dalam JWT (seperti password). Seperti yang kalian baru saja pelajari, kita bisa lihat isinya cukup dengan men-decodenya.

Signature

Bagian ketiga adalah signature. Signature adalah hash gabungan dari header, payload dan sebuah secret key (berupa string random panjang biasanya):

jtYrULLMxWPWfy39r4Qm0gCxo-5–542VhsRDSO5cjQ

Algoritma hash yang digunakan mengikuti dari apa yang sudah ditentukan di dalam header. Jadi jika ditulis kode untuk membuat signature, maka kurang lebih akan seperti ini:

// Contoh menggunakan bahasa PHP. Titik di PHP adalah cara menggabungkan string (concatenation)
$signature = hash(base64_encode($header).base64_encode($payload).$secret)

Catatan: Kode di atas hanya ilustrasi dan bukan kode yang sebenarnya.

Signature ini berguna untuk memverifikasi bahwa header maupun payload yang ada dalam token tidak berubah dari nilai aslinya (karena untuk membuat payload dan header palsu itu cukup mudah).

Signature-nya sendiri tidak mungkin dapat diakali, karena sudah dalam berbentuk hash; yang mana adalah fungsi satu arah (tidak dapat dikembalikan ke nilai semula), dan meski kita tahu algoritma hashing-nya, kita juga memerlukan secret key yang mana hanya si pembuat aplikasi yang tahu.

Cara Kerja Verifikasi Signature

Jika kalian pernah membuat otentikasi biasa menggunakan email/username dan password, maka kalian tidak asing lagi dengan proses hashing dan verifikasi password.

Saat hashing, kalian melakukannya seperti ini:

// function hash password dalam PHP
$hash = password_hash('password_user', PASSWORD_BCRYPT);

Pada kode di atas, kita membuat hash password user menggunakan algoritma bcrypt. Hash ini lah yang kalian simpan ke dalam database.

Lalu saat user login, kalian mencocokkan string password yang diinput user dengan hash yang ada di database seperti ini:

// function verifikasi hash password dalam PHP
$cocok = password_verify($input_user, $hash_dari_db);
// $cocok akan bernilai true jika passwordnya benar

Hal ini juga mirip pada saat verifikasi JWT.
Saat membuat signature kita hash:

$signature = password_hash(base64_encode($header).base64_encode($payload).$secret, PASSWORD_BCRYPT);

Catatan: Sekali lagi, kode hanya sebagai ilustrasi, jangan ditiru!

Lalu saat user mengirimkan token, bisa kita cek menggunakan function seperti ini:

function verify($token, $secret) {
  // Memisahkan header, payload, dan signature
  list($header, $payload, $signature) = explode('.', $token);
  // Mencocokkan apakah header dan payload saat ini masih sama seperti yang ada di signature (tidak berubah)
  return password_verify($header.$payload.$secret, $signature);
}
// Menggunakan function
$cocok = verify($jwt_dari_user, $secret_yang_dipakai_saat_hash);

Dengan demikian, apabila terdapat data header atau payload yang diubah, otomatis tidak akan lagi cocok dengan signaturenya. Membuat signature sendiri pun tidak mungkin dilakukan, karena dalam prosesnya diperlukan secret key dalam proses hashingnya.

Penerapan Oleh Dua Pihak atau Lebih

Ini merupakan alasan mengapa JWT dibuat.

Pada otentikasi/otorisasi umumnya kita menggunakan session, yang mana ketika user login ke sebuah web, maka server akan menyimpan data user tersebut.

Data session yang tersimpan itu akan digunakan untuk melakukan verifikasi otentikasi; memastikan user sudah login atau belum, dan otorisasi; memastikan hak akses user yang login.

Contoh kodenya:

$sudah_login = $_SESSION['login'] === true;
$adalah_admin = $_SESSION('role') === 'admin';
if ($sudah_login) {
  if ($adalah_admin) {
    echo 'Selamat datang admin!';
  } else {
    echo 'Selamat datang user!';
  }
} else {
  echo 'Silahkan login';
}

Sejauh ini tidak ada masalah. Namun, jika kalian memiliki dua aplikasi atau lebih dan ingin bisa berbagi session, tentu menggunakan session biasa tidak memungkinkan, karena session user hanya disimpan oleh website yang digunakan user untuk login sebelumnya.

Nah, di sinilah peran JWT.

Karena valid tidaknya JWT bisa diverifikasi secara mandiri menggunakan signature, ini memungkinkan untuk aplikasi lain menggunakan token tersebut asalkan memiliki secret key yang sama.

Lalu, karena kasus ini adalah untuk otentikasi/otorisasi, maka aplikasi server B juga harus menyimpan data user yang sama di databasenya.

Setelah verifikasi JWT di server B berhasil, kita bisa lanjut melakukan pengecekan hak akses menggunakan data dari payload; uuid, email, dan role, dengan dicocokkan yang ada di database, dan seterusnya.

Jadi singkatnya, token hasil dari aplikasi server A, dapat digunakan juga oleh aplikasi server B.

Kesimpulan

Dari pembahasan di atas, maka kita dapat mengambil kesimpulan bahwa:

JWT dapat memastikan integritas data yang dikirim (Data yang ada di dalam token tidak dapat dimanipulasi).
JWT dapat digunakan untuk otentikasi/otorisasi dua aplikasi yang berbeda

Penutup

Begitulah penjelasan tentang konsep dari JWT, dan bagaimana JWT bisa menjaga integritas data yang dikirim oleh user. Semoga bisa bermanfaat bagi yang baru belajar.

Jika ada yang masih dibingungkan atau ingin mengkritisi dan memberikan saran, jangan lupa untuk mengirimkannya di komentar.

Pada tulisan selanjutnya saya akan membahas tentang bagaimana cara menyimpan token JWT yang baik di frontend (biasanya untuk aplikasi SPA).