Parolasız Laravel Kimlik Doğrulama: Demo Yapması Kolay, İyi Yönetmek Zor

Şifresiz kimlik doğrulama, gerçek bir Laravel uygulamasında çalıştırmaya çalıştığınızda basit gibi görünse de aslında oldukça karmaşık bir süreçtir. Kullanıcı arayüzü daha basit hale gelir, ancak güvenlik modeli değişmez. Şifre alanını kaldırıyorsunuz ama hala kimliği doğrulamanız, tekrar oynama önlemleri almanız, düşman e-posta altyapısı ile başa çıkmanız ve cihazlar arasında kabul edilebilir bir kullanıcı deneyimi (UX) sunmanız gerekiyor.

Bu nedenle, çoğu sihirli bağlantı örneği prototipler için uygun olsa da üretim uygulamaları için eksiktir. Bu örnekler genellikle yalnızca imzalı bir URL oluşturmaya ve bunun açıldığında Auth::login() işlemini çağırmaya odaklanır. Bu kolay kısım. Zor kısım, tıklamadan sonraki her şeydir.

Tavsiyem şudur: Laravel’de şifresiz kimlik doğrulama özelliğini “özel oturum açma bağlantısı” olarak uygulamayın. Bunun yerine, açık bir durum, tek kullanımlık tüketim, adım artışı tetikleri ve destek görünürlüğü ile kısa ömürlü bir kimlik doğrulama akışı olarak uygulayın. Bu katmanları atlayarak göndereceğiniz şey, e-postada bir taşıyıcı token ve gerisinin kendi kendine sonuçlanmasını ummak olacaktır.

İlk tehdit genellikle kullanıcının e-posta güvenlik yapısıdır

Birçok sihirli bağlantı yazısı, bağlantıya yapılan ilk isteğin, gelen kutusunun sahibi olan insandan geldiğini varsayıyor. Üretimde bu varsayım hızla bozulur.

Kurumsal e-posta sistemleri, güvenli e-posta geçitleri, antivirüs ürünleri, tarayıcı önizleme servisleri ve mobil e-posta istemcileri genellikle bağlantıları önceden almakta ya da önizlemeye göre yönlendirmektedir. Laravel yönlendirmeniz ilk GET isteğinde oturumu açıyorsa, bu otomatik oyunculardan biri, kullanıcı e-postayı bile görmeden kimlik bilgilerini tüketebilir.

Bu, kullanıcılara garip gelen bir hata durumu oluşturur. E-postayı bir dakika sonra tıkladıklarında “bağlantı süresi dolmuş” veya “token zaten kullanıldı” mesajını görürler. Onların perspektifinden bakıldığında, kimlik doğrulamanız bozulmuş gibi görünmektedir. Oysaki sizin açınızdan olay bir kez çalıştı ama kullanıcılar için değil.

Bu nedenle, sihrli bağlantı oturumu, ciddi bir uygulamada tüketilmeyecek şekilde tasarlanmalıdır.

E-posta bağlantılarını bir akışı devam ettirmek için kullanın, bitirmek için değil

Daha iyi bir desen oldukça basittir:

1. Kullanıcı şifresiz oturum açma talep eder.
2. Veritabanında bir oturum açma girişim kaydı oluşturursunuz.
3. Bu girişimi tanımlayan imzalı bir URL’yi e-posta ile gönderirsiniz.
4. GET isteği bağlantıyı doğrular ve bir onay sayfası render eder.
5. Kasıtlı bir POST isteği, girişimi tüketir ve oturumu oluşturur.

Bu ek tur, “tıklanabilir e-posta token” ile “tarayıcı tarayıcıdan koruyan kimlik doğrulama akışı” arasındaki ayrımı yaratır. Otomatik tarayıcılar GET istekleri ile oldukça iyi olurken, aynı oturum bağlamında bir CSRF korumalı tarayıcı formunu tamamlamakta çok daha kötü durumda kalırlar.

Laravel’deki minimum rota yapısı şöyle görünebilir:

