Masuk tanpa kata sandi dengan magic link: checklist UX dan keamanan

Apa itu sign-in dengan magic link, dan apa yang bisa salah

Magic link adalah tautan sekali pakai untuk masuk yang dikirim ke email Anda. Alih-alih mengetik kata sandi, Anda membuka email, mengetuk tautan, dan langsung masuk.

Ini cocok ketika orang tidak suka kata sandi, sering lupa, atau hanya masuk sesekali. Juga membantu mengurangi penggunaan ulang kata sandi antar situs karena tidak ada kata sandi yang disimpan. Namun ini tidak menghilangkan kebutuhan keamanan—kuncinya hanya berpindah ke kotak masuk email Anda.

Jadi ini pertukaran yang harus jelas: masuk tanpa kata sandi dengan magic link hanya seaman akun email pengguna dan kemampuan mereka menjaga aksesnya tetap pribadi. Jika seseorang bisa membaca email Anda, mereka seringkali bisa masuk atas nama Anda.

Beberapa cara paling umum magic link gagal di dunia nyata:

• Akses inbox dicuri (kata sandi email dipancing, SIM swap untuk pemulihan email, malware, atau komputer bersama yang dibiarkan masuk).
• Tautan diteruskan (sengaja atau tidak) dan orang yang salah menggunakannya.
• Pengguna membuka email di satu perangkat tapi ingin sesi di perangkat lain, lalu bingung saat aplikasi terbuka di tempat “yang salah”.
• Perangkat bersama tetap masuk, sehingga orang berikutnya mendapat akses.
• Alamat email salah ketik, dan tautan masuk terkirim ke orang lain.

Contoh kecil: seseorang meminta tautan di laptop kerja, lalu mengecek email di ponsel pribadi. Mereka mengetuk tautan, ponsel masuk, tapi laptop masih menampilkan layar login. Jika alur Anda tidak menjelaskan apa yang terjadi, tiket dukungan akan muncul.

Jika Anda membangun ini di produk yang dibuat dengan AppMaster, perlakukan langkah email seperti tindakan sensitif, bukan hanya fitur kenyamanan. Pesan yang jelas, tautan berdurasi pendek, dan kontrol sesi sederhana membuat pengalaman terasa aman.

Apakah masuk lewat email tanpa kata sandi tepat untuk produk Anda?

Masuk tanpa kata sandi dengan magic link paling cocok ketika tujuan Anda adalah akses cepat dengan gesekan minimal, bukan perlindungan maksimal. Cocok untuk produk yang penggunaannya jarang dan pengguna benci reset kata sandi, serta ketika inbox email sudah menjadi “rumah” pengguna.

Cara sederhana menentukan: jika seseorang masuk ke akun yang salah, kerugian realistis terburuknya apa? Jika jawabannya "menyebalkan, tapi bisa diperbaiki", magic link bisa menjadi default yang baik.

Cocok untuk:

• Aplikasi risiko rendah sampai sedang (alat internal, panel admin untuk tim kecil, portal pelanggan dengan izin terbatas)
• Produk dengan pengguna jarang yang membenci reset kata sandi
• Pengalaman "Buat saya masuk cepat" seperti dukungan, onboarding, atau persetujuan
• Produk tahap awal yang ingin mengurangi tiket dukungan

Hati-hati atau hindari magic link sebagai satu-satunya metode saat:

• Akun bernilai tinggi (transfer uang, saldo besar, tindakan irreversible)
• Anda menyimpan data teratur atau sensitif (kesehatan, legal, catatan keuangan rinci)
• Pengguna sering berbagi inbox (mailbox bersama, akun resepsionis)
• Audiens Anda kemungkinan menjadi target (eksekutif, admin, peran ber-privilege tinggi)

Jika produk Anda memiliki momen sensitif daripada akun sensitif, gunakan sign-in email untuk masuk lalu tambahkan faktor kedua atau pemeriksaan step-up untuk aksi berisiko. Misalnya, minta konfirmasi tambahan saat mengubah detail pembayaran, mengekspor data, atau menambah admin baru.

Juga putuskan apa yang boleh dilakukan oleh email. "Tautan hanya untuk login" lebih aman dan lebih mudah dijelaskan. "Login + pemulihan akun" praktis, tapi artinya siapa pun yang punya akses email bisa mengambil alih akun. Jika Anda mendukung perubahan alamat email, anggap itu sebagai tindakan berisiko tinggi.

