✅ [30편] 리액트 인증·인가(Auth) 구조 실전 가이드

로그인부터 권한 관리까지, 현업에서 실제로 쓰는 표준 구조 

다음 글 주제인 “리액트 사용자 상태 관리와 세션 유지 전략”으로 이어지기 전에, 이번 글에서는 리액트 개발자가 실제 서비스에서 가장 많이 실수하는 영역인 인증(Authentication)과 인가(Authorization)를 현업 기준으로 정리합니다. 이 글은 단순 개념 설명이 아니라, “왜 이 구조를 쓰는지 / 어떤 방식이 실제로 안전한지 / 어디서 실패하는지”를 중심으로 구성했습니다.

🟦 1. 왜 리액트 인증 글이 ‘저품질’로 판단되기 쉬울까?

애드센스 승인에서 인증 관련 글이 자주 실패하는 이유는 명확합니다.

• OAuth, JWT 이론만 나열
• 실제 코드 없이 개념 설명만 반복
• “로그인 구현 방법” 수준에서 끝남
• 실무에서 쓰지 않는 구조 소개
• 보안 책임을 프런트엔드에 떠넘김

이런 글은 검색 사용자에게 실질적인 도움을 주지 못하기 때문에
“가치가 낮은 콘텐츠”로 판단될 가능성이 큽니다.

👉 그래서 이번 글은 실제 서비스 운영 기준으로만 설명합니다.

🟦 2. 인증(Authentication)과 인가(Authorization)를 명확히 구분하자

이 두 개념을 구분하지 못하면 구조가 무너집니다.

✔ 인증(Authentication)

• “이 사용자가 누구인가?”
• 로그인, 토큰 발급

✔ 인가(Authorization)

• “이 사용자가 이 기능을 써도 되는가?”
• 관리자/일반 사용자 구분, 권한 체크

👉 리액트는 인증을 ‘판단’하지 않습니다.
👉 리액트는 서버가 내려준 결과를 ‘표현’만 합니다.

이 전제를 잊으면 보안 사고로 이어집니다.

🟦 3. 현업에서 가장 많이 쓰는 인증 구조 (표준)

아래 구조는 스타트업부터 중견 서비스까지 가장 현실적인 방식입니다.

✔ 전체 흐름 요약

1. 로그인 요청 (ID/PW)
2. 서버에서 인증 성공
3. Access Token 발급 (짧은 만료)
4. Refresh Token 발급 (HttpOnly Cookie)
5. 프런트엔드는 Access Token만 사용
6. 만료 시 Refresh Token으로 재발급

🟦 4. 프런트엔드에서 “절대 하면 안 되는” 인증 실수

❌ 실수 1: localStorage에 토큰 저장

 

localStorage.setItem("token", accessToken);

이 방식은 XSS에 매우 취약합니다.
👉 실제 사고 사례 다수 존재

❌ 실수 2: 관리자 페이지를 조건부 렌더링만으로 보호

 

{user.isAdmin && <AdminPage />}

URL 직접 접근하면 그대로 노출됩니다.
👉 이건 UX 처리이지 보안이 아닙니다.

❌ 실수 3: 프런트에서 권한을 “판단”

 

if (user.role === "ADMIN") { // 관리자 API 호출 }

👉 권한 판단은 반드시 서버에서 해야 합니다.

🟦 5. 리액트에서 안전한 토큰 관리 구조 (현업 기준)

✔ 권장 구조 요약

항목방식

Access Token	메모리 상태 (Redux / Zustand)
Refresh Token	HttpOnly Cookie
권한 판단	서버
프런트 역할	상태 표현 + UX 제어

---

✔ Access Token 저장 예시 (Zustand)

 

const useAuthStore = create(set => ({ token: null, setToken: token => set({ token }), }));

• 새로고침 시 사라짐 → 보안성 ↑
• 필요하면 서버에서 재발급

🟦 6. 인가(Authorization)는 이렇게 처리해야 한다

✔ 서버에서 1차 차단 (필수)

 

403 Forbidden

✔ 프런트엔드에서는 UX 처리

 

if (!user) { return <Navigate to="/login" />; }

이 역할 분리가 실무에서 가장 중요합니다.

🟦 7. 라우트 단위 인증 보호 (실제 많이 쓰는 방식)

 

function PrivateRoute({ children }) { const user = useUser(); if (!user) return <Navigate to="/login" />; return children; }

 

<Route path="/mypage" element={ <PrivateRoute> <MyPage /> </PrivateRoute> } />

👉 구조가 명확하고 유지보수도 쉽습니다.

🟦 8. 로그인 상태 유지, 어디까지 해야 할까?

✔ 무조건 유지 ❌

✔ 필요한 경우만 유지 ⭕

실무 기준:

• 커머스, 금융 → 유지 필요
• 게시판, 정보 사이트 → 굳이 필요 없음

👉 유지 자체보다 “왜 유지하는지”가 중요

🟦 9. 인증 관련 기능 체크리스트 (애드센스 승인에 강한 포인트)

이 체크리스트는 실제 서비스 운영 기준입니다.

• ⭕ 토큰 저장 위치 설명됨
• ⭕ 프런트/서버 역할 구분 명확
• ⭕ 실수 사례 포함
• ⭕ 보안 책임 주체 명확
• ⭕ 코드 예시가 “의미 있음”
• ⭕ 초보자도 이해 가능

👉 이런 구조는 저품질 콘텐츠로 보기 어렵습니다.

 

🟦 결론

리액트 인증 구조는 “로그인 구현”이 아니라
서비스 신뢰성과 보안을 책임지는 핵심 설계 요소입니다.

이번 글에서 다룬 구조는

• 실제 현업에서 쓰이고
• 보안 사고 가능성을 낮추고
• 유지보수성이 높으며
• 초보자도 이해할 수 있는
  현실적인 표준 구조입니다.

다음 글에서는 이번 인증 구조를 바탕으로
“리액트 사용자 상태 관리와 세션 유지 전략”을
더 실무적으로 풀어 설명하겠습니다.