인증 연결 실습 참고

1. 이메일 인증
Supabase SSR의 브라우저·서버 클라이언트와 쿠키 갱신 구성을 현재 프로젝트 버전에 맞게 사용합니다. App Router의 cookies와 서버 경계를 확인합니다. 가입 요청 성공, 실제 이메일 확인, 로그인 세션, 앱의 가입 완료 상태를 구분합니다.

2. OAuth
앱에서 signInWithOAuth를 시작하고 PKCE callback에서 받은 code를 exchangeCodeForSession으로 교환하는 흐름을 확인합니다. 실제 설치 SDK와 SSR 안내를 확인합니다. 외부 복귀 주소는 서버에서 검증한 내부 경로만 허용합니다.

3. 공급자 주소
Google과 Kakao는 해당 제공자 설정을 확인합니다. Naver는 u-livet의 custom:naver 구조를 참고합니다. 개발자 앱에는 Supabase가 안내하는 제공자 callback을 등록합니다. Supabase에는 앱이 돌아올 로컬·운영 주소를 허용합니다. 두 주소를 혼동하지 않습니다.

4. Naver 정보 변환
naver-transform.mjs는 합성 JSON의 필드 변환 실습용입니다. 실제 userinfo 서버는 공급자 access token을 네이버 API로 검증하고, 응답의 최소 필드만 반환해야 합니다. 토큰과 응답 본문을 로그에 남기지 않습니다. 이메일 확인 상태를 임의로 true로 바꾸지 않습니다. 실제 가입 흐름은 동일 OAuth identity를 유지하며 사용자가 입력한 이메일을 확인한 뒤 가입을 완료합니다.

5. TOTP
native MFA의 등록, QR 또는 수동키 연결, 코드 검증, 재로그인 후 challenge 검증을 순서대로 확인합니다. 코드와 비밀키를 URL·로그·영구 저장소에 남기지 않습니다. AAL2와 데이터 소유권, 관리자 역할을 구분합니다.

6. 보호된 내보내기
서버에서 검증된 사용자와 AAL2를 확인한 후 schema.sql의 export_own_applications RPC를 호출하는 예시입니다. RPC도 AAL2를 확인하고 SECURITY INVOKER로 사용자 RLS를 유지합니다. 기본 신청 목록은 본인에게 AAL1에서도 보이므로 이 예시는 내보내기 작업에 추가 인증을 요구하는 교육용 정책입니다.

7. 확인 범위
이 자료는 설정과 구현의 참고 예시이며 실제 공급자 계정·SMTP 설정이 포함되지 않습니다. 강사는 수업 전에 새 테스트 프로젝트에서 최초 가입, 실패, 취소, 재로그인, MFA 전후의 직접 요청을 시험하고 기준 앱을 준비합니다.