Jika Anda membangun aplikasi di platform no-code seperti AppMaster, keputusan ini tetap penting: UI bisa sederhana, tapi kebijakan tentang tindakan sensitif dan pemulihan harus jelas sejak awal.

Alur dasar magic link (dan keputusan di dalamnya)

Magic link terasa sederhana bagi pengguna, tapi ada banyak pilihan kecil di balik layar. Alur yang rapi membuat orang tetap bergerak dan mengurangi tiket dukungan.

Alur yang dilihat pengguna

Kebanyakan produk mengikuti jalur yang sama: pengguna memasukkan email, menerima pesan, mengetuk tautan, dan langsung masuk.

Perbaikan umum adalah langkah konfirmasi akhir setelah tautan terbuka. Alih-alih langsung masuk, tampilkan layar singkat seperti “Confirm sign-in to Acme” dengan satu tombol. Ini membantu ketika seseorang mengetuk tautan di perangkat yang salah atau email dibuka oleh alat preview.

Di mobile, putuskan apa arti "ketuk tautan". Jika Anda punya aplikasi native, pengalaman terbaik biasanya: ketuk tautan -> buka aplikasi -> selesaikan sign-in. Jika aplikasi tidak terpasang, fallback ke web mobile dan tawarkan opsi “Buka aplikasinya” nanti.

Keputusan yang harus Anda buat

Sebelum membangun masuk tanpa kata sandi dengan magic link, tetapkan aturan ini agar pengalaman dapat diprediksi:

• Di mana tautan dibuka: in-app browser, system browser, atau langsung di aplikasi native (deep link).
• Apakah sign-in otomatis atau membutuhkan layar konfirmasi akhir.
• Apa yang terjadi jika pengguna sudah masuk saat mengetuk tautan.
• Apa yang terjadi jika email diubah di tengah alur atau pengguna mengetik email berbeda pada percobaan berikutnya.
• Apa arti "sukses": kembali ke halaman terakhir, layar beranda default, atau halaman yang memicu sign-in.

Sudah masuk sering terlupakan. Jika pengguna yang sudah masuk mengetuk tautan baru, Anda bisa (a) mempertahankan akun yang sama dan menampilkan “You are already signed in,” atau (b) memperlakukannya sebagai pergantian akun dan meminta konfirmasi. Untuk aplikasi yang dibuat dengan AppMaster (seperti portal pelanggan atau alat internal), opsi (a) biasanya lebih aman kecuali pergantian akun memang fitur nyata.

Aturan kedaluwarsa: cukup singkat untuk aman, cukup panjang untuk bekerja

Magic link hanya terasa tanpa kata sandi jika mudah. Kedaluwarsa adalah bagian yang bisa merusak janji itu secara diam-diam. Terlalu singkat, orang menemui link kadaluwarsa di inbox dan menyerah. Terlalu lama, tautan yang diteruskan atau terekspos menjadi risiko lebih besar.

Awal praktik yang baik untuk masuk tanpa kata sandi dengan magic link adalah jendela kedaluwarsa antara 10 hingga 30 menit. Jendela lebih singkat (3–10 menit) cocok untuk aksi berisiko tinggi seperti masuk area admin atau menyetujui pembayaran. Jendela lebih panjang (30–60 menit) bisa dipakai untuk aplikasi risiko rendah, tapi hanya jika Anda punya kontrol sesi yang kuat dan manajemen perangkat yang baik.

Cantumkan masa kedaluwarsa dengan jelas di email dan pada layar “Check your email”. Jangan sembunyikan di teks kecil. Gunakan kalimat sederhana seperti “Tautan ini kedaluwarsa dalam 15 menit.” Jika bisa, tampilkan countdown di layar tunggu, tapi jangan bergantung pada jam perangkat pengguna untuk akurasi.

Keterlambatan email dan perbedaan jam sering terjadi. Beberapa provider menahan pesan beberapa menit, dan beberapa pengguna membuka email di perangkat lain dari yang meminta tautan. Beberapa aturan membantu menghindari kebingungan:

• Terapkan kedaluwarsa berdasarkan waktu server Anda, bukan waktu pengguna.
• Jika tautan hampir kedaluwarsa, tampilkan pesan jelas seperti “Tautan kedaluwarsa. Minta yang baru.”
• Jika tautan masih valid tapi sudah dipakai, katakan langsung (dan tawarkan langkah cepat berikutnya).

