CodeWriteson Uygulamanız istemcilere(client/consumer) yani müşterilerinize/üyelerinize servis sağlayıcı (provider) olarak hizmet veriyorsa, bu hizmet bir API ise ve token authentication ile çalışıyorsa demek ki istemciye bir token vermeniz gerekecek. Laravel'de HasApiTokens trait'ini kullanan User modeli HasApiTokens::createToken() yöntemi ile kendine ait bir ya da birden fazla token oluşturabiliyor ve kullanabiliyor. İstemciye direkt kendiniz bu token'ı oluşturup verebilirsiniz, istemci de direkt kullanabilir. Bir controller aracılığıyla bu token'ı baştan oluşturma işlevini de sisteminize ekleyebilirsiniz böylece istemci de istediğinde token'ını (süresi dolduğu içi, güvenlik sebebiyle ya da kaybettiği için) kendisi yenileyebilir. Buraya kadar hiçbir sorun yok ama bu işlemi her istemci sizin sisteminize göre yapmak zorunda uygulamasını buna göre dizayn etmek zorunda. İşte burada diyorsunuz ki keşke bu token oluşturma, yenileme vs gibi işlemlerin bir standardı olsa, bir protokolü olsa da istemciler direkt entegre olabilse, authentication akışını tamamen kendileri yönetebilse. Aynı şekilde siz de istemci olduğunuzda servis sağlayıcının böyle bir özelliği olmasını istersiniz. Mesela 3 farklı servise de aynı protokol ile bağlandığınızı düşünsenize, ne güzel olurdu, her biri için ayrı ayrı token alma/yenileme akışı yazmanıza gerek kalmazdı. İşte bahsettiğim sistem aslında var: OAuth.
Passport kullandığınızda uygulamanıza OAuth uygulamış oluyorsunuz ve OAuth kullanan hali hazırdaki istemciler herhangi bir değişiklik yapmadan sizden direkt token alabiliyorlar, mevcut token'larını tekrar oluşturabiliyorlar ya da yenileyebiliyorlar. Bunlar için gerekli rotalar hazır geliyor. Eğer bu sistemin size daha uygun olacağını düşünüyorsanız Passport kullanabilirsiniz ama Passport ile Sanctum arasındaki asıl fark bu değil. Sanctum da token authentication ama Sanctum önce token için cookie'ye sonra headers içine bakıyor. O yüzden Sanctum ile hem session auth hem de token auth birlikte kullanabiliyorsunuz. Cookie içinde token araması ise size aynı domain altında çalışan bir SPA uygulamada klasik session auth özelliklerini kullanmanızı sağlıyor. Frontend login isteği attığında size bir token dönmüyor, tamam giriş yaptı deyip session ve cookie oluşturuyor, bir iki küçük ayar ile axios her istekte cookie içindeki token'ı isteğe otomatik ekliyor ve böylece SPA içinde klasik auth ile işlem yapmış gibi oluyorsunuz. Token al, kaydet vs ile uğraşmıyorsunuz.
Bu durumda şu sonuç çıkıyor:
- Aynı domain altında hem backend hem de SPA frontend varsa (biri ya da hepsi subdomain olabilir, sonuçta aynı ana domain) ve frontend tarafında token auth ile uğraşmak istemiyorsanız Sanctum kullanın.
- Benim OAuth protokolüne ihtiyacım yok, benim sadece mobil uygulamam var ya da SPA frontend ayrı bir domainde diyorsanız Sanctum kullanın.
- Hem SPA hem de mobile var bende, mobile rotalarım routes/api.php içinde, SPA rotalarım ise routes/web.php içinde. Mobil bir token ile bağlansın yeterli diyorsanız Sanctum kullanın.
- Benim uygulamam bir provider gibi çalışıyor (Paraşüt, Iyzico vs. gibi) ve ben sadece kullanılara token vermek istiyorum, bir arayüz var orada kendileri oluşturabiliyor, alıp kullansınlar istiyorum diyorsanız Sanctum kullanın.
- Ben OAuth protokolü nedir biliyorum ve şirketimiz büyük istemcilerle çalışıyor ve bunların kullandıkları uygulamalar genellikle OAuth protokolü ile çalışacak şekilde dizayn edilmiş. Biz onlara client_id ve client_secret vereceğiz, token alma güncelleme işlemlerini bizden bağımsız olarak kendileri yapacak ve zaten bizim frontend de session auth kullanmaya uygun değil diyorsanız Passport kullanın.
- Hani bu Facebook'da Google'da oluyor ya uygulamaya izin ver olayı. O da OAuth, öyle bir şey planlıyorsanız Passport kullanmak zorundasınız.
Peki ben Passport kullanarak Sanctum gibi SPA frontend ile session auth kullanabilir miyim?
Kullanamazsınız. Kullanmak için bir şeyler yazmanız lazım ki bu da Sanctum'u yazıyor olmanız demek.
Passport kullanarak Sanctum gibi sadece token oluşturup istemciye verebilir miyim?
Evet verebilirsiniz. https://laravel.com/docs/8.x/passport#personal-access-tokens
Sanctum ve Passport birlike kullanabilir miyim?
Bir iki hack ile belki kullanabilirsiniz. Bu, benim dilimde kullanmayın demektir.
Sanctum ve Passport olayını anladım ama bir de JWT var bu ne?
JWT de bir token ama içerisinde giriş yapan kullanıcının bilgileri encode edilmiş olarak duruyor. Sanctum ve Passport token'ları bildiğiniz rastgele karışık ifade. O yüzden JWT token ile istek gelince veritabanında sorgu yapılmaz, direkt işlem yapılır, ne zaman kullanıcıya ihtiyacınız olur o zaman sorgu yaparsınız. Bunun avantajı her istekte kullanıcı sorgusu yapılmamış olması ama dezavantajı ise kullanıcı bilgileri değişti mi token içinde bilgilerin eskiyor olması. Bu durumda hangi bilgiler token içindeki bilgiyi etkiliyorsa token'ın öldürülmesi gerekiyor. Bu da bayağı bir akış kontrolü yazmak. En basitinden sistemden kullanıcı gitse bile token hala çalışır çünkü authentication encoded gelen ifadenin decode edilmesi ile çalışıyor, kullanıcı var mı yok mu kontrol etmiyorsunuz. Onu kontrol ederseniz zaten düz token'dan farkı kalmıyor. JWT genellikle istenmeyen mantıksal hatalara sebep olduğu için az istek alan işlerde (benim az dediğim sizin için çok olabilir) tercih edilmiyor ama milyonlarca isteğin geldiği sistemlerde bu tarz bir şeyler de lazım. Elbette milyonlarda istek geliyor olması sisteminizin JWT'ye uygun olduğu anlamına gelmez. Bana göre JWT sadece birincil servisler arasında, yani sizin iki uygulamanız arasında kullanılmalı, 2. 3. parti istemcilerin işlerinde kullanılmamalı.