Route::middleware('guest')->group(function () {
            Route::post('/login/passwordless', RequestMagicLinkController::class)
                ->middleware('throttle:5,1')
                ->name('passwordless.request');

            Route::get('/login/passwordless/{attempt}', ShowMagicLinkController::class)
                ->middleware('signed')
                ->name('passwordless.show');

            Route::post('/login/passwordless/{attempt}', ConsumeMagicLinkController::class)
                ->middleware(['signed', 'throttle:6,1'])
                ->name('passwordless.consume');
        });

Önemli tasarım seçimi, rota isimlendirmesi değil, endişelerin ayrılmasıdır.

• E-posta bağlantısı, kullanıcının gelen kutusuna ulaştığını kanıtlar.
• Onay POST’u, bir tarayıcı oturumunun kasıtlı olarak akışı tamamladığını kanıtlar.
• Uygulamanız, bunun tam erişim ya da yalnızca geçici erişim için yeterli olup olmadığını belirler.

İmzalı URL’ler faydalıdır, ancak yetersizdir

Laravel’in imzalı URL desteği kesinlikle burada kullanılmaya değerdir. Bu, sorgu bütünlüğünü ve son kullanma tarihini korur. Ancak, tam sorunu çözmez.

Bir imzalı URL, temel oturum açma girişimini tek kullanımlık hale getirmez. Bir bağlantının bir tarayıcı tarafından tüketilip tüketilmediğini söylemez. İletilen bir e-postanın, süre içinde yeniden kullanılmasını engellemez. Yeni bir cihazın güvenilir olup olmayacağını belirlemez.

Bu ayrım önemlidir çünkü ekipler sıklıkla “kriptografik olarak imzalı” ile “üretime hazır” arasındaki farkı karıştırır. Bunlar farklı iddialardır.

Temel nesne bağlantı değil, giriş denemesidir

Şifresiz kimlik doğrulamanızın üretimde hayatta kalmasını istiyorsanız, akış için birinci sınıf bir kalıcılık modeli gerekir. Bağlantı, bir giriş denemesi kaydına işaret etmelidir, URL içinde tüm güvenlik hikayesini taşımalıdır.

Makul bir şema genellikle şunları içerir:

• id
• user_id
• token_hash
• expires_at
• consumed_at
• requested_ip
• requested_user_agent
• requested_at
• redirect_to
• device_label
• risk_flags veya eşdeğer JSON meta verisi

Token kendisi rastgele, kısa ömürlü ve yalnızca bir hash olarak saklanmalıdır. Onu sıfırlama token’ları gibi ele alın: ham gizlilik, yalnızca e-posta göndermek için yeterince uzun süre vardır.

Token’i hashleyin ve URL’i sıkıcı tutun

Hassas bir token formatına ihtiyacınız yok. Ancak tahmin edilemez bir token’a ihtiyacınız var.

use Illuminate\Support\Str;

        $plainToken = Str::random(64);

        $attempt = MagicLoginAttempt::create([
            'user_id' => $user->id,
            'token_hash' => hash(, $plainToken),
            'expires_at' => now()->addMinutes(15),
            'requested_ip' => request()->ip(),
            'requested_user_agent' => substr((string) request()->userAgent(), 0, 1000),
            'redirect_to' => ,
        ]);

        $url = URL::temporarySignedRoute(
            ,
            $attempt->expires_at,
            [
                => $attempt->id,
                => $plainToken,
            ]
        );

Yeter. Kullanıcı verilerini, cihaz ipuçlarını veya güven tanımalarını token’ın içine kodlama isteğine karşı koyun. Durumu veritabanında saklayın, bunu geri alabilir, inceleyebilir ve bu konuyla ilgili düşünme olanağı sağlar.

Tek aktif deneme mi yoksa birden fazla mı?

Bu, açıkça yapılması gereken bir mimari seçimdir.

Eğer bir kullanıcı on dakika içinde beş bağlantı talep ederse ne olmalı?

Kolay cevap, hepsinin süresi dolana kadar izin vermektir. Ancak operasyonel olarak daha temiz cevap, genellikle yeni birinin yayınlandığında eski bekleyen girişimleri geçersiz kılmaktır; bu, kafa karışıklığını azaltır ve destek ekibine daha net bir hikaye sunar: “yalnızca en son e-posta çalışır.”