Saat link kedaluwarsa, pengalaman terbaik adalah sekali ketuk kirim ulang dari halaman landing. Jaga keamanannya: hanya izinkan kirim ulang setelah cooldown singkat, dan hindari mengungkapkan apakah sebuah email terdaftar di sistem Anda. Halaman bisa mengatakan “Jika email ini terdaftar, kami akan mengirim tautan baru.”

Detail kecil yang mengurangi tiket dukungan: sertakan alamat email tepat yang dikirim (sebagian disamarkan) di layar tunggu, plus opsi “Ganti email”. Jika Anda membangun alur di alat no-code seperti AppMaster, ini biasanya hanya beberapa status UI, tapi mencegah banyak kebingungan “Saya tidak pernah menerima email.”

Penggunaan sekali pakai dan aturan reuse (bagian yang sering kena oleh pengguna)

Untuk kebanyakan produk, standar adalah tautan sekali pakai. Ini melindungi pengguna dari kecelakaan umum seperti penerusan email, inbox bersama, atau seseorang yang membuka pesan lama berminggu-minggu kemudian. Juga memudahkan dukungan: jika tautan dipakai, maka selesai.

Intinya adalah memutuskan apa arti “dipakai” dalam praktik. Orang mengklik dua kali, membuka di perangkat yang salah, atau mengetuk dalam preview email. Aturan Anda harus aman, tapi juga terasa adil.

Apa yang harus terjadi saat tautan yang sama dibuka dua kali?

Baseline yang baik: login pertama yang berhasil mengonsumsi token, dan pembukaan selanjutnya menampilkan pesan jelas seperti “Tautan ini sudah dipakai. Minta yang baru.” Hindari error yang samar. Jika ingin mengurangi frustrasi, Anda dapat menawarkan jendela aman kecil sebelum konsumsi, misalnya: tandai sebagai dipakai hanya setelah sesi dibuat.

Beberapa pola ramah pengguna yang tetap aman:

• Jika tautan dibuka lagi di perangkat yang sama dan pengguna sudah masuk, arahkan mereka ke aplikasi (tanpa menampilkan apa pun).
• Jika tautan dibuka lagi tapi tidak ada sesi aktif, tampilkan “Sudah dipakai atau kedaluwarsa” plus satu tombol untuk mengirim tautan baru.
• Jika tautan dibuka di perangkat berbeda setelah dipakai, anggap tidak valid dan minta tautan baru.

Jika pengguna meminta beberapa tautan, apakah tautan lama mati?

Putuskan ini lebih dulu dan konsisten. Default teraman adalah: setiap permintaan baru membatalkan semua tautan sebelumnya yang masih berlaku. Ini membatasi kerusakan jika seseorang mendapatkan akses inbox nanti.

Jika Anda membiarkan banyak tautan tetap valid sekaligus, Anda perlu proteksi lebih kuat (kedaluwarsa pendek, penggunaan sekali pakai yang ketat, dan kontrol perangkat/sesi yang jelas). Kalau tidak, “masuk tanpa kata sandi dengan magic link” bisa berubah jadi kunci akses berumur panjang yang tersimpan di email.

Hindari tautan yang dapat digunakan ulang berulang-ulang. Meski terasa nyaman, itu melatih pengguna menganggap email sebagai kunci permanen dan membuat pengambilalihan akun jauh lebih sulit untuk dibatasi.

Jika Anda membangun alur di no-code seperti AppMaster, tuliskan aturan ini dalam bahasa sederhana (valid, dipakai, kedaluwarsa, diganti) agar pesan UI sesuai dengan apa yang ditegakkan backend.

Detail UX yang mengurangi kebingungan dan tiket dukungan

Kebanyakan tiket dukungan tentang magic link bukan bug keamanan. Mereka: “Saya tidak mendapat email”, “Saya mengklik tapi tidak terjadi apa-apa”, atau “Apakah ini phishing?”. UX yang baik mencegah ketiganya.

Setelah pengguna mengirim email mereka, tampilkan layar "Check your email" khusus daripada toast kecil. Buat tenang dan spesifik: beri tahu alamat mana yang dikirimi, apa yang harus dilakukan selanjutnya, dan apa yang dicoba jika tidak tiba.

Layar check-email yang kuat biasanya mencakup:

• Alamat email yang digunakan, dengan opsi jelas “Ganti email”
• Tombol kirim ulang dengan countdown singkat (agar pengguna tidak spam klik)
• Catatan tentang waktu pengiriman tipikal (misal, “Biasanya tiba dalam 1 menit”)
• Pengingat lembut untuk cek spam, tab promosi, dan filter perusahaan
• Baris singkat tentang keamanan: “Jangan teruskan tautan ini”

