Supabase 용어 - Team-HGD/SniffMEET GitHub Wiki

JWT(JSON Web Token)

구성

헤더, 페이로드, 서명으로 구성된다.

  • 헤더: 말 그대로 헤더… 서명이 어떤 알고리즘으로 되어있는지와 같은 정보를 담고 있음
{ "alg": "HS256", "typ": "JWT" }
  • 페이로드: 사용자 정보나 요청 데이터가 담기는 부분, 이 부분에 있는 키-값 쌍을 클레임이라고 하고, 클레임중에서도 표준 클레임이 존재함
    • sub: 사용자의 정보
    • iat: JWT가 발급된 시간
    • ext: 만료시간
{ "sub": "888484", "dog_name": "HGD", "iat": 123456 }
  • 서명: 토큰이 변조되지 않았음을 보장하는 부분, 비밀 키와 헤더의 alg에서 정의한 알고리즘을 사용한다.
  • 최종적으로 BASE64로 인코딩 한다음에 주고받기

용도 및 특징

  • 사용자 인증
  • 정보 교환: 서명이 있으므로 변조되지 않았음을 보장할 수 있다.
  • 세션 관리: 클라이언트 측에 저장되므로 서버의 부담이 줄어들음
  • 만료 기한이 존재한다.

RLS(Row-Level Security)

image

PostgreSQL에서 제공하는 행 단위로 접근 권한을 제어하는 보안 기능, 특정 사용자나 그룹이 특정 행에 대해서만 접근할 수 있도록 권한을 설정할 수 있게 한다.

동작 순서

-- orders RLS 활성화
ALTER TABLE test ENABLE ROW LEVEL SECURITY;

-- 정책 추가: 현재 로그인한 사용자만 자신의 주문을 볼 수 있도록 설정
CREATE POLICY select_own_orders ON test
	FOR SELECT 
	USING (user_id = current_user_id());
  1. RLS 활성화
    1. test 테이블에 RLS를 활성화 시킨다.
  2. 정책 추가
    1. test 테이블에 select_own_orders 라는 새로운 POLICY를 생성한다.
    2. FOR SELECT - USING () 현재 정책이 읽기 작업 (SELECT)에만 적용됨을 지정하고, USING에는 조건을 지정한다.
    3. 위 예제 코드에선 현재 user_id 컬럼의 값이 현재 user_id와 같은 경우에만 접근을 허용한다.

장단점

  • 행 단위 접근 제어로 인한 정교한 보안 설정
    • 테이블 단위가 아닌 행 단위로 접근 레벨을 설정할 수 있어서 보안성이 높아진다.
  • 사용자 역할, ID 등 조건 설정이 유연함
    • 사용자, 역할, 그룹에 따라 조건을 지정할 수 있음
    • USING(status = ‘open’) 처럼 특정 컬럼의 값에 따라서 접근을 제한할 수 도 있음
    • 여러 조건을 논리 연산자로 결합하여 복잡한 조건을 만들 수 있다.
  • 정책이 많아지면 데이터베이스가 복잡도가 높아짐
  • 데이터베이스 쿼리 성능에 영향을 끼침

공부하면서 터득한 부분

  • anon-key 랑은 아무 관련이 없다. (anon-key는 로그인 없이 순수하게 데이터 베이스에 접근하는 용도의 키, 익명 유저랑 다름)
  • Supabase의 JWT 만료 기한은 분단위로 매우 짧다. (대신 refresh Token이 있다.)