FixVibe

// docs / baas security / auth0 hardening

Auth0 보안 체크리스트: 22개 항목

Auth0는 거대한 표면을 가진 신원 서비스 플랫폼입니다 — 애플리케이션, API(리소스 서버), 테넌트, 액션, 규칙(레거시), 연결, 권한 부여. 이들 중 어느 하나의 잘못된 구성은 인증 우회입니다. 이 체크리스트는 애플리케이션, 콜백/로그아웃 허용 목록, 토큰 및 새로 고침 회전, 사용자 정의 액션, RBAC, 이상 탐지, 지속적인 모니터링에 걸친 22개 항목 감사입니다. 각 항목은 Auth0 대시보드에서 10분 이내에 검증할 수 있습니다.

Clerk의 동등한 체크리스트는 Clerk 보안 체크리스트를 참조하세요. 신원 계층 설정 오류가 AI 도구 사각지대인 이유에 대한 배경은 AI 코딩 도구가 보안 격차를 남기는 이유를 참조하세요.

애플리케이션 유형 및 권한 부여 유형

애플리케이션 유형과 활성화된 권한 부여 유형은 Auth0에서 가장 영향력 있는 설정입니다. 잘못 설정하면 프론트엔드 코드가 닫을 수 없는 공격 클래스가 열립니다.

  1. 브라우저 전용 앱에는 Application Type = Single Page Application을, 서버 렌더링 앱에는 Regular Web Application을 사용. 잘못된 유형은 잘못된 권한 부여 유형을 허용합니다 — 예: SPA 권한 부여가 활성화된 Regular Web App은 PKCE 없는 Implicit 흐름을 활성화하여 URL 조각을 통해 토큰을 유출합니다.
  2. 모든 애플리케이션에서 Implicit 권한 부여 유형 비활성화. 대시보드 → Application → Advanced Settings → Grant Types → Implicit 체크 해제. Implicit 흐름은 URL 조각으로 토큰을 반환하며, 이는 브라우저 기록과 분석에 로그됩니다. 대신 PKCE를 사용한 Authorization Code를 사용하세요.
  3. 문서화된 필요가 없는 한 Password 권한 부여 비활성화. Resource Owner Password Credentials(ROPC) 권한 부여는 사용자 비밀번호를 직접 처리해야 합니다 — Auth0를 구입한 이유 대부분을 무효화합니다. 레거시 시스템을 통합하지 않는 한 비활성화하세요.
  4. 모든 공개 클라이언트에서 PKCE를 사용한 Authorization Code 활성화. 대시보드 → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = 활성화. PKCE는 코드 가로채기를 방지하기 위해 모바일 앱과 SPA에 필요합니다.

콜백 및 로그아웃 URL 허용 목록

OAuth 콜백 경로의 오픈 리다이렉트는 토큰 도용 프리미티브입니다. Auth0의 허용 목록이 유일한 방어입니다.

  1. Allowed Callback URLs를 정확한 프로덕션 콜백 경로로 설정 — 와일드카드 없음. https://yourapp.com/*가 아닌 https://yourapp.com/callback. 와일드카드 콜백은 공격자가 도메인의 임의의 하위 경로로 토큰을 리다이렉트할 수 있게 합니다.
  2. Allowed Logout URLs를 유한한 목록으로 설정. 동일한 규칙: 명시적 URL만. 오픈 로그아웃 리다이렉트는 공격자가 로그아웃 후 상태처럼 보이는 피싱 페이지를 만들 수 있게 합니다.
  3. Allowed Web Origins을 프로덕션 오리진으로만 설정. 무음 인증(숨겨진 iframe을 통한 토큰 갱신)에 사용됩니다. 와일드카드 오리진은 공격자 페이지가 테넌트에 대해 무음 인증을 수행할 수 있게 합니다.
  4. API 엔드포인트용 Allowed CORS origins 설정(애플리케이션용이 아님). Tenant Settings → Advanced → Allowed CORS origins. 기본값은 비어 있음(제한됨)이며, 직접 통제하는 명시적 오리진만 추가하세요.

토큰 및 새로 고침 회전

토큰 수명, 새로 고침 회전, 서명 알고리즘은 모든 토큰 유출의 영향 범위를 결정합니다.

  1. Refresh Token Rotation 활성화. Application → Refresh Token Settings → Rotation. 각 새로 고침은 새 새로 고침 토큰을 발급하고 이전 토큰을 무효화합니다. 절대 만료와 결합하면 토큰 도용을 억제합니다.
  2. Refresh Token Reuse Interval을 0으로 설정(또는 재생 허용 한도가 허용하는 만큼 낮게). 재사용 간격은 토큰이 같은 윈도우에서 두 번 사용될 수 있게 합니다 — 특정 이유가 없는 한 끄세요.
  3. Absolute Refresh Token Expiry를 무한이 아닌 14-30일로 설정. Application → Refresh Token Expiration → Absolute Expiration. Auth0는 기본적으로 Inactivity만이며, 이는 유휴 세션이 수년간 지속될 수 있다는 의미입니다.
  4. JWT Signature Algorithm을 RS256으로 설정. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256은 비대칭 서명을 사용하므로 클라이언트가 토큰을 위조할 수 없습니다. 클라이언트 대면 애플리케이션에 결코 HS256을 사용하지 마세요.
  5. API가 받는 모든 JWT에 대해 audiss 클레임 확인. 서버 측에서 공식 Auth0 SDK를 사용하세요 — 자동으로 이를 확인합니다. 수동으로 만든 JWT 파싱은 일반적으로 청중 검증을 건너뛰며, 이는 인증 우회입니다.