Kepercayaan dibangun di dalam email itu sendiri. Gunakan nama pengirim dan subject yang konsisten, dan buat isi yang dapat diprediksi. Tambahkan satu atau dua detail yang membantu pengguna yakin itu sah, seperti “Diminta dari Chrome di Windows” atau “Diminta pada 15:42”. Hindari kata-kata menakutkan. Sederhana lebih baik: “Tautan ini masuk untuk Anda. Jika Anda tidak memintanya, abaikan email ini.”

Rencanakan juga kegagalan paling umum: email tertunda atau terfilter. UI Anda tidak boleh berakhir tanpa jalan keluar. Jika tautan mungkin memakan waktu, jelaskan apa yang bisa dilakukan sambil menunggu dan tawarkan fallback ramah.

Fallback praktis adalah memasukkan kode sekali pakai pendek di email yang sama dengan tautan. Lalu layar check-email bisa menawarkan “Masukkan kode sebagai gantinya” untuk kasus ketika tautan membuka di perangkat yang salah atau diblokir oleh scanner keamanan email.

Detail kecil tapi penting: jika pengguna mengklik tautan lama atau sudah dipakai, tunjukkan pesan membantu dan satu langkah jelas seperti “Kirim tautan baru”, bukan error generik.

Dasar-dasar keamanan di balik layar (tanpa bicara crypto berat)

Magic link seaman token yang ada di baliknya. Perlakukan token itu seperti kunci sementara ke akun: harus sulit ditebak, umur pendek, dan hanya bisa dipakai sesuai maksud Anda.

Mulailah dengan ketidak-terdugaan. Hasilkan token acak panjang (jangan berbasis email, waktu, atau ID bertambah). Simpan sesedikit mungkin. Pola umum adalah menyimpan versi hash dari token (jadi jika DB bocor, tautan mentah tidak bisa dipakai kembali) plus metadata minimal untuk validasi.

Mengikat token ke konteks bisa mencegah penerusan mudah. Anda tidak selalu ingin pengikatan ketat (orang berganti perangkat), tapi Anda bisa menambahkan pemeriksaan ringan untuk menangkap penyalahgunaan jelas. Contoh: kaitkan token dengan alamat email yang memintanya, dan opsional dengan fingerprint kasar seperti keluarga user agent atau rentang IP awal. Jika konteks tidak cocok, minta tautan baru alih-alih memblokir keras.

Pembatasan laju lebih penting daripada matematika canggih. Tanpanya, penyerang bisa mengirim spam ke form login Anda, mengganggu pengguna, dan mencoba mencari tahu apakah email ada.

• Batasi permintaan per email dan per IP (termasuk kirim ulang)
• Tambahkan cooldown singkat antara email (misal, 30–60 detik)
• Tampilkan pesan yang sama apakah email ada atau tidak
• Beri peringatan pada lonjakan (banyak email ke banyak alamat)

Akhirnya, catat apa yang Anda perlukan saat pengguna bilang “Saya tidak melakukan ini.” Rekam event seperti permintaan link, email dikirim, tautan dibuka, token diterima/gagal (dan kenapa), dan sesi dibuat. Sertakan timestamp, IP, dan user agent. Di alat seperti AppMaster, event ini bisa direkam sebagai bagian dari business process login sehingga dukungan dan keamanan punya jejak jelas tanpa menggali internals server.

Manajemen perangkat dan sesi yang bisa dipahami pengguna

Magic link menghilangkan kata sandi, tapi pengguna masih berpikir berdasarkan perangkat: “Saya masuk di ponsel saya” atau “Saya menggunakan laptop bersama.” Jika Anda tidak memberi mereka cara sederhana untuk melihat dan mengakhiri sesi, tiket dukungan akan melonjak.

Mulailah dengan satu keputusan: berapa banyak sesi aktif yang boleh dimiliki satu akun pada waktu yang sama. Untuk kebanyakan produk konsumen, banyak sesi diperbolehkan (ponsel + laptop). Untuk alat sensitif (panel admin, keuangan, operasi internal), Anda mungkin membatasi atau meminta tautan baru saat perangkat baru muncul.

Halaman kecil “Perangkat” atau “Sesi aktif” membuat ini mudah dimengerti. Buat informasinya sederhana dan sedikit kasar daripada terlalu presisi. Baris yang baik biasanya mencakup:

• Nama perangkat (atau browser dan OS jika tidak bisa deteksi model)
• Perkiraan lokasi (kota atau wilayah, bukan alamat lengkap)
• Waktu aktif terakhir
• Waktu pertama terlihat
• Label singkat seperti “Perangkat ini” untuk sesi saat ini

