saas-auth

Name: saas-auth
Author: komunite

90stars9forks

How to install saas-auth?

komunite/tezgah/saas-auth

$npx -y skills add komunite/tezgah --skill saas-auth

Installs into the current project.

Summary

SaaS uygulaması için kimlik doğrulama ve oturum yönetimi kur. Google OAuth, Magic Link, e-posta/şifre veya bunların kombinasyonlarını yapılandır. Bu skill'i kullanıcı login sistemi, kayıt akışı, oturum yönetimi, korumalı route'lar veya kullanıcı profili ile ilgili bir şey istediğ

Files · 1

View on GitHub

SKILL.md

1	# SaaS Auth — Kimlik Doğrulama ve Oturum Yönetimi
2
3	Bu skill, bir SaaS uygulamasının kimlik doğrulama katmanını kurar. Auth, uygulamanın diğer tüm katmanlarının temelidir — ödeme sistemi kullanıcı kimliğine, API koruması oturuma, e-posta gönderimi kullanıcı bilgisine bağlıdır.
4
5	Bağımlılık: Bu skill saas-launcher orkestratör skill'inin Faz 3'üdür. Bağımsız olarak da kullanılabilir.
6
7	Bağlı skill'ler:
8	- saas-email — Magic Link stratejisi seçildiyse e-posta altyapısının kurulu olması gerekir.
9	- saas-payments — Auth tamamlandıktan sonra ödeme sistemi kullanıcı kimliğini kullanır.
10	- saas-api-security — Oturum bilgisi API koruma katmanı tarafından tüketilir.
11
12	---
13
14	## Auth Stratejisi Seçimi
15
16	Kullanıcıyla beraber doğru stratejiyi belirle. Her yöntemin avantaj ve dezavantajlarını açıkla.
17
18	### Google OAuth
19
20	Ne zaman seç: Çoğu SaaS için varsayılan önerimiz. Kullanıcılar yeni bir şifre oluşturmak zorunda kalmaz, güven algısı yüksektir.
21
22	Avantajları: Tek tıkla giriş, şifre yönetimi yükü yok, profil bilgisi (isim, fotoğraf) otomatik gelir, güvenilir e-posta adresi garanti.
23
24	Dezavantajları: Google Cloud Console'da OAuth uygulama oluşturma ve onay süreci gerekir. Production'da Google'ın app review'u birkaç gün sürebilir. Bazı kurumsal kullanıcılar kişisel Google hesaplarını iş araçlarında kullanmak istemeyebilir.
25
26	Kritik adımlar:
27	- Google Cloud Console'da proje oluştur, OAuth Client ID al
28	- Callback URL'leri hem development hem production için tanımla
29	- OAuth Consent Screen'i yapılandır ve yayınla
30	- Scopes: `email` ve `profile` neredeyse her zaman yeterli
31
32	Dikkat: Google OAuth başvurusunda uygulama adı, logo ve gizlilik politikası URL'si gerekir. Gizlilik politikası sayfası launch'tan önce hazır olmalı.
33
34	### Magic Link (E-posta ile Giriş)
35
36	Ne zaman seç: Şifresiz deneyim isteyenler için. Google'a bağımlı olmak istemeyenler veya Google OAuth'u destekle birlikte ikinci yöntem olarak.
37
38	Avantajları: Şifre yok, hesap çalınma riski düşük, e-posta adresi otomatik doğrulanmış olur.
39
40	Dezavantajları: Her girişte e-posta kutusuna gitmek gerekir — sürtünme yaratır. E-posta teslim edilemezse kullanıcı giremez. E-posta altyapısı hazır olmalı (DNS kayıtları dahil).
41
42	Bağımlılık: Magic Link kullanmak için saas-email skill'inin tarif ettiği e-posta altyapısı önceden kurulmuş olmalı. DNS kayıtları (SPF, DKIM, DMARC) yapılmadan magic link e-postaları spam'a düşer.
43
44	Dikkat: Magic link bağlantılarının süresi olmalı (24 saat makul). Bağlantı tek kullanımlık olmalı — tekrar kullanılması güvenlik açığıdır.
45
46	### E-posta + Şifre
47
48	Ne zaman seç: Genellikle önerilmez, ama bazı enterprise senaryolarda veya kullanıcı tabanı OAuth'a aşina değilse gerekebilir.
49
50	Avantajları: Kullanıcılara tanıdık kalıp, hiçbir dış servise bağımlılık yok.
51
52	Dezavantajları: Şifre saklama yükümlülüğü (hashing, salt, güvenli depolama), şifre sıfırlama akışı, brute force koruması, şifre politikası yönetimi. Güvenlik yüzey alanı çok daha geniş.
53
54	Eğer bu yol seçilirse: Şifreler bcrypt veya argon2 ile hash'lenmeli, minimum şifre uzunluğu zorunlu olmalı, rate limiting giriş denemelerine uygulanmalı, şifre sıfırlama token'ları tek kullanımlık ve süreli olmalı.
55
56	### Önerilen Kombinasyon
57
58	Çoğu SaaS için en iyi strateji: Google OAuth + Magic Link. Kullanıcıya iki yol sunar — Google hesabı olanlar tek tıkla girer, olmayanlar e-posta ile girer. İkisi de şifresiz.
59
60	Aynı e-posta ile hem Google hem Magic Link kullanılabilmesi için hesap bağlama (account linking) aktif edilmeli. Bu yapılmazsa "bu e-posta zaten kayıtlı" hatası oluşur.
61
62	---
63
64	## Oturum Stratejisi
65
66	### JWT vs. Database Session
67
68	JWT (JSON Web Token) — Varsayılan önerimiz:
69	- Oturum bilgisi token içinde taşınır, her istekte veritabanı sorgusu yapmaz
70	- Serverless ortamlarda (Vercel) çok daha performanslı
71	- Token içine plan bilgisi gibi özel alanlar eklenebilir
72	- Dezavantaj: token iptal etmek anında mümkün değil (token süresi dolana kadar geçerli)
73
74	Database Session:
75	- Oturum veritabanında saklanır, her istekte sorgulanır
76	- Anlık iptal mümkün (oturumu sil → kullanıcı çıkış yapmış olur)
77	- Dezavantaj: her API isteğinde veritabanı sorgusu, serverless'ta latency
78
79	Karar: JWT seç. Plan bilgisinin anlık güncellenmesi gerekiyorsa (ödeme sonrası plan yükseltme), session update mekanizmasını kullan — token'ı yenile.
80
81	### Token'a Eklenecek Bilgiler
82
83	JWT token'a şu bilgileri ekle:
84	- Kullanıcı ID'si (veritabanı referansı)
85	- Plan bilgisi (free/starter/pro — API koruma katmanı bunu kullanır)
86	- Gerekirse: takım ID'si, ro

