// docs / baas security / auth0 hardening

Auth0 security checklist: 22 ข้อ

Auth0 เป็นแพลตฟอร์ม identity-as-a-service ที่มีพื้นผิวมหาศาล — application, API (resource server), tenant, action, rule (เก่า), connection และ grant การตั้งค่าผิดของอันใดอันหนึ่งคือการ bypass auth checklist นี้คือ audit 22 ข้อข้าม application, callback / logout allowlist, token และการหมุน refresh, custom action, RBAC, การตรวจจับความผิดปกติ และการ monitor ต่อเนื่อง แต่ละข้อตรวจสอบได้ใน Auth0 Dashboard ในเวลาไม่ถึง 10 นาที

สำหรับ checklist ที่เทียบเท่าบน Clerk โปรดดู Clerk security checklist สำหรับเบื้องหลังว่าทำไมการตั้งค่าผิดชั้น identity จึงเป็นจุดบอดของ AI tool โปรดดู ทำไมเครื่องมือ AI Coding ทิ้งช่องโหว่ด้านความปลอดภัย

ประเภท application และประเภท grant

ประเภท application และประเภท grant ที่เปิดใช้คือการตั้งค่าที่ส่งผลกระทบสูงสุดใน Auth0 การทำผิดเปิด class ของการโจมตีที่ไม่มีโค้ด frontend ปริมาณใดสามารถปิดได้

ใช้ Application Type = Single Page Application สำหรับแอปเบราว์เซอร์เท่านั้น และ Regular Web Application สำหรับแอป server-rendered ประเภทที่ผิดอนุญาตประเภท grant ที่ผิด — เช่น Regular Web App ที่มี SPA grant เปิดใช้ flow Implicit ที่ไม่มี PKCE ซึ่งทำให้ token รั่วไหลผ่าน URL fragment
ปิดประเภท grant Implicit บนทุก application Dashboard → Application → Advanced Settings → Grant Types → uncheck Implicit Implicit flow คืน token ใน URL fragment ซึ่งถูก log ในประวัติเบราว์เซอร์และ analytics ใช้ Authorization Code with PKCE แทน
ปิด Password grant เว้นแต่คุณมีความต้องการที่บันทึก Resource Owner Password Credentials (ROPC) grant ต้องการให้คุณจัดการ password ของผู้ใช้ด้วยตนเอง — ทำลายส่วนใหญ่ของสิ่งที่คุณซื้อ Auth0 มา ปิดมันเว้นแต่จะ integrate ระบบเก่า
เปิดใช้ Authorization Code with PKCE บนทุก client สาธารณะ Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = enabled PKCE จำเป็นสำหรับแอปมือถือและ SPA เพื่อป้องกันการดักจับ code

Callback และ logout URL allowlist

Open redirect บนเส้นทาง callback ของ OAuth เป็น primitive การขโมย token allowlist ของ Auth0 คือการป้องกันเพียงอย่างเดียวของคุณ

ตั้งค่า Allowed Callback URLs เป็นเส้นทาง callback production ที่แน่นอนของคุณ — ไม่มี wildcard https://yourapp.com/callback ไม่ใช่ https://yourapp.com/* Callback ที่มี wildcard ให้ผู้โจมตี redirect token ไปยัง subpath ใด ๆ บนโดเมนของคุณ
ตั้งค่า Allowed Logout URLs เป็นรายการจำกัด กฎเดียวกัน: URL ที่ชัดเจนเท่านั้น Open logout redirect ให้ผู้โจมตีสร้างหน้า phishing ที่ดูเหมือนสถานะหลัง logout ของคุณ
ตั้งค่า Allowed Web Origins เป็น origin production ของคุณเท่านั้น ใช้สำหรับ silent authentication (การต่ออายุ token ผ่าน iframe ที่ซ่อนอยู่) origin ที่มี wildcard ให้หน้าของผู้โจมตีดำเนินการ silent auth กับ tenant ของคุณ
ตั้งค่า Allowed CORS origins สำหรับ API endpoint ไม่ใช่ application Tenant Settings → Advanced → Allowed CORS origins ค่าเริ่มต้นคือว่าง (จำกัด); เพิ่มเฉพาะ origin ที่คุณควบคุมและชัดเจน

Token และการหมุน refresh

อายุ token, การหมุน refresh และ algorithm การเซ็นตัดสินขอบเขตการระเบิดของการรั่วไหล token ใด ๆ

