수파베이스 로그인 흐름 이해하기

김현준·2025년 5월 9일

스팟에디터 트러블슈팅, 구현

목록 보기

5/18

이번에 수파베이스의 소셜 로그인 기능을 적용하며 그동안 모호했던 Authentication(인증)과 Authorization(권한) 개념을 전통적인 방식과 비교해가며 정리해봤다.

Authentication (인증)

사용자가 누군지 확인하는 절차

예시: 사용자가 구글 계정으로 로그인할 때
- 수파베이스의 signInWithOAuth({ provider: 'google' }) 함수 호출
- 구글 로그인 창이 뜨고, 사용자가 인증을 완료
- 수파베이스가 access_token, user 정보를 발급
- 이걸 통해 "이 사용자는 구글 계정 A의 소유자다"라고 확인됨

Authorization (권한 부여)

인증된 사용자가 무엇을 할 수 있는지 결정하는 절차

예시: 로그인한 사용자가 자신이 쓴 게시글만 수정할 수 있게 하려면
- 백엔드 API 또는 Supabase Row Level Security(RLS)에서
- user.id === post.user_id인 경우에만 UPDATE 허용
- 즉, 인증은 되어있지만 자기 게시글이 아니면 수정은 못함

전통적인 로그인 방식

"클라이언트 → 서버 → DB" 흐름에서 권한 판단은 서버가 책임진다

흐름 요약

[로그인 요청]
브라우저 → /login API → 서버 → DB → 결과 반환

[데이터 요청]
브라우저 → /posts API (토큰 포함)
→ 서버에서 인증된 유저인지 검증
→ 유저의 권한 확인 후 DB 쿼리
→ 응답 반환

서버는 항상 중간 관리자 역할을 하며, DB에는 전권 접근이 가능
클라이언트는 DB에 직접 접근하지 못하므로 이 구조가 안전하게 유지 됨

수파베이스 로그인 방식

서버 없이 클라이언트가 직접 DB 요청
따라서 권한 제어를 DB 자체가 담당

흐름 요약

[로그인 요청]
브라우저 → supabase.auth.signIn() 실행
→ Supabase Auth 서버가 OAuth 연동 및 토큰 발급

[데이터 요청]
브라우저 → supabase.from("posts").select("*")
→ Supabase가 토큰을 바탕으로 유저 식별
→ DB에서 권한 확인 후 데이터 응답

브라우저에서 supabase.from("...")으로 요청하면

이건 사실 REST API 요청을 JS로 감싼 것이며,
내부적으로는 DB에 쿼리를 날린다.

핵심 차이

수파베이스는 DB가 권한을 판단
수파베이스는 PostgreSQL의 RLS(Row Level Security) 기능을 사용해,
DB 단에서 자동으로 권한 제어

RLS(로우 레벨 시큐리티) 예시

create policy "사용자는 자신의 데이터만 조회 가능"
on todos for select
using (auth.uid() = user_id);

동작 방식

select * from todos
-- 이 쿼리에 다음이 자동으로 붙음
where auth.uid() = todos.user_id;

auth.uid()는 현재 로그인한 유저의 ID를 반환하며,
이 조건이 자동으로 모든 쿼리에 붙는다.

즉, 내가 select만 날려도 자동으로 내 데이터만 필터링된다.
다른 사람 데이터를 가져오려 해도 DB에서 거절당함.

로그인 흐름 비교표

항목	전통적인 방식	Supabase 방식
인증 처리	서버가 Auth API 구현	Supabase가 OAuth/Email로 인증
인증 정보 저장	서버 세션 or JWT	Supabase 쿠키 or JWT
DB 접근	서버만 가능	클라이언트가 직접 가능
권한 판단 위치	서버 코드	DB(RLS)
보안 제어 포인트	서버 로직	DB 정책(RLS + Policy)