People who liked this also viewed

6 picks

Type

saas-auth

90stars9forks

View on GitHub

How to install saas-auth?

komunite/tezgah/saas-auth

$npx -y skills add komunite/tezgah --skill saas-auth

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# SaaS Auth — Kimlik Doğrulama ve Oturum Yönetimi
2
3	Bu skill, bir SaaS uygulamasının kimlik doğrulama katmanını kurar. Auth, uygulamanın diğer tüm katmanlarının temelidir — ödeme sistemi kullanıcı kimliğine, API koruması oturuma, e-posta gönderimi kullanıcı bilgisine bağlıdır.
4
5	Bağımlılık: Bu skill saas-launcher orkestratör skill'inin Faz 3'üdür. Bağımsız olarak da kullanılabilir.
6
7	Bağlı skill'ler:
8	- saas-email — Magic Link stratejisi seçildiyse e-posta altyapısının kurulu olması gerekir.
9	- saas-payments — Auth tamamlandıktan sonra ödeme sistemi kullanıcı kimliğini kullanır.
10	- saas-api-security — Oturum bilgisi API koruma katmanı tarafından tüketilir.
11
12	---
13
14	## Auth Stratejisi Seçimi
15
16	Kullanıcıyla beraber doğru stratejiyi belirle. Her yöntemin avantaj ve dezavantajlarını açıkla.
17
18	### Google OAuth
19
20	Ne zaman seç: Çoğu SaaS için varsayılan önerimiz. Kullanıcılar yeni bir şifre oluşturmak zorunda kalmaz, güven algısı yüksektir.
21
22	Avantajları: Tek tıkla giriş, şifre yönetimi yükü yok, profil bilgisi (isim, fotoğraf) otomatik gelir, güvenilir e-posta adresi garanti.
23
24	Dezavantajları: Google Cloud Console'da OAuth uygulama oluşturma ve onay süreci gerekir. Production'da Google'ın app review'u birkaç gün sürebilir. Bazı kurumsal kullanıcılar kişisel Google hesaplarını iş araçlarında kullanmak istemeyebilir.
25
26	Kritik adımlar:
27	- Google Cloud Console'da proje oluştur, OAuth Client ID al
28	- Callback URL'leri hem development hem production için tanımla
29	- OAuth Consent Screen'i yapılandır ve yayınla
30	- Scopes: `email` ve `profile` neredeyse her zaman yeterli
31
32	Dikkat: Google OAuth başvurusunda uygulama adı, logo ve gizlilik politikası URL'si gerekir. Gizlilik politikası sayfası launch'tan önce hazır olmalı.
33
34	### Magic Link (E-posta ile Giriş)
35
36	Ne zaman seç: Şifresiz deneyim isteyenler için. Google'a bağımlı olmak istemeyenler veya Google OAuth'u destekle birlikte ikinci yöntem olarak.
37
38	Avantajları: Şifre yok, hesap çalınma riski düşük, e-posta adresi otomatik doğrulanmış olur.
39
40	Dezavantajları: Her girişte e-posta kutusuna gitmek gerekir — sürtünme yaratır. E-posta teslim edilemezse kullanıcı giremez. E-posta altyapısı hazır olmalı (DNS kayıtları dahil).
41
42	Bağımlılık: Magic Link kullanmak için saas-email skill'inin tarif ettiği e-posta altyapısı önceden kurulmuş olmalı. DNS kayıtları (SPF, DKIM, DMARC) yapılmadan magic link e-postaları spam'a düşer.
43
44	Dikkat: Magic link bağlantılarının süresi olmalı (24 saat makul). Bağlantı tek kullanımlık olmalı — tekrar kullanılması güvenlik açığıdır.
45
46	### E-posta + Şifre
47
48	Ne zaman seç: Genellikle önerilmez, ama bazı enterprise senaryolarda veya kullanıcı tabanı OAuth'a aşina değilse gerekebilir.
49
50	Avantajları: Kullanıcılara tanıdık kalıp, hiçbir dış servise bağımlılık yok.
51
52	Dezavantajları: Şifre saklama yükümlülüğü (hashing, salt, güvenli depolama), şifre sıfırlama akışı, brute force koruması, şifre politikası yönetimi. Güvenlik yüzey alanı çok daha geniş.
53
54	Eğer bu yol seçilirse: Şifreler bcrypt veya argon2 ile hash'lenmeli, minimum şifre uzunluğu zorunlu olmalı, rate limiting giriş denemelerine uygulanmalı, şifre sıfırlama token'ları tek kullanımlık ve süreli olmalı.
55
56	### Önerilen Kombinasyon
57
58	Çoğu SaaS için en iyi strateji: Google OAuth + Magic Link. Kullanıcıya iki yol sunar — Google hesabı olanlar tek tıkla girer, olmayanlar e-posta ile girer. İkisi de şifresiz.
59
60	Aynı e-posta ile hem Google hem Magic Link kullanılabilmesi için hesap bağlama (account linking) aktif edilmeli. Bu yapılmazsa "bu e-posta zaten kayıtlı" hatası oluşur.
61
62	---
63
64	## Oturum Stratejisi
65
66	### JWT vs. Database Session
67
68	JWT (JSON Web Token) — Varsayılan önerimiz:
69	- Oturum bilgisi token içinde taşınır, her istekte veritabanı sorgusu yapmaz
70	- Serverless ortamlarda (Vercel) çok daha performanslı
71	- Token içine plan bilgisi gibi özel alanlar eklenebilir
72	- Dezavantaj: token iptal etmek anında mümkün değil (token süresi dolana kadar geçerli)
73
74	Database Session:
75	- Oturum veritabanında saklanır, her istekte sorgulanır
76	- Anlık iptal mümkün (oturumu sil → kullanıcı çıkış yapmış olur)
77	- Dezavantaj: her API isteğinde veritabanı sorgusu, serverless'ta latency
78
79	Karar: JWT seç. Plan bilgisinin anlık güncellenmesi gerekiyorsa (ödeme sonrası plan yükseltme), session update mekanizmasını kullan — token'ı yenile.
80
81	### Token'a Eklenecek Bilgiler
82
83	JWT token'a şu bilgileri ekle:
84	- Kullanıcı ID'si (veritabanı referansı)
85	- Plan bilgisi (free/starter/pro — API koruma katmanı bunu kullanır)
86	- Gerekirse: takım ID'si, ro

People who liked this also viewed

6 picks

Type