เปิดใช้ Refresh Token Rotation Application → Refresh Token Settings → Rotation แต่ละ refresh ออก refresh token ใหม่และทำให้ตัวเก่า invalidate รวมกับการหมดอายุแบบ absolute สิ่งนี้จำกัดการขโมย token
ตั้งค่า Refresh Token Reuse Interval เป็น 0 (หรือต่ำที่สุดเท่าที่ความทนทาน replay ของคุณจะอนุญาต) ช่วง reuse ให้ token ถูกใช้สองครั้งในหน้าต่างเดียวกัน — ปิดมันเว้นแต่คุณมีเหตุผลเฉพาะที่จะเก็บไว้
ตั้งค่า Absolute Refresh Token Expiry เป็น 14-30 วัน ไม่ใช่ไม่จำกัด Application → Refresh Token Expiration → Absolute Expiration Auth0 ตั้งค่าเริ่มต้นเฉพาะ Inactivity ซึ่งหมายความว่า session ที่ idle สามารถคงอยู่เป็นปี
ตั้งค่า JWT Signature Algorithm เป็น RS256 Application → Advanced → OAuth → JsonWebToken Signature Algorithm RS256 ใช้การเซ็นแบบ asymmetric ดังนั้น client ไม่สามารถปลอม token ได้ ห้ามใช้ HS256 สำหรับ application ที่ client-facing
ตรวจสอบ claim aud และ iss บนทุก JWT ที่ API ของคุณได้รับ ใช้ Auth0 SDK อย่างเป็นทางการฝั่งเซิร์ฟเวอร์ — มันตรวจสอบสิ่งเหล่านี้โดยอัตโนมัติ การ parse JWT ด้วยมือมักข้ามการตรวจสอบ audience ซึ่งเป็นการ bypass auth

Action และ custom code

Auth0 Action (และ Rules เก่า) รันฝั่งเซิร์ฟเวอร์ตอนเข้าสู่ระบบและเหตุการณ์ lifecycle อื่น ๆ พวกมันเข้าถึง context ของ request ทั้งหมดได้ โค้ดที่ไม่ปลอดภัยที่นี่คือช่องโหว่ทั่ว tenant

ห้าม log event.user หรือ event.transaction เป็น object ทั้งก้อน สิ่งเหล่านี้มีที่อยู่อีเมล, ที่อยู่ IP และ PII อื่น ๆ ใช้ log ระดับ field เท่านั้นและ log เฉพาะสิ่งที่คุณต้องการ
ใช้ secret store สำหรับ API key หรือ webhook URL ใด ๆ Actions → Edit → Secrets ห้าม inline API key เป็น string literal ในโค้ด action — โค้ดมองเห็นได้สำหรับใครก็ตามที่มีสิทธิ์ editor Action บน tenant
Validate input ก่อนเก็บเป็น user_metadata หรือ app_metadata action self-service ที่เขียน event.body.name ลงใน user.user_metadata.display_name เป็น vector stored-XSS ถ้า frontend ของคุณ render field นั้นโดยไม่ escape

RBAC และ resource server

หากคุณใช้ Auth0 RBAC การ mapping role-to-permission คือชั้นการอนุญาตของคุณ ทำผิดและผู้ใช้ที่ผ่านการ authenticate คนใดสามารถเข้าถึง admin endpoint ได้

กำหนด Resource Server (API) อย่างชัดเจนใน Auth0 Dashboard ไม่ใช่ตามที่ต้องการ แต่ละ API มีตัวระบุ (audience), scope และการตั้งค่าการเซ็น หากไม่มี API ที่ลงทะเบียน token ทั้งหมดออกสำหรับ "Auth0 Management API" โดยปริยาย — audience ผิด
กำหนด Permission ต่อ API และต้องการพวกมันในโค้ดของคุณด้วย claim scope อย่าตรวจสอบการเป็นสมาชิก role ใน application logic ของคุณ; ตรวจสอบ scope ใน access token Scope เป็นกลไกการอนุญาต OAuth-native
ทดสอบว่าผู้ใช้ที่ผ่านการ authenticate ที่ไม่มี role / scope ที่จำเป็นไม่สามารถเข้าถึง endpoint ที่มีสิทธิ์พิเศษ เข้าสู่ระบบในฐานะผู้ใช้ปกติ พยายามเรียก POST /api/admin/users/delete response ต้องเป็น 403

การตรวจจับความผิดปกติและ tenant log

Auth0 ปล่อยเหตุการณ์สัญญาณสูง ตั้งค่าให้แจ้งเตือนทีมของคุณ ไม่ใช่แค่นั่งใน log buffer

เปิดใช้ Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling Dashboard → Security → Attack Protection แต่ละอันปิดเป็นค่าเริ่มต้นบนระดับฟรี; เปิดทั้งหมดสำหรับ production
Stream tenant log ไปยัง SIEM หรือ log ของ application ของคุณ Dashboard → Monitoring → Streams Auth0 เก็บ log เป็นเวลา 30 วันในแพ็กเกจส่วนใหญ่; การเก็บรักษาระยะยาวต้องการ stream เข้าระบบของคุณเอง
แจ้งเตือนเมื่อ fcoa (failed cross-origin auth) และ fp (failed login) พุ่งขึ้น การพุ่งของเหตุการณ์เหล่านี้ในหน้าต่างสั้นเป็น credential stuffing Route ไปยัง channel on-call ของคุณ

ขั้นตอนถัดไป

รัน FixVibe scan กับ URL production ของคุณ — check baas.clerk-auth0 แจ้ง Auth0 client secret ที่ bundle ใน JavaScript และ class การเปิดเผย identity-provider อื่น ๆ สำหรับเทียบเท่าบน Clerk โปรดดู Clerk security checklist สำหรับมุมมองภาพรวมข้าม BaaS provider อ่าน BaaS misconfiguration scanner