B2B uygulamalarında şunlardan birini tercih ederim:

• Standart oturum açma için kullanıcı başına tek bir aktif deneme.
• Paralel akışlar için kapsamlı aktif denemeler (örneğin, web oturumu ve ayrıcalıklı işlem onayları için).

Şunu önlemek; örtüşen geçerlilik süreleri olan token’lar sunmak. Bu, istemediğiniz destek biletlerini üretmekte başa çıkmanızı zorlaştırır.

Tekrar oynamaya karşı koruma, sistemleri ayıran kısım

Bir sihirli bağlantı, bir taşıyıcı kimlik belgesidir. Yani, izin verilen zaman dilimi içinde ilk sunumunu yapan kimse, erişim elde edebilir; eğer tüketim adımını dikkatlice tasarlamazsanız.

En az düzey basittir:

• token tek kullanımlık olmalıdır
• token tüketimi atomik olmalıdır
• başarılı oturum açma, oturumu döndürmelidir
• ikinci kullanım, temiz bir şekilde başarısız olmalı, tahmin edilebilir bir yarış yürütmemelidir
• eski girişimler belirsiz bir şekilde “bir tür geçerli” kalmamalıdır

Atomik durum geçişiyle tüketin

Kendi yapılan şifresiz kimlik doğrulama süreçlerinde en yaygın hata, geçerli bir girişimi yüklemek, kontrol etmek ve sonra güncelleyerek iki yakından gelen isteğin başarılı olmasına izin vermektir.

Doğru zihinsel model “doğrula sonra oturumu aç” değil, “bir kerelik durum geçişini kazanın, sonra oturumu açın”dır.

public function __invoke(Request $request, string $attemptId)
        {
            $attempt = MagicLoginAttempt::query()
                ->whereKey($attemptId)
                ->where(, , now())
                ->firstOrFail();

            abort_unless(
                hash_equals($attempt->token_hash, hash(, (string) $request->string())),
                403
            );

            $updated = MagicLoginAttempt::query()
                ->whereKey($attempt->id)
                ->whereNull()
                ->where(, , now())
                ->update([
                    => now(),
                    => $request->ip(),
                    => substr((string) $request->userAgent(), 0, 1000),
                ]);

            abort_if($updated !== 1, 409, );

            Auth::loginUsingId($attempt->user_id, remember: false);
            $request->session()->regenerate();

            return app(PostMagicLoginRedirector::class)->handle($request, $attempt);
        }

Güncelleme çağrısı gerçekteki işi yapıyor. Yalnızca bir istek, girişimi beklemeden kullanılmış durumdan geçirebilir.

IP ve kullanıcı aracı ile aşırı bağlanmayın

Pek çok ekip, tekrar oynama riski görünce akışı IP adresine veya tarayıcı parmak izine bağlamaya çalışır. Bu, güçlü gibi görünse de gerçek kullanıcılar bunu mobil ağlardan, gizlilik koruyucu tarayıcılardan, VPN’lerden veya bağlantıyı farklı tarayıcı örneklerine yönlendiren e-posta uygulamalarından kullanınca sıkıntı yaratır.

Tavsiyem, bu sinyalleri risk göstergeleri olarak değerlendirmektir, kesin gerçeklik olarak değil.

Bu sinyalleri iyi kullanmanın yolları:

• tüketim isteği yapılan akış isteğinden önemli ölçüde farklıysa ek onay almak
• oluşan oturum için güveni düşürmek
• denetim meta verisi eklemek
• hassas hesaplar için artan kimlik doğrulama tetiklemek

Kötü kullanım örnekleri:

• normal cihaz geçişlerine zor bloklar koymak
• talep ve tıklama arasında IP değiştiği için oturum açma talebini kalıcı olarak reddetmek
• tarayıcı parmak izlerinin kimlik kanıtı kadar kararlı olduğunu varsaymak

Şifresiz kimlik doğrulama, şifreleri kırılgan çevresel kontrol mekanizmaları ile değiştirmekten daha kötü olur.

