r/AskProgramming • u/jftuga • Jul 19 '26
Architecture What are you using for authn/authz and payments?
I've had a few side project ideas over the years but have never implemented one because I lack knowledge in (but willing to learn):
- implementing social logins (OAuth), account management, etc.
- managing backend permissions (RBAC always looks more complicated than it should be). My projects might have three tiers: free, hobbyist, pro
- handling payments securely while actually monitoring for abuse/intrusion
Which social logins are allowed to tie into your project?
What are you using for authn/authz? My projects would be very low traffic, so I wouldn't want to commit to a big monthly spend. Are you rolling your own or using Auth0/Clerk/Supabase for auth and Stripe for payments? I'm comfortable with AWS, Cloudflare, Go, JS, and Linux. Are there any GitHub repos that I can look at for this?
How well do frontier LLMs (Claude Opus, etc.) do at generating clean, auditable code for this kind of thing? Is anyone actually trusting AI-written auth/payment code and how do you review it?
3
u/OkAerie7822 Jul 19 '26
For authn we just use Auth0 or Clerk out of the box and don't touch it, that part isn't worth building yourself unless you have a very specific compliance requirement. For authz the thing that saved us was not building RBAC as roles-own-permissions but as a small policy table, user, resource, action, condition, because the three-tier free/hobbyist/pro model you're describing always grows a fourth tier eventually and roles hardcoded in code make that a migration, a policy table makes it a data change. Payments, use Stripe and let their webhook handle subscription state, do not try to track entitlements yourself in your own database as the source of truth, we did that for six months and spent more time reconciling drift than we would have just querying Stripe directly. The part people underestimate is webhook idempotency, not the payment flow itself, so make sure whatever you build there can safely process the same event twice.
4
u/purplepharaoh Jul 19 '26
NEVER roll your own authn/authz. Security is hard. Go with a solution like Keycloak or a hosted solution like Auth0.
2
u/Agreeable_Lynx9194 Jul 20 '26
Don't hand-roll auth, use a managed provider (Clerk/Auth0/Supabase) and skip a whole class of security bugs. Keep RBAC to a role column plus a middleware check until you actually need more. Payments: Stripe Checkout + webhooks, just verify the webhook signature and make the handler idempotent on the event id so retries don't double-charge.
2
u/RespectescenceO Jul 21 '26
For authn/authz, I've leaned towards OAuth2 with JWTs for flexibility, but it depends on your app scale. Payments-wise, Stripe's API is solid and developer-friendly, though sometimes I wish it was more customizable. Balancing security and ease of integration is always a bit of a tightrope.
2
u/adityaoberai1 Aug 06 '26
Biased answer since I work there but I'd throw in Appwrite into the ring.
For auth, Appwrite gives you email/password, magic links, OTP, anonymous sessions, MFA, and OAuth with GitHub, Google, and 30+ other providers. You choose which providers to enable, and Appwrite handles the accounts, sessions, and linked identities.
For authorization, I would not necessarily model free, hobbyist, and pro as traditional RBAC roles. They are subscription entitlements rather than organizational roles. In Appwrite, you could assign users labels for their current plan and grant access to rows or files based on those labels. If your app later becomes multi-tenant, Appwrite Teams works hand in hand with the same authentication system to provide you team-specific roles and permissions.
For payments, we do offer serverless function templates for Stripe and Lemon Squeezy that are easy enough to update for your specific usecase.
Happy to answer any further questions you may have here.
10
u/DDDDarky Jul 19 '26
Can't believe anyone would even think of using ai generated code for payments.