Ama, Ama, Ama yetki HaaRrRrRrRrRd

Hayır değil. Sıkıcı, bürokratik, çözülmüş bir sorun... ama genel bir ifadeyle zor demeyin.

"PHP'de şifreleri karıştırmak için MD5 kullandım" yaşındayım. Elbette, 2012'de bile korkunç bir fikirdi. Ama o zamanlar, kimlik doğrulamayı "zor" olarak düşündüğümü hatırlamıyorum. Kendi başına oldukça basit bir çileydi - bir e-posta veya kullanıcı adı alın, bir şifre alın, onu karıştırın (MD5 ile, "Tanrı'nın istediği gibi") ve özellikle güvenlik konusunda bilinçliyseniz, şifreyi [ tuzlayın ]. Bunların hepsini bir yerde, genellikle bir veritabanında saklayın. Ta-da, kayıt işlemi tamam.

Günümüzde anlatı değişti. "Auth zordur" ifadesi, HackerNews veya Reddit'e tıklama mesafesinde olan sürekli mevcut bir anlatı gibi geliyor. Ama gerçekten öyle mi? Bence, gerçek şu ki, auth'u oluşturmak zor değil - herkes öğrenebilir (ve bu işte çalışan herkes temellerini öğrenmeli). Asıl zorluk ekstralarda yatıyor: MFA, kullanıcı yönetimi, parola sıfırlamaları, yüzlerce OAuth sağlayıcısının her biri ve farklı sağlayıcılardan hesap birleştirmeleri. Binlerce kesikle ölüm. Auth çözülmüş bir sorun olduğundan, tekerleği yeniden icat etmek zamanınızı en iyi şekilde kullanmak değildir. Ama bu, genel bir ifade olarak "auth zordur" ifadesinin doğru veya hatta doğruya yakın olduğu anlamına gelmez. Deney yapmalı, temelleri anlamalı ve oradan inşa etmelisiniz. Karmaşıklık, yalnızca yarattığınız şeyin ölçeğiyle (veya potansiyel ölçeğiyle) büyür.

Peki, auth gerçekten ne kadar zor olabilir? Hadi inceleyelim.

Eskiden...

PHP ve md5 hikayesini bıraktığım yerden devam ettirirsek, bir oturum açma işlevi oluşturmak benzer adımları izledi; Bir e-posta ve parola alın, e-postanın depolama alanınızda olup olmadığını kontrol edin, parolayı e-posta için depolanan tuzla birlikte hashleyin, elde edilen hash değerini veritabanında depolanan değerle karşılaştırın ve her şey yolunda giderse setcookie aracılığıyla bir çerez ayarlayın (burada hala PHP topraklarındayız - genel mantığın diğer ekosistemlerde de çok farklı olduğunu söyleyemeyiz).

Çıkış yapmak daha da basitti - sunucudaki çerezi geçersiz kılmanız yeterli ve işiniz bitti. Sunucu bir sonraki istekte bir çerez görmezse, oturum açmamış olursunuz. Bu nedenle, kimlik doğrulamalı rotalar yapmak da genel olarak basit bir çileydi. İzinler söz konusu olduğunda işler çetrefilli hale gelebiliyordu, ancak çoğu zaman, oluşturmam gereken uygulamalarda yalnızca yöneticiler ve kullanıcılar vardı. Bu, uygulamanız için sahip olduğunuz rol sayısını genişletmeniz gerektiğinde kullanıcı kaydıyla birlikte veya bir izin tablosunda saklayabileceğiniz bir şeydi.

Tam açıklama: SuperTokens için çalışıyorum. Ancak bu parça, kimlik doğrulamanın ne kadar zor olduğuna dair genel bir ifade olarak her yerde bulunan bir anlatıya duyduğum kişisel hayal kırıklığından doğdu. Başka bir deyişle, "size bir şey satmaya" çalışmıyorum. İstediğinizi kullanın.

Kendin yap - "modern" bir yaklaşım

E-posta/şifre ve Sosyal kimlik doğrulama

Bugün bulunduğumuz noktaya gelmek için, en baştan başlayacağız... Şaşırtıcı, biliyorum. Muhtemelen bu bileşenlerin bir e-posta/şifre + sosyal oturum açma PoC'si oluşturmak için yeterli olduğunu kabul edebiliriz:

