Hướng dẫn setup Supabase Auth: session chuẩn và RLS cho Postgres
· Tác giả: Trường — Founder Webchốt
Liên quan: Bạn đang cần một website để bán hàng? Xem trọn bộ dịch vụ thiết kế web bán hàng.
Hướng dẫn setup Supabase Auth này dành cho team đang xây portal hoặc SaaS nhẹ trên Next.js và muốn bảo mật dữ liệu ở tầng database bằng Row Level Security. Phần mở đầu tập trung vào việc bạn sẽ làm gì trong một ngày làm việc thực tế: tạo project, bật provider phù hợp, cấu hình URL redirect, tạo bảng profiles liên kết auth.users, viết policy RLS đọc/ghi theo tenant hoặc theo user, rồi kiểm tra bằng SQL và giao diện. Mục tiêu là tránh lỗi phổ biến như để anon key trên server lộ logic nhạy cảm, hoặc bật RLS nhưng quên policy nên ứng dụng chết im. Cuối bài có FAQ kỹ thuật để tra cứu nhanh khi bạn debug production. Nếu bạn cần đội triển khai trọn gói, xem trang dịch vụ web của Webchốt.
Bảo vệ dữ liệu khách hàng bắt đầu từ session đúng chuẩn và policy rõ ràng trên Postgres | Nguồn: webchot.com
Supabase Auth và Supabase row level security: nền tảng cần hiểu trước khi code
Supabase Auth lưu danh tính người dùng và phát JWT. Phía Postgres, mỗi request từ client JavaScript thường đi qua PostgREST với JWT đính kèm. Row Level Security là cơ chế của Postgres lọc dòng theo điều kiện policy, nên ngay cả khi truy vấn SQL giống nhau, hai user khác nhau sẽ nhìn thấy tập dòng khác nhau. Điểm mấu chốt là bạn không được coi RLS như tính năng tùy chọn cho bảng chứa PII hay đơn hàng: nếu bảng đã public qua API và chỉ dựa vào filter phía client, rủi ro lộ dữ liệu rất lớn. Chiến lược khôn ngoan là thiết kế schema với khóa ngoại tới auth.users hoặc organization_id ngay từ đầu, sau đó map JWT claim vào điều kiện policy.
Ở môi trường dev, hãy tạo hai tài khoản test và một bộ seed nhỏ để kiểm tra policy không chỉ đọc mà còn insert và update. Việc này giúp bạn phát hiện sớm lỗi khi dùng trigger hoặc default value sai. Khi chuyển staging, đồng bộ lại biến môi trường NEXT_PUBLIC_SUPABASE_URL và ANON_KEY và đối chiếu site URL trong dashboard Supabase để tránh lỗi redirect sau đăng nhập.
Chọn phương án đăng nhập và cấu hình biến môi trường an toàn
Email magic link, OTP, Google hoặc GitHub đều có ưu nhược điểm riêng. Với sản phẩm phục vụ người dùng Việt Nam, magic link qua email vẫn phổ biến, nhưng bạn nên chuẩn bị template nhắc người kiểm tra hộp thư spam. OAuth tiện cho dev nội bộ nhưng đòi hỏi cấu hình client id và secret đúng domain production. Không bao giờ nhúng service role key vào bundle trình duyệt; chỉ dùng anon key ở phía client và giữ service role cho Edge Function hoặc server tin cậy.
- Tách client browser và server: tạo helper createBrowserClient và createServerClient theo @supabase/ssr để cookie được refresh đúng chu kỳ.
- Redirect URL: liệt kê đầy đủ localhost, preview Vercel và domain chính để tránh lỗi callback.
- Rate limit: bật email confirmation và giới hạn số lần gửi liên kết để chống abuse nhẹ.
- Webhooks: cân nhắc đồng bộ profiles khi user.created nếu bạn cần denormalize display name.
Bảng so sánh nhanh các chiến lược policy RLS phổ biến
Dưới đây là khung quyết định khi bạn thiết kế policy lần đầu. Mục đích là giảm tranh cãi trong code review vì mỗi pattern đều có giá phí vận hành khác nhau.
| Tiêu chí | Theo user_id | Theo organization_id | Kết hợp role claim | Khuyên dùng |
|---|---|---|---|---|
| Độ phức tạp triển khai | Thấp, phù hợp MVP | Trung bình, cần join bảng membership | Cao, phụ thuộc JWT custom claims | Bắt đầu user_id, mở rộng org sau |
| Đa tenant B2B | Hạn chế | Mạnh nếu mọi bảng có org key | Rất linh hoạt với admin | organization_id + index phù hợp |
| Audit và debug | Dễ đọc log SQL | Cần kỷ luật đặt tên cột | Dễ sai nếu claim lệch DB | Ghi chú policy trong migration |
| Rủi ro thời điểm ban đầu | Thấp nếu test kỹ | Trung bình khi migrate legacy | Cao nếu phát sinh role ẩn | Thêm test tự động cho policy |
Khi chọn organization_id, hãy bắt buộc NOT NULL trên các bảng nghiệp vụ chính và tạo foreign key tới bảng organizations. Policy SELECT có thể cho phép thành viên đọc dòng khi auth.uid() thuộc membership của org đó. Với admin toàn cục, tạo bảng role riêng hoặc dùng claim custom nhưng hạn chế đặt quyền admin trong client.
Quy trình thực hành từ tạo bảng tới bật RLS và kiểm tra
- Tạo bảng và index: đặt primary key kiểu uuid, thêm cột user_id REFERENCES auth.users(id) hoặc tenant key; index cho các cột hay lọc.
- ALTER TABLE ENABLE ROW LEVEL SECURITY: thực thi trên mọi bảng public qua API; kiểm tra lại bằng schema diff.
- Viết policy FOR SELECT USING: điều kiện tối thiểu là user_id = auth.uid() hoặc membership phù hợp; tránh OR quá rộng.
- Policy INSERT và UPDATE WITH CHECK: đảm bảo user không tự gán owner khác; khóa các cột nhạy cảm bằng trigger nếu cần.
- Thử hai phiên song song: mở hai trình duyệt, đăng nhập hai user, gọi cùng endpoint và xác minh dữ liệu tách biệt.
Sau khi pass checklist, hãy lưu migration SQL trong repo và mô tả ngắn ý nghĩa từng policy để đồng đội mới onboard trong vài phút. Nếu bạn dùng ORM, vẫn coi migration là nguồn sự thật, không chỉ generate từ code.
Chi phí nội bộ so với triển khai cùng đối tác và liên hệ Webchốt
Tự setup Supabase Auth tiết kiệm ngân sách ngắn hạn nếu team đã quen Postgres và Next.js; chi phí ẩn nằm ở thời gian review policy, hardening cookie và viết tài liệu handover. Thuê đối tác phù hợp khi bạn cần roadmap rõ, bàn giao CI/CD và đào tạo vận hành. Webchốt gói dịch vụ thiết kế web Next.js thường tích hợp Supabase cho CMS nhẹ, portal khách hàng và dashboard nội bộ, kèm tiêu chí Lighthouse và log audit cơ bản.
Khi trao đổi vendor, hãy yêu cầu demo RLS trên dữ liệu giả và bằng chứng test regression sau mỗi lần đổi schema. Việc này giúp tránh tình trạng production ổn định nhưng staging lại mở quyền quá rộng vì copy sai policy.
Sai lầm dễ gặp khiến Supabase Auth hoặc RLS thất bại thầm lặng
Nhiều dự án chạy được demo nhưng lại rủi ro khi scale nhỏ vài chi tiết bị bỏ qua lúc đầu. Dưới đây là các case Webchốt thường phải vá khi nhận bàn giao từ nơi khác.
- Bật RLS nhưng không có policy: kết quả là chặn toàn bộ hoặc trái ngược tùy role, khó debug nếu không đọc log PostgREST kỹ.
- Dùng service role ở client: coi như công khai toàn bộ database; rotate key ngay và audit log truy cập.
- Không index theo tenant: policy đúng nhưng truy vấn chậm, dẫn tới timeout trên dashboard mobile.
- Quên refresh session: cookie hết hạn nhưng UI vẫn hiển thị như đăng nhập, gây lỗi UX và request xen kẽ 401.
FAQ — hướng dẫn setup supabase auth
RLS có thay thế hoàn toàn kiểm soát quyền ở API không?
RLS là lớp bảo vệ bắt buộc ở tầng database khi client hoặc service role có thể chạm trực tiếp Postgres qua Supabase. Bạn vẫn nên kiểm tra quyền nghiệp vụ ở API hoặc server action để tránh logic phức tạp nằm hết trong policy. Kết hợp hai lớp giúp giảm rủi ro khi có lỗi ở một nơi và dễ audit hơn cho team nhỏ.
Nên dùng Supabase Auth với magic link hay email và mật khẩu?
Magic link tiện cho onboarding nhanh và ít friction trên mobile. Email và mật khẩu phù hợp khi người dùng quen flow truyền thống hoặc cần tuân thủ nội bộ. Với B2B có thể bật SAML hoặc SSO tùy gói. Quan trọng là bật xác thực hai lớp khi ứng dụng chứa dữ liệu nhạy cảm và cấu hình redirect URL đúng cho môi trường dev và production.
auth.uid() trong policy RLS trả về gì và khi nào bị null?
auth.uid() là UUID của người dùng đã đăng nhập qua Supabase Auth cho request đang dùng JWT hợp lệ. Nếu request dùng khóa service role hoặc chưa gửi token, giá trị có thể khác kỳ vọng. Vì vậy policy nên kiểm tra rõ điều kiện và tránh SELECT rộng mặc định. Luôn test bằng tài khoản thật và tài khoản ẩn danh trong SQL editor.
Làm sao đồng bộ session Supabase với Next.js App Router và middleware?
Dùng @supabase/ssr để đọc và ghi cookie phiên trong Server Component, Route Handler và middleware. Tạo client riêng cho server và browser theo tài liệu chính thức. Tránh trộn storage local-only với luồng SSR vì sẽ lệch state giữa lần request. Sau khi đăng nhập, redirect qua route xử lý cookie để tránh flash nội dung nhạy cảm.
Khi nào nên thuê đội triển khai thay vì tự setup Supabase Auth?
Nếu bạn cần portal nhiều vai trò, audit log, tích hợp thanh toán và SLA bảo hành, thuê đội có kinh nghiệm giúp rút ngắn thời gian và giảm lỗi cấu hình RLS. Webchốt triển khai Next.js với Supabase cho SME với quy trình rõ ràng và handoff tài liệu. Liên hệ qua hotline 0905 151 701 hoặc email hi@webchot.com để trao đổi phạm vi.
Liên Hệ Webchốt
Hướng dẫn setup Supabase Auth cần đi đôi với thực hành trên project thật: cookie SSR, migration RLS và kiểm thử hai user. Webchốt hỗ trợ doanh nghiệp nhỏ và startup xây MVP nhanh trên Next.js nhưng vẫn giữ chuẩn bảo mật Postgres. Bạn có thể gửi repo hoặc mô tả phạm vi để nhận checklist review policy miễn phí trong buổi trao đổi đầu tiên. Đừng chậm trễ với hardening khi đã có khách trả tiền, vì sửa policy trong production luôn tốn nhiều ca làm việc hơn lúc thiết kế ban đầu.
- Hotline / Zalo: 0905 151 701 — gặp anh Trường (founder/dev).
- Chat Zalo: zalo.me/0905151701 — phản hồi nhanh.
- Email: hi@webchot.com — phản hồi <12h làm việc.
- Studio: 262/1/93 Phan Anh, Phường Phú Thạnh, TP.HCM (T2–T7, 9h–18h).
Tham khảo thêm: 17 template Next.js · 10 dịch vụ web chuyên sâu · bảng giá Webchốt 2026 · 12 công cụ kế toán/tài chính miễn phí.
Reference: Next.js docs · web.dev Core Web Vitals.