Son kullanma tarihi, çevresel rahatlığı değil, saldırı penceresini yansıtmalıdır

On beş dakika, yaygın bir varsayılan süre olsa da, bunun makul göründüğü birçok uygulama için uygundur. Ancak, süresi dolmuş bir email token’ı riskine urun oturum açmanın sıklığıyla ilişkili bir son kullanma süresi seçin, yalnızca kılavuzlarda görüldüğü için değil.

Düşük ayrıcalıklı bir ürün oturumu genellikle kısa ömürlü bir e-posta token’ını tolere edebilir. Ancak bir faturalama onayı veya yönetici erişim akışı genellikle daha dar bir pencere ve daha güçlü takip kontrolleri gerektirir.

Doğru soru, “diğer uygulamalar ne tür bir son kullanma süresi kullanıyor?” değil, “bir sızan e-posta bağlantısı süresi dolmadan ne kadar zarara neden olabilir?”dır.

Cihaz güveni ve adım artışı kimlik doğrulama, mimarinin gerçekleştiği yerdir

Pek çok ekip, şifresiz kimlik doğrulamayı tüm kimlik doğrulama yığını için bir değişim olarak düşünür. Bu, herhangi bir anlamlı hesap değerine sahip uygulamalar için yanlış bir kavramdır.

Uygulamada, şifresiz kimlik doğrulama genellikle birincil oturum açma faktörünüz olmalıdır, tüm yetkilendirme modeliniz değil. Kullanıcı gelen kutusu erişimini kanıtlarken, hala yeni cihazlar, riskli oturumlar, ayrıcalıklı işlemler ve kurtarma için bir politikaya ihtiyacınız var.

Bu, birçok Laravel uygulamasının doğaçlama yapmayı bırakması gereken bir noktadır ve Fortify‘nin ikinci faktör katmanını ele almasına izin verilmelidir.

Sihirli bağlantı önce, Fortify sonra

Eğer zaten Laravel Fortify kullanıyorsanız, temiz bir yaklaşım endişeleri ayrı tutmaktır:

• şifresiz akış, temel kimliği oluşturur
• Fortify, gerektiğinde TOTP veya diğer ikinci faktör zorluklarını ele alır
• güvenilir cihaz durumu, zorluğun atlanıp atlanamayacağını etkiler
• hassas eylemler için yetkilendirme geçitleri, mevcut güven düzeyini kontrol eder

Bu tasarım önemlidir çünkü sıra dışı veya karmaşık güvenlik kararlarını sihirli bağlantı denetleyicisinde yığmaktan kaçınmanızı sağlar.

Sihirli bağlantı akışı yalnızca bir soruya yanıt vermelidir: bu kullanıcı geçerli bir e-posta temelli oturum açma girişimi mi tamamladı?

Fortify ve güvenlik politikanız, sonraki soru için yanıt vermelidir: bu oturum, neyi yapmaya çalışıyorlarsa yeterince sağlam mı?

Geçici oturumlar değerlidir

Handover’ı entegre etmenin temiz bir yolu, token tüketimi başarılı olduktan sonra gerçek bir kimlik doğrulama oturumu oluşturmak ancak bunu geçici olarak işaretlemektir.

Örneğin, Auth::loginUsingId() sonrasında oturum meta verisini şöyle ayarlayabilirsiniz:

• auth_method=passwordless_email
• auth_assurance=low
• step_up_required=true
• trusted_device=false

Ardından, middleware veya yeniden yönlendirme katmanı, kullanıcının direkt olarak kontrol paneline, Fortify zorluğuna ya da sınırlı erişim ekranına yönlendirilmesi gerekip gerekmediğini belirleyebilir.

Bu, kimlik doğrulamayı yalnızca iki durumlu bir “giriş yapıldı mı, yapılmadı mı” durumundan çok daha fazla kontrol etmenizi sağlar.

Güvenilir cihaz sunucu durumu olarak geri alınabilir

Güvenilir cihazın tembel bir versiyonu, “bir daha sorma” diyen kalıcı bir çerezdir. Bu, elverişli ve zayıftır.

Daha iyi bir versiyon:

