한 시스템이 신원을 소유하게 하세요
로그인 폼은 요청을 수집합니다. 인증 시스템은 그 요청이 신원을 확립하는지 결정하고 애플리케이션 나머지가 신뢰하는 세션을 발급합니다. 이 책임을 한 곳에 두면 각 라우트가 로그인된 사용자의 자체 해석을 만들어내는 것을 막습니다.
supastack은 신원과 세션 관리를 위해 Better Auth를 구성합니다. 애플리케이션 코드는 보호된 경계에서 세션을 해석하고 워크스페이스에 연결합니다. 인터페이스는 유용한 액세스 상태를 보여줄 수 있지만 클라이언트 상태가 작업이 인가되었다는 증거가 되어서는 안 됩니다.
그 규칙은 제품이 출시하는 모든 표면에서 유지되어야 합니다. 웹, 모바일, 데스크톱 클라이언트는 같은 신원 결정을 세 번 구현하는 대신 소비해야 합니다 — “로그인됨”의 세 가지 해석이 계정 버그가 나오는 곳입니다.
로그인 방법을 신중하게 고르세요
모든 방법은 마찰을 공격 표면과 외부 의존성과 맞바꿉니다. 비밀번호는 재설정 플로와 속도 제한이 필요합니다. 매직 링크와 일회용 코드는 이메일 도달성에 의존합니다. OAuth는 Google, GitHub, Apple 같은 프로바이더에 신원을 위임합니다 — 그리고 그들의 장애, 동의 화면, 콜백 규칙을 상속받습니다.
supastack은 이를 Better Auth를 통해 — 이메일 OTP, 비밀번호, 매직 링크, OAuth, 그리고 사용 가능한 2단계 인증과 패스키 — 하나의 신원 결정 뒤로 구성합니다. 사용자층이 실제로 필요로 하는 가장 작은 세트를 출시하세요. 추가되는 각 방법은 또 다른 콜백 경로, 또 다른 실패 모드, 출시 전 검증해야 할 또 다른 플로입니다. 인증 가이드가 그 연결을 다룹니다.
한 사람이 두 가지 이상으로 로그인할 수 있을 때, 방법들이 어떻게 합쳐지는지 결정하세요. 같은 주소로 해석되는 Google 계정과 이메일 매직 링크는 두 개가 아니라 하나의 신원에 도착해야 합니다. 계정 연결 규칙은 신원 결정의 일부이며, 잘못 정하면 몇 달 뒤 신비롭게 사라진 데이터로 표면화되는 중복 사용자를 만듭니다.
세션이 중요한 자격 증명입니다
로그인 후 모든 요청이 나르는 것은 비밀번호가 아니라 세션입니다. 그 만료, 저장, 무효화 규칙이 실제 보안 태세를 정의합니다. 로그아웃 후에도 살아남는 세션이나 제거된 워크스페이스 멤버가 계속 쓸 수 있는 세션은, 아무리 멋진 로그인 화면도 고칠 수 없는 인증 실패입니다.
라이프사이클을 미리 결정하세요: 세션이 얼마나 사는지, 사용자가 활성 세션을 보고 취소할 수 있는지, 비밀번호 변경, 이메일 변경, 워크스페이스 제거가 세션에 무엇을 하는지. 세션 관리가 킷에 모듈로 존재하는 것은 바로 이 결정들이 미루기 쉽고 나중에 끼워 넣기 비싸기 때문입니다.
세션을 요청된 레코드에 연결하세요
로그인되어 있다고 모든 레코드에 대한 액세스가 부여되지는 않습니다. 서버에서 사용자의 워크스페이스를 해석하고 그 범위를 읽기와 변경에 포함하세요. 작업 식별자나 복구 링크는 작업에 대한 참조이지 그것을 가져올 허가가 아닙니다 — 워크스페이스 경계 포스트가 경계의 그 측면을 자세히 다룹니다.
범위를 고정된 순서로 해석하세요: 세션을 인증하고, 멤버십을 로드한 뒤, 그 워크스페이스 컨텍스트로 읽거나 씁니다 — 절대 반대 순서가 아닙니다. 미들웨어는 익명 방문자를 리다이렉트할 수 있지만 작업을 인가할 수는 없습니다. 검사는 레코드가 건드려지는 서버 액션이나 라우트 핸들러에 속합니다.
계정에는 시작만이 아니라 라이프사이클이 있습니다
프로비저닝은 그 경계의 첫 테스트입니다. 사용자가 가입할 때 이어지는 워크스페이스와 소유권 레코드는 두 번 이상 생성해도 안전해야 합니다 — 라이프사이클 훅은 프로바이더, 재시도, 지원 도구에 의해 재생될 수 있습니다. 중복 이벤트는 중복 조직이 아니라 무작업이어야 합니다.
라이프사이클의 끝도 같은 주의를 받을 만합니다. 이메일 변경, 비밀번호 재설정, 멤버 제거, 계정 삭제, 데이터 내보내기는 각각 자체 남용 사례를 가진 작은 플로입니다 — 두 번 작동하는 재설정 링크, 팀원의 레코드를 새는 내보내기. supastack이 GDPR 내보내기와 세션 관리를 제공하는 이유입니다. 무엇 위에 만들든, 지루한 플로를 위한 예산을 잡으세요.
끝을 포함해 라이프사이클을 테스트하세요
성공적인 로그인 테스트는 유용하지만 불완전합니다. 유효하지 않은 자격 증명, 만료되거나 재사용된 인증 코드, 익명 요청, 워크스페이스 간 액세스를 실행하세요. 로그아웃이 세션을 무효화하고 돌아온 클라이언트가 이전에 인가된 화면을 사용해 보호된 작업을 계속할 수 없는지 검증하세요.
핸들러 테스트와 배포 수용을 구분하세요. 인메모리 어댑터는 Postgres 영속화나 프로바이더 콜백을 증명하지 않으면서 실제 인증 핸들러의 의미를 확립할 수 있습니다. 전체 로그인 여정이 작동한다고 주장하기 전에 구성된 오리진, 콜백 경로, 세션 복원, 로그아웃을 배포된 의존성으로 검증하세요.
- 유효하지 않은 자격 증명과 만료되거나 재사용된 인증 코드가 거부됩니다.
- 익명 및 워크스페이스 간 요청이 소유된 데이터를 받지 않습니다.
- 로그아웃이 세션을 무효화합니다 — 오래된 클라이언트는 계속 행동할 수 없습니다.
- 라이프사이클 훅이 재생될 때 프로비저닝된 레코드가 멱등을 유지합니다.
- 실제 프로바이더 콜백이 구성된 오리진에서 작동합니다 — 가정이 아니라 검증됨.
흔한 인증 질문
아래 질문들은 로그인 폼이 끝나고 시스템이 계속 작동해야 할 때 표면에 오릅니다.
- 미들웨어로 라우트 보호가 충분한가요? — 미들웨어는 편리한 리다이렉트이지 인가 계층이 아닙니다. 각 서버 액션과 라우트가 스스로 세션과 워크스페이스를 해석합니다. 페이지 수준 가드는 작업을 인가하지 않고 화면을 숨길 뿐입니다.
- 인증을 직접 만들까요, 라이브러리를 쓸까요? — 세션 의미는 SaaS가 차별화되는 곳이 거의 아닙니다. 명확한 모듈 경계 뒤의 Better Auth 같은 유지보수된 라이브러리는 중요한 결정 — 범위 지정, 라이프사이클 — 을 당신의 코드에 두면서 검증된 프리미티브를 줍니다.
- 세션과 워크스페이스는 어떤 관계인가요? — 세션은 사람을 식별하고, 워크스페이스는 그 사람이 건드릴 수 있는 레코드를 식별합니다. 모든 요청에서 서버에서 멤버십을 해석하고 클라이언트가 보낸 워크스페이스 ID는 절대 신뢰하지 마세요.
- B2B 고객은 인증에 무엇을 기대하나요? — 역할이 있는 팀 워크스페이스, OAuth 로그인, 세션 가시성과 취소, 감사 추적. 2단계 인증과 패스키는 관리자 역할에 점점 기대됩니다.
- 프로덕션에서 인증을 깨는 것은요? — 보통 가장자리입니다: 로컬에만 존재하는 콜백 URL, 두 번 프로비저닝하는 훅, 멤버십보다 오래 사는 세션. 시작뿐 아니라 플로의 끝을 테스트하세요.