액션 및 사용자 정의 코드

Auth0 Actions(및 레거시 Rules)는 로그인 및 기타 생명주기 이벤트에서 서버 측에서 실행됩니다. 전체 요청 컨텍스트에 접근할 수 있습니다. 여기의 안전하지 않은 코드는 테넌트 전체의 취약점입니다.

  1. event.user 또는 event.transaction을 전체 객체로 결코 로그하지 마세요. 이들은 이메일 주소, IP 주소, 기타 PII를 포함합니다. 필드 수준 로깅만 사용하고 필요한 것만 로그하세요.
  2. 모든 API 키 또는 웹훅 URL에 비밀 저장소 사용. Actions → Edit → Secrets. 액션 코드에 API 키를 문자열 리터럴로 인라인하지 마세요 — 코드는 테넌트에서 Action 편집기 접근 권한을 가진 누구에게나 보입니다.
  3. user_metadata 또는 app_metadata로 저장하기 전에 입력 확인. event.body.nameuser.user_metadata.display_name에 쓰는 셀프 서비스 액션은 프론트엔드가 그 필드를 이스케이프 없이 렌더링하면 저장된 XSS 벡터입니다.

RBAC 및 리소스 서버

Auth0 RBAC를 사용하면 역할에서 권한으로의 매핑이 권한 부여 계층입니다. 잘못 설정하면 인증된 모든 사용자가 관리자 엔드포인트에 접근할 수 있습니다.

  1. Auth0 대시보드에서 리소스 서버(API)를 즉석에서가 아니라 명시적으로 정의. 각 API에는 식별자(audience), 범위, 서명 설정이 있습니다. 등록된 API가 없으면 모든 토큰이 암시적 "Auth0 Management API"용으로 발급됩니다 — 잘못된 청중.
  2. API당 권한을 구성하고 코드에서 scope 클레임으로 이를 요구. 애플리케이션 로직에서 역할 멤버십을 확인하지 마세요. 액세스 토큰의 범위를 확인하세요. 범위는 OAuth 네이티브 권한 부여 메커니즘입니다.
  3. 필수 역할/범위가 없는 인증된 사용자가 권한 있는 엔드포인트에 접근할 수 없는지 테스트. 일반 사용자로 로그인하고 POST /api/admin/users/delete를 호출하려고 시도하세요. 응답은 403이어야 합니다.

이상 탐지 및 테넌트 로그

Auth0는 신호가 강한 이벤트를 발생시킵니다. 그것들을 로그 버퍼에만 두지 말고 팀에 알리도록 설정하세요.

  1. Attack Protection 활성화: Bot Detection, Brute Force, Suspicious IP Throttling. 대시보드 → Security → Attack Protection. 각각은 무료 티어에서 기본적으로 꺼져 있습니다. 프로덕션을 위해 모두 켜세요.
  2. 테넌트 로그를 SIEM 또는 애플리케이션 로그로 스트리밍. 대시보드 → Monitoring → Streams. Auth0는 대부분의 플랜에서 30일간 로그를 유지합니다. 장기 보존은 자체 시스템으로의 스트림이 필요합니다.
  3. fcoa(실패한 교차 오리진 인증) 및 fp(실패한 로그인) 급증 경보. 짧은 윈도우에서 이러한 폭발은 자격 증명 스터핑입니다. 호출 채널로 라우팅하세요.

다음 단계

프로덕션 URL에 대해 FixVibe 스캔을 실행하세요 — baas.clerk-auth0 검사는 JavaScript에 번들된 Auth0 클라이언트 비밀과 기타 신원 제공자 노출 클래스를 플래그합니다. Clerk의 동등한 것은 Clerk 보안 체크리스트를 참조하세요. BaaS 제공자 전반에 걸친 포괄적 관점은 BaaS 설정 오류 스캐너를 읽으세요.

// baas 표면 스캔

다른 누군가가 발견하기 전에 열린 테이블을 찾으세요.

프로덕션 URL을 입력하세요. FixVibe는 앱이 통신하는 BaaS 제공자를 열거하고, 공개 엔드포인트의 지문을 채취하며, 인증되지 않은 클라이언트가 무엇을 읽거나 쓸 수 있는지 보고합니다. 무료, 설치 불필요, 카드 불필요.

  • 무료 티어 — 월 3회 스캔, 가입 시 카드 불필요.
  • 수동 BaaS 지문 채취 — 도메인 소유권 확인 불필요.
  • Supabase, Firebase, Clerk, Auth0, Appwrite 등.
  • 모든 발견에 AI 수정 프롬프트 — Cursor / Claude Code에 그대로 붙여넣기.
Auth0 보안 체크리스트: 22개 항목 — Docs · FixVibe