• sunucu tarafında hashlenmiş bir rastgele cihaz token’ı
• bir expires_at zamanı
• kullanıcının anlayabileceği bir etiket, örneğin “MacBook Pro, Chrome”
• bir last_seen_at zamanı
• kullanıcı ayarlarından tümü veya bir cihazı geri alma imkânı

Bu, sürekli erişim için pürüzsüz bir tekrar giriş sağlamanıza imkan tanır, ancak güveni geri alınabilir durumda tutabilir.

Poliçeniz ayrıca çoğu ekibin düşündüğünden daha dar olmalıdır. Güvenilir cihaz genellikle rutin erişimlerde pürüzleri azaltmalıdır. Ancak hassas işlemleri daima sessizce yetkilendirmemelidir.

Pratik bir politika şöyle görünebilir:

• olağan ürün erişimi: şifresiz giriş ile izin verin
• yeni bir cihaz üzerindeki yönetim hesabı: Fortify zorluğu isteyin
• faturalama değişikliği veya API anahtarı oluşturma: güvenilir cihaz bakımından son zamanlardaki bir zorluk isteyin
• takım sahipliği transferi: her zaman yeni bir zorluk isteyin

Bu, “şifresiz giriş” ile “şifresiz güvenlik tiyatrosu” arasındaki farktır.

Destek ve gözlemlenebilirlik, sistemin başarıyla lansmanı belirler

Şifresiz kimlik doğrulama ilk defa başarısız olduğunda, destek, tasarımınız hakkında geliştiricilerden daha fazla şey öğrenir.

Kullanıcılar, “token tüketim semantiklerinin önceden tahmin edilmiş yarışmalar için savunmasız olduğunu düşünüyorum” diye bilet açmaz. Genellikle şu şekildedir:

• “bağlantı çalışmadı”
• “giriş yapmaktan çıktım ve yeni e-posta da başarısız oldu”
• “artık kullanılmış diyor”
• “yeni bir dizüstü bilgisayardayım ve şimdi takıldım”

Ekibiniz bu akışı hızlı bir şekilde yeniden oluşturamazsa, manuel çözümler bulmaya başlayacaklardır. Bu, güvensiz operasyonel alışkanlıkların doğduğu yerdir.

Yaşam döngüsü üzerinde olayları kaydedin

En azından şu olaylar için yapılandırılmış olaylar yayınlayın:

• oturum açma girişimi oluşturuldu
• e-posta gönderim denemesi yapıldı
• e-posta gönderimi başarılı ya da başarısız oldu
• inme rotası görüntülendi
• tüketim isteği yapıldı
• tüketim reddedildi
• oturum oluşturuldu
• Fortify zorluğu başlatıldı
• zorluk tamamlandı veya başarısız oldu
• güvenilir cihaz verildi, yenilendi veya geri alındı

Olaylar, pek süslü olmak zorunda değil ama ilişkilendirilmiş olmalıdır.

MagicLinkRequested::dispatch($attempt->id, $user->id);
        MagicLinkEmailSent::dispatch($attempt->id, $user->id);
        MagicLinkViewed::dispatch($attempt->id, request()->ip());
        MagicLinkConsumeRejected::dispatch($attempt->id, );
        MagicLinkConsumed::dispatch($attempt->id, $user->id);
        StepUpChallengeRequired::dispatch($user->id, session()->getId());
        TrustedDeviceGranted::dispatch($user->id, $device->id);

Önemli olan, bir destek mühendisi veya geliştiricinin tahmin etmeden bir zaman dilimini inceleyebilmesi ve basit sorulara yanıt verebilmesidir.

Sadece kötü niyetli olmayan yaygın hata senaryolarına göre tasarlayın

En sık karşılaşılan problemler genellikle operasyonel olup, zararlı değildir:

• kullanıcı birkaç e-postada en eski olanı tıkladı
• kurumsal e-posta geçidi bağlantıyı önceden aldı
• kullanıcı, e-postayı mobilde açtı ama masaüstü tarayıcıdan giriş yapacağını bekliyordu
• cihaz değişti ve beklenmedik şekilde adım artışı kimlik doğrulama gerekli oldu
• e-posta teslimat gecikmesi, token süre sınırını aştı