1. Kayıt, oturum açma, oturum kapatma gibi rotaları yöneten bir sunucu.
2. Kullanıcı kayıtlarını tutmak için bir tür depolama (bellekteki bir dizi de işe yarar)
3. Görünümler - giriş, kayıt ve kimliği doğrulanmış "pano" ekranları.
4. Sosyal kimlik doğrulama için işleyiciler

Tekerlekleri yeniden icat etmeyeceğimiz için Express ve Passport'a geçiyoruz, tam olarak 150 satır çok, çok sıkıcı ve tekrarlayan koda ulaşıyoruz: https://github.com/supertokens/auth-express/blob/master/index.mjs . Bir sonraki bölüm kodda neler olup bittiğinin yüzeysel açıklaması olacak, bu yüzden kavramlara aşinaysanız atlayabilirsiniz . Express uygulaması zaten bir PoC'dir.

Hızlıca inceleyelim:

Ekranda bir şeyler oluşturma

Benim bakış açıma göre, buna yaklaşmanın iki yolu var - işlemeyle başlayıp kimlik doğrulama yoluna geçmek veya tam tersi. Çoğunlukla şans eseri, FE'ye ağırlık veren bir pleb oldum (merak ediyorsanız hala SQL yapabiliyorum), bu yüzden "ekranda işleme" yaklaşımıyla başlayacağım.

Bu bir PoC olduğundan, React-fantezisi yapmayacağız. Ejs'li sade eski SSR yeterli olacaktır: https://github.com/supertokens/auth-express/tree/master/views

Rotalar ekleme

Passport.js'deki bazı örneklere dayanarak, ancak daha da basitleştirerek, aşağıdakilere ihtiyacımız var:

1. Bazı bağımlılıklar: npm i passport passport-local express-session . Her birine kısaca göz atalım:

   1. Passport.js - Express ve Node için OG kimlik doğrulama ara yazılımı.
   2. passport-local - Passport için bir kimlik doğrulama stratejisi; Belirli bir kimlik doğrulama yöntemi için kimlik doğrulama sürecini işleyen bir modüldeki kimlik doğrulama stratejisi - bu durumda, kullanıcı adı (e-posta) ve parola kullanılarak yerel bir oturum açma.
   3. express-session - oturum verilerini yöneten ve HTTP istekleri arasında kullanıcı oturumlarını depolamanıza ve sürdürmenize olanak tanıyan bir ara yazılım. Her istemciye benzersiz bir oturum kimliği atayarak çalışır, bu kimlik istemci tarafında bir çerezde depolanır ve sunucuda oturum verilerini almak için kullanılır.

2. Kullanıcılarımızı depolayabileceğimiz bir yer (yukarıdaki bağlantıdaki örnekte bellek içi dizi kullanılmıştır): https://github.com/supertokens/auth-express/blob/master/index.mjs#L13

3. Kullanıcı araması için gelen istekleri işlemek üzere pasaport örneğimiz ve LocalStrategy örneğimiz için yapılandırma: https://github.com/supertokens/auth-express/blob/master/index.mjs#L18

4. Pasaportu ( https://github.com/supertokens/auth-express/blob/master/index.mjs#L60 ) ve ekspres oturumu ( https://github.com/supertokens/auth-express/blob/master/index.mjs#L69 ) başlatın.

Ayrıntılı, elbette. Zor mu? Sanmıyorum, en azından bir oyuncak olarak uygulama anlamında değil. Ama bir süre önce e-posta/şifre kombinasyonlarını kullanmayı geçtik. Sahip olduğumuz şeyin üstüne bir sosyal sağlayıcı eklemenin ne kadar zor olduğunu inceleyelim.

Örnek bir sağlayıcı için GitHub'ı seçmemin basit bir nedeni var: Eğer tam olarak takip etmeye karar verirseniz, başlayabileceğiniz en kolay sağlayıcılardan biri (sana bakıyorum Google).

Eğer tüm adımları takip etmeye karar verirseniz, GitHub anahtarlarını nasıl edineceğinizi anlatan bir bağlantı burada: https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/creating-an-oauth-app Bu arada, endişeleniyorsanız, depodaki anahtarlar geçerli değil ;)

GitHub OAuth2'yi PoC'umuza entegre ediyoruz