Dari sana, berikan dua aksi jelas. “Log out” harus mengakhiri hanya sesi itu. “Log out dari semua perangkat” harus mengakhiri semuanya, termasuk perangkat saat ini, dan memaksa tautan magic baru di mana pun.

Di antara aksi-aksi itu, tentukan apa yang terjadi saat perangkat hilang atau dipakai bersama. Default paling aman: logout menghanguskan semua sesi yang ada dan semua magic link yang belum dipakai. Pengguna tidak perlu detail rumit; mereka hanya butuh jaminan bahwa akses lama hilang.

Berikut set perilaku sederhana yang jarang mengejutkan pengguna:

• Login dengan magic link membuat sesi baru
• Setiap sesi punya timeout idle (misal, hari) dan umur maksimum (misal, minggu)
• Mengganti email memicu “logout dari semua perangkat”
• “Logout dari semua perangkat” juga membatalkan tautan sign-in yang tertunda

Jika Anda membangun ini di AppMaster, Anda bisa memodelkan sesi di Data Designer, menampilkannya di UI web/mobile sederhana, dan menambahkan aksi satu tombol di Business Process. Pengguna mendapatkan tampilan "sesi aktif" yang familiar tanpa Anda perlu membuat buku teks keamanan.

Ancaman dan edge case: penerusan, email bersama, dan salah ketik

Magic link terasa sederhana, tapi email itu berantakan. Orang meneruskan pesan, berbagi inbox, dan salah ketik alamat. Jika Anda hanya mendesain untuk kasus sempurna, Anda akan berakhir dengan penguncian membingungkan dan permintaan dukungan yang sulit ditangani.

Penerusan adalah kejutan terbesar. Masuk tanpa kata sandi dengan magic link harus mengasumsikan tautan bisa dibuka orang lain, di perangkat lain, beberapa menit atau jam kemudian. Baseline teraman adalah penggunaan sekali pakai plus pesan jelas “tautan ini sudah dipakai”, dengan tombol perintah untuk minta tautan baru. Jika ingin proteksi ekstra, tampilkan langkah konfirmasi ringan setelah klik ketika perangkat baru terdeteksi (misal, “Apakah ini Anda?” plus opsi batal yang segera mencabut sesi).

Inbox bersama butuh keputusan produk, bukan tambal teknis. Jika banyak orang legit membaca email yang sama (seperti support@ atau sales@), magic link secara default menjadi akses bersama. Pertimbangkan meminta langkah tambahan untuk akun tim (misal, undangan ke email personal) atau jelaskan di UI bahwa akses email = akses akun.

Salah ketik menciptakan “akun hantu” dan masalah privasi yang canggung. Hindari membuat akun baru secara diam-diam pada login pertama kecuali produk Anda benar-benar membutuhkannya. Pendekatan yang lebih aman adalah mengonfirmasi niat di dalam aplikasi sebelum onboarding, dan membuat respons email netral (sama apakah akun ada atau tidak).

Alias juga penting. Putuskan bagaimana Anda menangani plus-addressing (nama+tag@) dan alias provider:

• Perlakukan email sebagai string eksak (lebih sederhana, lebih sedikit kejutan)
• Atau normalisasi pola umum (lebih sedikit akun duplikat, tapi risiko menggabungkan pengguna yang tidak mengharapkannya)

Dukungan adalah tempat banyak hal bisa salah cepat. Jangan minta pengguna meneruskan email, menempelkan token, atau membagikan screenshot link. Sebaliknya, tawarkan aksi sederhana di dalam produk seperti “kirim tautan baru”, “keluarkan perangkat lain”, dan “laporkan bukan saya”, sehingga dukungan dapat membantu tanpa menyentuh data sensitif.

Daftar periksa cepat sebelum rilis

Sebelum meluncurkan masuk tanpa kata sandi dengan magic link, putuskan apa yang Anda inginkan terjadi di dunia nyata yang berantakan: pengiriman email lambat, orang mengetuk tautan dua kali, dan pengguna pindah antara ponsel dan laptop.

Mulailah dengan aturan yang mengontrol risiko dan beban dukungan. Jika Anda salah di sini, UI tidak bisa menolong.

