Auth에 대하여 - otw7917/oig GitHub Wiki

로그인 디자인 가이드

  • 로그인 버튼을 설계할 때 아래의 기준을 반드시 따른다:

  1. Oauth 리소스를 제공하는 provider(Google, Apple 등)에 대해 공식 디자인 가이드라인이 있는지 확인한다.

    • 브랜드 명칭 + 로고 + 버튼 스타일 규칙이 제공되는지 확인한다.
    • 제공된다면 해당 규칙을 가능한 한 그대로 따른다 (문구, 여백, 색상, 배치 등).

  2. 공식 가이드라인이 없을 경우, 다음을 순서대로 따른다:

    • 해당 provider의 로고(SVG, PNG)를 신뢰할 수 있는 공식 출처에서 확보 가능한지 확인한다.
    • 로고를 구할 수 없다면 아래 기본 형식을 따른다:
      • 버튼 문구는 반드시: "Sign in with {Provider}"
        • {Provider}는 예: Google, Apple, Kakao
        • 첫 글자는 대문자, 전체 문구는 정확히 표기할 것
      • 로고는 가능한 가장 근접한 형태로 디자인하되, 공식 아님을 명시하는 주석 또는 노트를 코드나 문서에 남긴다.

  3. 기본적인 디자인 규칙:

    • 버튼에 사용된 브랜드 명칭, 로고, 스타일의 출처를 명확히 남긴다.
    • 폰트는 반드시 Roboto일 필요는 없지만, 가능한 가이드를 따른다.
    • 색상은 기본적으로 흰 배경 + 회색 테두리 + 검정/어두운 회색 텍스트를 사용한다.
    • 다크 모드나 고대비 환경에서도 인식 가능하게 대비를 충분히 확보한다.
    • 버튼 크기는 최소 높이 40px 이상, 로고와 텍스트 사이 여백 12px 이상 확보할 것.

  4. 적용 환경:

    • Tailwind, CSS-in-JS, 이미지 기반 등 어떤 방식이든 가이드 준수를 우선한다.
    • 접근성(alt text), 마우스 및 키보드 호버 효과 등도 고려한다.
  • 예외가 필요한 경우에는 디자인/법무 리뷰를 요청하여 기록에 남긴다.

구글 가이드라인

PostgreSQL에서의 VIEW와 RLS(Row-Level Security)

1. VIEW란?

VIEW는 복잡한 SELECT 쿼리를 이름을 붙여 저장해두는 가상의 테이블입니다. 일반 테이블처럼 사용할 수 있지만 실제 데이터를 저장하지 않고, 정의된 쿼리를 실행한 결과를 반환합니다.

📌 VIEW의 주요 사용 목적

  • 복잡한 쿼리의 재사용 (DRY 원칙)
  • 민감한 정보를 제외한 읽기 전용 인터페이스 제공
  • API 응답 형식을 통일하기 위한 데이터 가공 및 조합
-- 예: 활성 사용자만 필터링한 VIEW
CREATE VIEW active_users AS
SELECT id, email FROM users WHERE is_active = true;

✅ 주의: VIEW는 실제 데이터를 저장하지 않으며, 호출 시마다 원본 테이블을 참조합니다.

2. RLS(Row-Level Security)란?

RLS는 테이블의 각 행(row)마다 접근 권한을 다르게 설정할 수 있는 PostgreSQL의 보안 기능입니다. 테이블 단위가 아닌 행 단위의 세밀한 권한 제어가 가능합니다.

🔐 RLS의 주요 특징

  • 사용자마다 자신의 데이터만 보이도록 설정 가능
  • SELECT, INSERT, UPDATE, DELETE에 대해 행 단위로 권한 통제 가능
  • Supabase 등 인증 시스템과 연동 시 강력한 보안 레이어로 작동
-- 예: 현재 로그인한 사용자만 자신의 row에 접근 가능
ALTER TABLE profiles ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Users can access their own profile"
  ON profiles
  FOR SELECT
  USING (user_id = auth.uid());

3. VIEW와 RLS를 함께 사용할 때 주의할 점

PostgreSQL 15부터 VIEW에도 RLS 정책을 정상적으로 적용할 수 있게 되었지만, 설정을 명확히 하지 않으면 RLS가 무시될 위험이 있습니다.

⚠️ 기본 동작의 위험성

  • VIEW는 기본적으로 SECURITY DEFINER 속성을 갖습니다.
  • 이는 VIEW를 호출하는 사용자가 아닌, VIEW를 정의한 사용자의 권한으로 실행됨을 의미합니다.
  • 이 경우, 해당 테이블에 설정된 RLS 정책이 우회될 수 있습니다.
-- ❌ RLS를 우회할 수 있는 위험한 VIEW 예시
CREATE VIEW user_view AS
SELECT * FROM users;

✅ 안전한 VIEW 작성 방법

PostgreSQL 15 이상에서는 다음과 같이 SECURITY INVOKER 옵션을 명시하여 RLS를 적용할 수 있습니다.

-- 안전한 View 정의 방법 (1)
CREATE VIEW user_view
WITH (security_invoker = true) AS
SELECT id, email FROM users;

또는:

-- 안전한 View 정의 방법 (2)
CREATE VIEW user_view SECURITY INVOKER AS
SELECT id, email FROM users;

✅ SECURITY INVOKER를 지정하면 View 실행 시 호출자의 권한이 사용되며, RLS가 정상적으로 작동합니다.

4. Best Practices

  • 인증 관련 데이터(auth.users 등)는 가능한 한 직접 쿼리 + RLS 정책을 활용해 보호합니다.
  • VIEW를 사용하는 경우 반드시 SECURITY INVOKER를 명시하여 RLS가 적용되도록 해야 합니다.
  • 복잡한 조인이나 API 응답 정제를 위한 목적이라면 VIEW를 활용할 수 있으나, 이때도 RLS 정책 적용 여부를 반드시 테스트해야 합니다.

✅ 참고 자료