Sisteminizin bu durumlara dair bir görüş sahibi olması gereklidir.

Örneğin, önceden tüketilen bir girişimin, güvenlik tarayıcıları tarafından daha önce görüntülendiğini tespit ederseniz, arayüzünüz “bu oturum açma bağlantısını açmış olabilirsiniz. Yeni bir tanesini talep edin.” şeklinde anlamlı bir şey söyleyebilir. Bu sadece UX’i geliştirmekle kalmaz, gereksiz destek hacmini azaltır.

Kurtarma politikası kimlik doğrulama tasarımının bir parçasıdır

Şifresiz kimlik doğrulama, kullanıcının e-posta erişimi bozulduğunda veya kaybolduğunda en çok başarısız olur. Kullanıcının e-postası mevcut değilse ve güvenilir cihazı da kaybedilmişse, ne olmalı?

Ona yapmanız gereken yanıtı almanız gerekiyor, lansmandan önce.

İyi bir kurtarma tasarımı genellikle şunları içerir:

• oran zekalı operatör politikası, destek biriminin neleri yapıp yapamayacağı
• denetim kayıtlı cihaz iptali ve oturum iptal edilecektir
• hesap kurtarma öncesi müşteri kimlik bilgileri
• giriş akışını yeniden gönderme ile güvenlik kontrollerini aşıp geçme arasında açık ayrım

Ön hat desteğinin iki faktörlü ayarları kaldırabilmesine veya kullanıcıları taklit edebilmesine izin vermekten kaçının. Bu, yardım masanızı kimlik doğrulama yığınındaki en zayıf nokta haline getirir.

Bugün bir Laravel uygulamasında gerçekten göndereceğim

Eğer bugün gerçek bir Laravel ürününde şifreleri değiştirecek olsaydım, tasarımı kasıtlı olarak sıkıcı tutardım.

Uygulama şu özelliklere sahip olurdu:

• e-posta bağlantıları bir akışı GET ile başlatır; kullanıcıları doğrudan giriş yapmaz.
• giriş denemeleri sunucu tarafında hashlenmiş token’lar ve açık yaşam döngüsü alanları ile saklanır.
• yalnızca en son standart oturum açma denemesi geçerli kalır, aksi açık bir sebep olmadıkça.
• token tüketimi POST ile CSRF koruma ve atomik tek kullanımlık güncellemelerle yapılır.
• başarılı tüketim, hemen oturumu yeniden oluşturur.
• oluşan oturum bir güven düzeyini taşır, yalnızca evet/hayır oturum durumunu değil.
• Fortify, kişisel zorluklarla birlikte adım artırır, dağıldı denetimlerde değil.
• güvenilir cihaz kayıtları geri alınabilir, sona eren ve sunucu durumu ile desteklenir.
• hassas işlemler, yalnızca herhangi bir kimlik doğrulama oturumu gerektirmekten çok daha yakın güvenirlik gerektirir.
• destek, asla ham token’ları görmeden dolu bir olay izini inceleyebilir.

Bu, “şifresiz”e en kısa yol değildir. Ancak, güvendiğim en kısa yoludur.

Sihirli bağlantılar değerlidir. Şifre sıfırlama zorluklarını azaltır, kimlik bilgisi doldurma saldırısına maruz kalmayı azaltır ve genellikle ilk giriş deneyimini iyileştirir. Bunlar gerçek kazanımlardır. Ancak bunlar, çevreleyen sistem şifre akışından daha sağlam değilse yalnızca kazanımlardır.

Karar kuralı basittir: eğer Laravel şifresiz kimlik doğrulamanız bir tarayıcı tarafından tüketilip, yeniden oynatılabiliyorsa, yanlış cihazda ömür boyu güvenilir olsa veya yalnızca tahmin yoluyla hata ayıklanabilecek olsaydı, tasarımı tamamlamadınız. Sorun sihirli bağlantı değil, operasyonel modeldir.

Tam yazıyı QCode’da okuyun: https://qcode.in/passwordless-laravel-auth-magic-links-are-not-the-hard-part/