• Tetapkan jendela kedaluwarsa yang jelas (sering 10–20 menit), dan tampilkan di email serta layar "Check your email".
• Buat link sekali pakai secara default, dan tentukan apa arti "dipakai" (setelah klik, setelah sesi dibuat, atau setelah buka pertama).
• Tambahkan batas pengiriman ulang dan pacing (misal cooldown singkat), plus pesan ramah yang menjelaskan mengapa mereka tidak bisa spam "kirim lagi".
• Batasi sesi aktif per pengguna bila perlu, dan putuskan apa yang terjadi saat batas tercapai (pertahankan terbaru, pertahankan terlama, atau minta keputusan).
• Tangani banyak klik dan link lama secara konsisten: jika link kedaluwarsa atau sudah dipakai, tampilkan halaman sederhana dengan satu aksi utama (“Kirim tautan baru”).

Selanjutnya, periksa bagian yang dilihat pengguna. Sebagian besar keluhan datang dari email yang tidak jelas dan perilaku mobile yang membingungkan.

• Konten email: nama pengirim mudah dikenali, subject jelas, bahasa sederhana, dan baris singkat “Tidak meminta ini?” yang menjelaskan apa yang harus dilakukan.
• Perilaku mobile: konfirmasi apa yang terjadi jika pengguna membuka email di satu perangkat tapi ingin masuk di perangkat lain, dan apakah Anda mendukung deep link ke aplikasi.
• Klik berulang: jika pengguna mengetuk dua kali, hindari error menakutkan; beri tahu mereka sudah masuk atau tautan tidak lagi valid.
• Manajemen perangkat: sediakan daftar perangkat sederhana, opsi “keluarkan perangkat ini”, dan catatan audit dasar (waktu, perangkat, lokasi bila tersedia).
• Pemulihan: siapkan rencana untuk "Saya tidak bisa akses email saya" (alur dukungan, verifikasi alternatif, atau proses perubahan akun yang aman).

Jika Anda membangun ini di alat seperti AppMaster, petakan setiap item checklist ke layar konkret dan aturan bisnis dalam logika Anda, agar perilaku konsisten di web dan mobile.

Contoh realistis: login perangkat baru, link kedaluwarsa, dan pembersihan

Maya bekerja di dukungan. Senin pagi ia membuka portal pelanggan di laptop baru. Ia memasukkan email kerja dan mengetuk “Send me a sign-in link”. Email tiba dengan magic link yang kedaluwarsa dalam 10 menit.

Ia mengkliknya, browser terbuka, dan ia masuk ke portal. Di belakang layar, tautan diterima sekali, lalu ditandai sebagai dipakai. Portal membuat sesi baru bernama “Maya - Laptop Chrome” dan menjaga dia masuk selama 14 hari kecuali ia keluar.

Nanti hari itu, Maya mencoba login dari ponselnya. Ia menggunakan email yang sama dari pagi dan mengetuk tautan yang sama lagi. Aplikasi menunjukkan pesan jelas: “Tautan itu sudah dipakai. Minta yang baru.” Ia meminta tautan lain, tapi sibuk sejenak. Lima belas menit kemudian ia mengetuknya dan melihat: “Tautan ini kedaluwarsa. Kirim yang baru.” Ia meminta lagi, mengetuk segera, dan sesi ponsel dibuat sebagai “Maya - iPhone Safari.”

Jumat, Maya membantu rekan di laptop bersama kantor. Ia masuk, menyelesaikan tugas, lalu ke “Perangkat” dan mengetuk “Sign out of this device”. Sebelum pergi, ia juga menghapus sesi laptop bersama dari akunnya agar tidak bisa dipakai lagi.

Aturan sederhana yang diikuti aplikasi:

• Link kedaluwarsa cepat (menit), tapi sesi bisa lebih lama (hari)
• Setiap link hanya berfungsi sekali; link yang sudah dipakai atau kedaluwarsa tidak dapat digunakan ulang
• Setiap sign-in membuat sesi perangkat bernama yang bisa ditinjau pengguna
• Pengguna bisa keluar dari satu perangkat, atau mencabut semua sesi jika perlu

Untuk membangun alur ini di AppMaster, mulai dengan modul autentikasi dan aktifkan sign-in email. Simpan sesi di database Anda (user, nama perangkat, waktu dibuat, waktu terakhir dipakai). Gunakan modul messaging untuk mengirim email login, dan business process singkat untuk memvalidasi status token (belum dipakai, belum kedaluwarsa), lalu buat atau cabut sesi. Jika ingin masuk tanpa kata sandi dengan magic link tanpa banyak kode khusus, Anda bisa membuat layar dan logika di editor visual dan mencobanya sekarang.