Öncelikle bir bağımlılığa daha ihtiyacımız var, npm i passport-github2 . passport-github2, Passport için bir kimlik doğrulama stratejisidir ve GitHub'ın OAuth2 API'siyle entegre olmamızı sağlar.

Bazı işleyiciler ( https://github.com/supertokens/auth-express/blob/master/index.mjs#L122-L133 ) ve yapılandırma ( https://github.com/supertokens/auth-express/blob/master/index.mjs#L29-L45 ) daha sonra, işte bu kadar. Karmaşık mı? Muhtemelen değil. Bürokratik mi? Elbette. Sıkıcı mı? Kesinlikle. Özellikle bunu tekrar tekrar yapıyorsanız. Bu çözülmüş bir sorundur; tekerleği yeniden icat etmek, belirlediğimiz gibi, çoğu zaman zamanınızı en iyi şekilde kullanma şekli değildir.

Büyük fikir

Artık Auth'un inşasının zor olmadığı konusunda muhtemelen hemfikir olabiliriz. Dolayısıyla, bu sadece JWT'lerin mistik dilini konuşan beyaz sakallı büyücülerin anlayıp uygulayabileceği büyülü bir şey değil.

Hayır, aslında, bir geliştirici olarak, kimlik doğrulamanın nasıl çalıştığına dair çıplak temelleri anlamanız gerektiğini savunurdum. Ve sıklıkla aksini iddia eden bir anlatı görüyorum - "bana güvenin, dostum, bunu sizin için halledebiliriz" gibi bir şey. Ve elbette, çoğunlukla kendi kimlik doğrulamanızı oluşturmanın zaman kaybı olduğu konusunda hemfikirim. Ancak bunu oluşturmak o kadar da zor değil ve kesinlikle mistik bir şey değil. Gerçekten karmaşık hale geldiği yer, kimlik doğrulama ve kullanıcı deneyimiyle ilgili her şey.

Şunu düşünün - yukarıdaki örnekte çalışan bir auth şeyimiz var. Bir nevi. Ama yapamadığı şey şu (makale açılışında da bahsedilmiştir):

• 2FA, Güzel Sanatlar Yüksek Lisansı
• Şifre sıfırlamaları
• Yüzlerce OAuth sağlayıcısının her biri, kendine özgü özellikleriyle
• Kullanıcı yönetimi
• Farklı sağlayıcılardan hesap birleştirmeleri
• Tüm olası uç durumları ve potansiyel güvenlik açıklarını kapatın
• ...ve devam edebilirim

Muhtemelen bunların her birini uygulayabiliriz. Ve kendi başına, her parça basit olarak düşünülebilir. Ama toplanır. Yani, ille de uygulama değil—onu sürdürmek, bundan sorumlu olmak, standartlar, güvenlik ihlalleri vb. konusunda güncel kalmak. Ayrıca, el kaldırma—kaçınız RfC'leri okumayı seviyor? Bir buluşmada olsaydık pek çok el kaldırılmış kişi göreceğimi sanmıyorum.

Benim demek istediğim, auth'un bir bütün olarak ele alındığında kolay olmadığıdır. Elbette, yukarıda yaptığımız gibi bir PoC için kolayca bir şeyler bir araya getirebiliriz. Ancak bu büyülü değil, anlaşılması imkansız değil ve lütfen, lütfen öyle olduğunu söylemeyin. Bence bu düşünce tarzı (ve pazarlama) endüstrinin tamamına zarar veriyor.

O zaman doğal olarak sorulması gereken soru şudur: Ne zaman kendi fikrinizi ortaya koymalısınız?

Oyuncak projesi, bağımsız ve eğitim faaliyetleri

...elbette. Hatta bunu teşvik ederim. Yaparak çok şey öğrenirsiniz, öyleyse neden olmasın? Bağımsız/oyuncak projeniz veya blogunuz önemli bir kullanıcı tabanına veya takipçi kitlesine sahip olacak şekilde büyürse, onu bir hizmete, kendi kendine barındırılan bir çözüme veya başka bir şeye dönüştürün. Sonuçta, o noktada bir ürününüz var ve zamanınızı şüphesiz kimlik doğrulamasını sürdürmek yerine o ürünü inşa etmeye harcamak daha iyi olacaktır.

Başlangıçlar

Genel olarak, ürünler inşa ediyorsanız, kendi auth'unuzu yapmayın. Çok sıkıcı ve bürokratik bir tekerleği yeniden icat etmektir. Seçebileceğiniz birçok seçeneğiniz var. Ayrıca, bir şey inşa ediyorsunuz, değil mi? Ürününüz auth değilse neden bu konuşmayı yapıyoruz ki?

Ölçeklendirme ve üzeri (bunları nasıl tanımlamayı seçersek seçelim)

Yapma. Girişimlerle aynı sebep - ama burada kesinlikle daha çok geçerli.

Muhtemelen nereye varmak istediğimi anlamışsınızdır. "Auth zordur" ifadesinin, genel bir ifade olarak kullanıldığında bir pazarlama söylemi olduğunu söyleyebilirim. Auth'u anlayabilir, inşa edebilirsiniz ancak sıkıcıdır, bakımı eğlenceli değildir ve çözülmüş bir sorundur. Bu nedenle, bir meta olarak düşünülebilir; raflardan istediğiniz çeşidini seçebilirsiniz (aşağıda bazı seçenekler bulunmaktadır).

Kendi kendine barındırılan ve FOSS manzarası

Yığın sahibi olmayı sevenler için (benim gibi), seçebileceğiniz birçok seçeneğiniz de var:

Yetkilendirme kütüphaneleri

• Passport.js, yukarıda ayrıntılı olarak ele alınmıştır
• Lucia - Geliştirici deneyimi ve kullanım kolaylığına odaklanan, modern web uygulamaları için basit ve esnek bir kimlik doğrulama kütüphanesi.
• Auth.js - Node.js için hafif ve özelleştirilebilir bir kimlik doğrulama kütüphanesi, çeşitli çerçevelere ve uygulamalara kolayca entegre edilebilecek şekilde tasarlanmıştır. Next için bir kütüphane olarak başlamıştır.

Kimlik doğrulama sunucuları

• Keycloak - Tek oturum açma (SSO), kimlik aracılığı ve kullanıcı federasyonu gibi özellikler sunan açık kaynaklı bir kimlik ve erişim yönetim sunucusu.
• SuperTokens (yukarıdaki sorumluluk reddi beyanını inceleyin) - Oturum yönetimi, sosyal oturum açma ve e-posta/şifre doğrulaması gibi önceden oluşturulmuş özellikler sunan, güvenlik ve basitliğe odaklanan açık kaynaklı bir kimlik doğrulama çözümüdür.
• FusionAuth - Geliştiricilere yönelik esnek bir kimlik doğrulama platformu olup kullanıcı yönetimi, çok faktörlü kimlik doğrulama (MFA) ve tek oturum açma (SSO) gibi özellikler sunmaktadır.
• Authelia - Ters proxy'leri kullanarak uygulamaları güvence altına almak için tasarlanmış, çok faktörlü kimlik doğrulama (MFA) ve SSO sağlayan açık kaynaklı bir kimlik doğrulama sunucusudur.

Depolama + Kimlik Doğrulama

• Supabase - Veritabanı, kimlik doğrulama ve gerçek zamanlı yetenekler sağlayan, Firebase alternatifi olarak tasarlanmış, açık kaynaklı bir arka uç hizmeti (BaaS) platformudur.
• Pocketbase - Veritabanı, kimlik doğrulama ve dosya depolamayı birleştiren, modern web ve mobil uygulamaların geliştirilmesini basitleştirmeyi amaçlayan açık kaynaklı bir arka uç çözümü.

Yani, kimlik doğrulama için üçüncü taraf yazılımları kullanmak istemiyorsanız bile, ihtiyaçlarınıza ve tercihlerinize bağlı olarak raflardan açık kaynaklı bir yazılım seçebilir ve onunla devam edebilirsiniz.

Özet: auth, geliştirmenin "bürokratik engelleri"dir

"Büyük" çıkarımım, özellikle de auth gibi çözülmüş bir sorunsa, tekerlekleri yeniden icat etmekten kaçınmaktır. Söz konusu tekerlekler hakkında bilgi edinin, onlarla deneyler yapın, bir oyuncak tekerlek yapın ve anlayın. Ama lütfen, lütfen bunu anlaşılması ve yapılması imkansız derecede zor bir şey olarak satmayın. Eğitin, kapı kapı dolaşmayın.