Supabase Auth - Team-HGD/SniffMEET GitHub Wiki

Authentication: 유저가 유저 스스로 주장하는 사람이 맞는지 확인하는 과정 Authorization: 해당 데이터에 접근이 허용된 유저인지 확인하는 과정

• Supabase Auth는 인증 하는데 JWT를 사용한다.
• Auth는 Supabase의 데이터베이스 기능과 통합되어 있으므로, RLS를 쉽게 사용하여 인증할 수 있다.

Supabase Auth의 4개의 주요 계층이 있다.

• Client Layer: Supabase SDK거나, HTTP 클라이언트를 사용해서 만든 HTTP 요청중 하나.
• Kong API gateway: 모든 Supabase 제품이 공유하는 게이트웨이
• Auth Service
• Postgres database: 모든 Supabase 제품이 공유하는 데이터베이스

애플리케이션에서 동작하는 레이어

• 프론트엔드, 백엔드, 네이티브 애플리케이션 코드에서 동작한다.
• SDK를 사용하는 것을 권장하긴 하나 원한다면 HTTP 호출로도 가능

Supabase에서 관리하는 Auth API 서버

• JWT를 검증, 발급, 리프레시 한다.
• 애플리케이션과 데이터베이스 내부의 Auth 정보 사이의 중개자

Supabase Auth는 auth 스키마를 사용하여 Postgres DB에 유저 테이블이나 다른 정보를 저장한다. 이 스키마는 자동으로 생성된 API에 노출되지 않는다.

오브젝트에 Auth 정보를 database trigger와 foreign key를 이용해 연결할 수 있다. RLS나 권한을 취소하여 Auth 데이터 내부에 생성한 뷰가 적절하게 보호되는지 확인해야 한다.

• auth스키마에 저장된 user ID를 가진 사람
• 유저는 Access Token을 발급 받아서 Supabase endpoint에 접근할 수 있다.
• RLS를 통해서 리소스에 대한 유저 액세스를 제한할 수 있다.

• 영구 유저: 개인 식별 정보(PII)에 연결된 유저, 이러한 식별 정보를 통해 로그아웃을 해도 다시 계정에 접근할 수 있다.
• 익명 유저: 개인 식별 정보가 없는 유저 로그아웃 할 경우 동일한 사용자로 다시 로그인 할 방법이 없다.

https://supabase.com/docs/guides/database/postgres/roles

• postgres: 관리자 권한이 있는 Postgres role
• anon: 로그인 되어있지 않는 상태에서 액세스를 위한 role
• authenticated: 로그인 한 유저를 위한 role
• service_role: API에서 RLS를 우회하기 위한 role

⚠️ 익명 유저는 anon-role을 사용하지 않는다. 영구 유저와 마찬가지로 익명 유저도 데이터베이스에 접근할 때 authenticated-role을 사용한다. anon-role은 로그인 되어있지 않은 유저(unauthenticated, public user)를 위한 것이다. roles: https://supabase.com/docs/guides/database/postgres/roles

Supabase Auth는 유저 세션에 대한 세분화된 제어 기능을 제공한다.

• 유저가 로그인 하면 세션이 생성된다.
• 기본적으로 세션은 제한 시간이 정해져 있지 않고, 활성화된 세션과 장치의 개수도 제한하지 않는다.
• JWT 형태의 access token과 고유 문자열(unique string)인 refresh token으로 표현된다.
• 기본적으로 액세스 토큰은 5분 - 1시간 사이의 짧은 만료 시간을 가지고, 리프레시 토큰은 만료 시간이 없지만 단 한번만 사용할 수 있다.
  • refresh token을 사용한다(세션 새로 고침): 새로운 access token, refresh token 쌍과 교환한다.
• 세션이 종료되는 것은 config에 달려있다
  • 로그아웃
  • 비밀번호 변경, 보안상 민감한 작업 수행
  • 비활성으로 인한 시간 초과
  • 세션 만료 시간에 도달 (위와 다른 점은, 위는 비활성 상태가 얼마나 지속되었느냐가 기준이고, 이 것은 비활성 상태랑 상관 없이 만료 시간에 도달하면 무조건 세션을 종료 시킴)
  • 다른 장치 로그인

모든 액세스 토큰은 session_id 클레임, UUID를 가지고 있다. 이 ID를 auth.sessions의 테이블의 기본 키와 상관관계를 만들 수 있다.

세션은 유저가 로그인 했을 때 개시된다. 세션은 auth.session테이블에 저장되고, 앱은 access와 refresh token을 수신해야 한다. session을 개시하는 흐름은 다음과 같다:

1. 로그인에 성공하면 다음과 같은 형태의 URL과 함께 앱으로 리디렉션 된다.

https://yourapp.com/...#access_token=<...>&refresh_token=<...>&...

URL에 access token과 refresh token이 포함되어 있다.

1. 이러한 유형의 URL을 감지하고
2. 정보를 추출한 다음
3. 앱에서 추가적으로 사용할 수 있도록 로컬 저장소에 보관한다.

• 익명 유저는 로그아웃하거나 브라우징 데이터를 지우거나 다른 장치를 사용하는 경우 계정에 액세스할 수 없다는 것을 제외하고는 영구 유저와 같다.
• 영구 유저처럼 authenticated role 은 익명 유저의 JWT에는 RLS 정책에서 구별하는 데 사용할 수 있는 is_anonymous클레임이 있다.
• anon API Key는 유저를 생성하지 않고, anon role 사용하므로 데이터베이스에 대한 공개 액세스를 구현하는데 사용한다.

⚠️ 익명 로그인을 활성화 하기 전에 RLS 정책을 확인해야 한다. 익명 유저는 authenticated role을 사용하기 때문에 영구 유저와 구분을 위해서는 JWT 토큰에 있는 is_anonymous 필드를 확인하자.

Anonymous Sign-Ins

익명 유저는 영구 유저처럼 authenticated role을 사용하기 때문에, RLS 정책을 사용하여 auth.jwt()에서 리턴된 is_anonymous클레임을 이용하여 구분할 수 있다.

Supabase는 이는 PostgREST를 사용하는 API 레이어를 제공한다. 이는 Postgres 위에 있는 얇은 레이어이다.

• CRUD와 관련된 모든 작업은 다음 URL에서 할 수 있다:

  https://<project_ref>.supabase.co/rest/v1/
  -- 우리 주소는: https://hgdhgd.supabase.co/rest/v1/
  

• 데이터베이스를 업데이트 하면, 변경 사항이 곧바로 API에 반영된다.

• RLS를 사용해 보안이 구성된다.

• Firebase보다 읽기 작업이 3배 이상 빠르다.

• 기본 CRUD 작업 (Create/Read/Update/Delete)
• Postgres 뷰(Views), 물리적 뷰(Materialized Views)
  • 물리적 뷰: 실제로 데이터가 저장되어 있는 뷰
• Postgres 함수
  • 특정 작업을 수행하는 SQL 코드 블록, 복잡한 로직을 쉽게 재사용 할 수 있음.
• Postgres의 보안 모델 - Row Level Security, 역할(Role), 권한 부여(Grants)를 포함