HomeAboutMeBlogGuest
© 2025 Sejin Cha. All rights reserved.
Built with Next.js, deployed on Vercel
📦
하위 페이지 모음/
↗️
공개 페이지/
🗑️
휴지통/
1. 인증ㆍ인가

1. 인증ㆍ인가

1. 인증과 인가

서비스를 사용하다 보면 회원가입과 로그인을 자주 접하게 될 것이다. 회원가입과 로그인을 구현할 때 가장 핵심이 되는 내용이 바로 인증과 인가이다.
프론트엔드 개발에서 인증(Authentication)과 인가(Authorization)는 보안과 관련된 매우 중요한 개념이다. 이는 웹 애플리케이션에서 사용자의 신원을 확인하고, 적절한 권한을 가진 사용자만 특정 리소스나 기능에 접근하도록 제한하는 역할을 한다. 이 둘은 종종 혼동되기도 하지만, 분명하게 각각의 역할이 다르며, 각각의 과정에서 발생할 수 있는 보안 리스크도 다르다. 또한, 제대로 된 인증 및 인가 처리가 이루어지지 않으면 민감한 정보가 유출되거나 악의적인 사용자가 애플리케이션에 접근할 수 있다. 그럼 지금부터 인증과 인가에 대해 알아보도록 하자.

(1) 인증(Authentication)

인증은 사용자가 누구인지를 확인하는 과정이다. 일상 생활에서 주민등록증을 통해 신분을 입증하는 것과 같이 "당신이 누구인가?"를 묻는 단계이다. 인증을 통해 시스템은 사용자가 자신이 주장하는 인물이 맞는지 확인하게 된다. 인증에 대한 과정은 아래와 같다.
과정
과정
  1. 사용자 입력: 사용자는 사용자 이름(또는 이메일)과 비밀번호를 입력
  1. 서버 요청: 프론트엔드는 이 정보를 서버에 전달하여 사용자가 올바른지 확인
  1. 서버 검증: 서버는 데이터베이스에 저장된 정보와 사용자가 입력한 정보를 비교. 올바르다면, 사용자는 인증됨
  1. 토큰 발급: 성공적인 인증 후, 서버는 인증 토큰(예: JWT)을 발급 (이 토큰은 사용자가 이후의 요청에서 자신의 신원을 증명하는 데 사용됨)
  1. 토큰 저장: 프론트엔드는 이 토큰을 로컬 스토리지, 세션 스토리지, 또는 쿠키에 저장
인증은 애플리케이션이 신뢰할 수 있는 사용자인지를 결정하는 첫 번째 단계로, 일반적으로 사용자명과 비밀번호, 소셜 로그인, 2단계 인증 등의 방식으로 이루어진다.

(2) 인가(Authorization)

인가는 인증된 사용자가 특정 리소스나 기능에 접근할 수 있는 권한이 있는지를 확인하는 과정이다. 즉, "당신이 무엇을 할 수 있는가?"를 묻는 단계다. 관계자 외 출입 금지와 비슷한 맥락이라고 보면 된다. 인가에 대한 대략적인 과정은 아래와 같다.
과정
과정
  1. 인증된 요청: 인증된 사용자는 프론트엔드를 통해 서버에 요청을 보냄
  1. 권한 확인: 서버는 요청을 받은 후, 해당 사용자가 요청한 리소스에 접근할 권한이 있는지 확인
  1. 응답: 권한이 있다면 서버는 요청을 처리하고, 그렇지 않다면 접근이 거부됨
위와 같이, 인가는 인증된 사용자가 애플리케이션 내에서 어떤 기능을 사용할 수 있는지, 혹은 어떤 데이터에 접근할 수 있는지 결정하는 과정이다. 이때, 모든 사용자가 모든 기능에 접근할 수 있도록 허용하면 보안 리스크가 커지므로, 권한을 가진 사용자만 중요한 데이터에 접근할 수 있도록 제한하는 것이 좋다.

2. 프론트엔드에서의 인증과 인가

앞서 인증과 인가는 프론트엔드 개발에서의 보안과 관련된 매우 중요한 개념이라고 했다. 그렇다면 인증과 인가는 어떤 식으로 중요할까? 지금부터 그에 대해 알아보자.

(1) 중요성

프론트엔드에서 인증과 인가는 사용자 경험과 보안 측면에서 매우 중요하다. 사용자가 인증을 통해 애플리케이션에 로그인하고, 인가를 통해 올바른 권한으로 필요한 리소스에 접근할 수 있어야 한다. 잘못된 인증 및 인가 처리는 민감한 정보가 노출되거나, 부적절한 사용자가 중요한 기능에 접근하는 심각한 보안 문제가 발생할 수 있다.
만약 인증이 잘못 처리되면 누구나 애플리케이션에 접근할 수 있게 되어 불법적인 사용이나 데이터 유출 등의 보안 문제가 발생할 수 있다. 또한, 신뢰할 수 없는 사용자들이 중요한 기능을 이용하게 되면서 애플리케이션의 운영에 심각한 지장을 초래할 수 있다.
또한, 인가가 제대로 적용되지 않으면 권한이 없는 사용자가 민감한 정보나 중요한 기능에 접근할 수 있어 보안 문제가 발생할 수 있다. 예를 들어, 일반 사용자가 관리자 기능에 접근하거나, 제한된 데이터에 접근하게 되는 경우 심각한 결과를 초래할 수 있다.

(2) 보안 리스크

인증과 인가의 과정에서 적절한 보안 조치를 취하지 않으면 여러 보안 리스크에 노출될 수 있다. 이 리스크들은 사용자의 데이터를 탈취하거나, 악의적인 행위를 통해 시스템에 손상을 줄 수 있다. 그렇다면 지금부터 인증과 인가 과정에서 발생할 수 있는 주요 보안 리스크에 대해 알아보자.

1) 인증의 보안 리스크

 

2) 인가의 보안 리스크

 

3. 인증 상태 관리

웹 애플리케이션에서 인증 상태를 관리하는 것은 보안적으로 매우 중요한 문제이다. 인증 상태를 유지하기 위해 사용자는 로그인한 후 서버가 발급한 세션 ID나 토큰(JWT)을 클라이언트 측에 저장하여, 이후 요청 시 이를 서버에 보내 인증된 사용자인지를 확인한다. 이때 인증 정보를 저장할 수 있는 여러 가지 브라우저 저장소 옵션이 있으며, 각각의 장단점과 보안 위험이 다르다.

(1) 브라우저 저장소 옵션(localStorage vs sessionStorage vs 쿠키)

1) localStorage

localStorage는 브라우저 내에서 영구적으로 데이터를 저장하는 저장소이다. 페이지를 새로고침하거나 브라우저를 닫아도 데이터가 삭제되지 않으며, 명시적으로 삭제하지 않는 이상 브라우저에 계속 남아있는다.
  • 특징:
    • 데이터를 영구적으로 저장한다.
    • 최대 5~10MB의 데이터 저장이 가능하다.
    • 도메인 단위로 데이터를 관리한다.
    • 자바스크립트를 통해 읽기 및 쓰기가 가능하다.
    • 브라우저 간에 데이터를 공유하지 않는다.
  • 적합한 사용 사례:
    • 영구적으로 보관해야 하지만 민감하지 않은 데이터(예: 사용자 기본 설정, UI 상태 등)를 저장할 때 적합하다.
    • 인증 정보(JWT 등)를 저장하는 용도로는 부적합하다.

2) sessionStorage

sessionStorage는 사용자가 브라우저 탭을 닫거나 페이지를 떠날 때 자동으로 삭제되는 임시 저장소이다. 한 브라우저 탭 내에서만 데이터를 유지하며, 다른 탭이나 창과 공유되지 않는다.
  • 특징:
    • 세션 단위로 데이터를 저장하며, 브라우저 탭을 닫으면 데이터가 삭제된다.
    • 최대 5~10MB의 데이터 저장이 가능하다.
    • 자바스크립트를 통해 읽기 및 쓰기가 가능하다.
    • 도메인 단위로 데이터를 관리하지만, 각 브라우저 탭마다 별도의 저장 공간을 가진다.
  • 적합한 사용 사례:
    • 세션이 종료되면 자동으로 삭제해야 하는 비민감한 데이터 저장에 적합하다.
    • 인증 정보 저장에 권장되지 않으며, 로그아웃이나 세션 만료 시 토큰을 수동으로 삭제해야 한다.

3) 쿠키

쿠키는 클라이언트 측에 데이터를 저장하고, 각 요청마다 자동으로 서버에 전송되는 작은 데이터 저장소이다. 쿠키는 웹사이트가 서버와 클라이언트 간 상태를 유지하는 데 자주 사용된다.
  • 특징:
    • 데이터 크기 제한: 최대 4KB 정도의 작은 데이터만 저장이 가능하다.
    • 자동 전송: 각 HTTP 요청마다 자동으로 서버로 쿠키를 전송할 수 있다.
    • 쿠키에 만료 시간을 지정할 수 있으며, 만료 시간이 지나면 자동으로 삭제된다.
    • 쿠키는 도메인 및 경로 단위로 설정되며, 특정 서브 도메인이나 경로에만 전송되도록 제한할 수 있다.
  • 적합한 사용 사례:
    • 인증 정보를 저장할 때 가장 안전한 방법이다. httpOnly, secure 플래그를 사용하여 쿠키를 보호하고, 전송 시에는 반드시 HTTPS를 사용해야 한다.
    • 또한, 쿠키의 만료 시간을 설정하여 세션 만료 시 자동으로 인증 정보가 삭제되도록 할 수 있다.
저장소 유형
설명
장점
단점
localStorage
브라우저에 데이터를 영구적으로 저장. 브라우저를 닫아도 유지됨.
간편하게 데이터 저장 가능, 지속성 있음.
XSS 공격에 취약, 민감한 정보 저장 불가.
sessionStorage
브라우저 세션 동안만 데이터를 저장. 탭을 닫으면 삭제됨.
세션별로 구분되므로 특정 사용 사례에 유용
XSS 공격에 취약, 세션 종료 시 정보 삭제.
쿠키(Cookies)
데이터를 작고 간결하게 관리하며 서버와 자동으로 통신.
httpOnly와 secure 옵션으로 보안 강화 가능
CSRF 공격에 취약할 수 있음, 크기 제한.
 

(2) 각 저장소의 보안 위험, 인증 정보 저장 시 고려사항

1) localStorage와 sessionStorage의 보안 위험

  • XSS(Cross-Site Scripting) 공격에 취약: localStorage와 sessionStorage는 자바스크립트를 통해 접근할 수 있기 때문에, 웹사이트가 XSS 공격에 취약하다면 공격자가 클라이언트 측에서 인증 정보에 접근할 수 있다. 공격자가 악성 스크립트를 주입하여 사용자의 인증 토큰이나 세션 정보를 탈취할 수 있다.
  • 민감한 데이터 저장에 부적합: 두 저장소 모두 데이터를 자바스크립트로 쉽게 읽고 쓸 수 있기 때문에, 민감한 정보(예: JWT 토큰, 세션 ID 등)를 저장하기에는 적절하지 않다.
  • 데이터 만료 및 삭제 관리: localStorage는 자동으로 만료되지 않으므로, 세션이나 토큰이 만료된 경우 명시적으로 삭제해야 한다. 이를 적절히 관리하지 않으면 보안 리스크가 발생할 수 있다.

2) 쿠키(Cookie)의 보안 위험 및 고려사항

  • CSRF(Cross-Site Request Forgery) 공격: 쿠키는 브라우저에서 자동으로 서버에 전송되므로, 공격자가 피해자가 인증된 상태에서 서버에 요청을 보내도록 유도하는 CSRF 공격에 취약할 수 있다. 이를 방지하기 위해서는 CSRF 토큰을 사용하여 요청의 진위를 검증하는 메커니즘을 도입해야한다.
  • 쿠키 보호 설정: 인증 정보를 저장할 때는 쿠키에 다음과 같은 속성을 설정하여 보호해야 한다.
    • httpOnly: 자바스크립트에서 쿠키에 접근할 수 없도록 하여 XSS 공격에 대한 취약성을 줄인다.
    • secure: 쿠키가 HTTPS를 통해서만 전송되도록 보장하여 네트워크 상에서 탈취되는 위험을 줄인다.
    • SameSite: 쿠키가 제3자 사이트에서 전송되지 않도록 하여 CSRF 공격을 방지한다.
  • 데이터 암호화: 쿠키에 민감한 데이터를 저장할 경우, 반드시 데이터가 암호화되어 있어야 합니다. 암호화된 데이터는 탈취되더라도 복호화되지 않으면 쓸모가 없으므로, 보안성이 높아집니다.
요약하자면, 프론트엔드에서 인증 상태를 관리할 때는 쿠키를 이용하는 것이 보안적으로 가장 안전하다. httpOnly와 secure 속성을 적절히 설정하여 XSS 공격을 방지하고, 쿠키 전송 시 HTTPS를 사용하는 것이 기본적인 보안 수칙이다. localStorage와 sessionStorage는 인증 정보 저장에는 부적합하며, 인증 상태를 관리할 때는 쿠키를 사용하는 것이 좋다.

4. 프론트엔드에서의 인가 처리

프론트엔드에서 인가(Authorization)는 사용자의 권한에 따라 특정 리소스나 기능에 접근할 수 있도록 제어하는 중요한 보안 기능이다. 인가는 인증이 완료된 후, 사용자가 특정 자원에 접근할 수 있는 권한을 가졌는지를 확인하는 과정이다. 프론트엔드에서는 인가를 위해 조건부 렌더링과 보호된 라우트 등의 기법을 사용해, 권한이 없는 사용자가 특정 페이지나 기능을 사용할 수 없도록 제어할 수 있다.

(1) 조건부 렌더링

조건부 렌더링은 사용자의 권한 수준에 따라 특정 UI 요소를 렌더링할지 말지를 결정하는 기법이다. 이를 통해 프론트엔드에서 사용자가 접근할 수 있는 화면이나 기능을 제한할 수 있다.

1) 조건부 렌더링의 원리

조건부 렌더링은 주로 React, Vue.js와 같은 프론트엔드 프레임워크에서 많이 사용된다. 사용자의 인증 상태나 역할(Role)에 따라 특정 컴포넌트나 요소를 렌더링할지 여부를 결정하는 방식이다. 일반적으로 사용자의 JWT 토큰이나 사용자 역할 정보를 기반으로 렌더링할 내용을 결정한다.

2) 예시

다음은 React에서 조건부 렌더링을 사용하는 예시이다.
위 코드에서는 user.role이 admin인 경우에만 "Admin Settings" 버튼이 렌더링되고, 그 외의 사용자에게는 해당 기능이 차단되며 메시지가 표시된다.

3) 장점과 한계

  • 장점:
    • 사용자의 권한에 따라 UI를 동적으로 조정할 수 있어, UX가 개선된다.
    • 간단한 권한 관리가 가능하며, 프론트엔드 레벨에서의 빠른 제어가 가능하다.
  • 한계:
    • 조건부 렌더링은 UI에서만 기능을 제한할 뿐, 실제 백엔드 서버나 API에 대한 접근을 보호하지는 않는다. 악의적인 사용자는 개발자 도구를 통해 차단된 기능을 활성화하거나, API 호출을 직접 시도할 수 있다.
    • 백엔드에서 별도의 권한 검증이 이루어지지 않으면, 보안상 취약할 수 있다.
따라서, 조건부 렌더링은 UI 차원의 권한 관리를 제공할 수 있지만, 궁극적인 보안을 위해서는 서버 측에서의 검증이 반드시 병행되어야 한다.

(2) 보호된 라우트

보호된 라우트(Protected Route)는 사용자가 특정 페이지나 리소스에 접근할 때, 권한이 있는 사용자만 접근할 수 있도록 제한하는 방식이다. 보호된 라우트는 주로 프론트엔드의 라우팅(routing) 시스템을 사용하여 구현된다. 권한이 없는 사용자가 특정 라우트에 접근하려고 할 때, 다른 페이지로 리다이렉트하거나 접근을 차단할 수 있다.

1) 보호된 라우트의 원리

프론트엔드 프레임워크에서 라우터를 설정할 때, 사용자의 인증 상태와 역할에 따라 특정 경로를 보호할 수 있다. 예를 들어, 로그인된 사용자만 특정 페이지에 접근할 수 있도록 하고, 로그인되지 않은 사용자는 로그인 페이지로 리다이렉트하는 방식이다.

2) 예시(React Router)

다음은 React Router에서 보호된 라우트를 구현한 예시이다.
이 코드는 사용자가 인증되지 않은 경우 ProtectedRoute 컴포넌트에서 로그인 페이지로 리다이렉트시키고, 인증된 경우에만 대시보드 페이지를 렌더링합니다. 이렇게 하면 보호된 페이지에 대한 접근을 효과적으로 제어할 수 있다.

3) 보호된 라우트에서 권한 기반 접근 제어

보호된 라우트는 단순한 인증 외에도 권한(Role) 기반 접근 제어를 적용할 수 있다. 예를 들어, 관리자만 접근할 수 있는 페이지를 설정하려면 사용자 역할 정보를 기반으로 라우트를 보호할 수 있다.
이 예시는 user.role이 admin이 아닌 경우, "접근할 수 없음" 페이지로 리다이렉트하고, 관리자일 경우에만 자식 컴포넌트를 렌더링한다. 이를 통해 사용자의 권한에 따라 특정 경로를 보호할 수 있다.

4) 장점과 한계

  • 장점:
    • 사용자의 인증 상태나 역할에 따라 특정 페이지에 접근을 제한할 수 있어 보안적인 보호가 가능하다.
    • 사용자가 권한이 없을 경우 다른 페이지로 리디렉트하여, 권한 없는 사용자 접근을 방지할 수 있다.
  • 한계:
    • 보호된 라우트는 주로 프론트엔드에서 사용되므로, 악의적인 사용자가 직접 URL을 통해 서버로 요청을 보내는 경우를 완전히 막을 수 없다. 따라서 백엔드에서의 추가적인 권한 검증이 필수적이다.
    • 사용자가 URL을 직접 조작해 비인가된 접근을 시도할 수 있기 때문에, 서버 측에서 항상 사용자 권한을 확인하고 적절히 처리해야 한다.
 
프론트엔드에서 인가 처리는 사용자 경험과 보안 측면에서 매우 중요한 역할을 한다. 조건부 렌더링은 사용자의 권한에 맞춰 UI를 동적으로 변경할 수 있지만, 단순히 UI 차원의 권한 제한만으로는 보안이 완벽하지 않다. 보호된 라우트는 사용자가 접근할 수 있는 페이지를 제어하는 데 효과적이지만, 백엔드에서의 권한 검증과 함께 사용해야 전체 시스템의 보안을 유지할 수 있다. 결국, 프론트엔드에서의 인가 처리는 백엔드에서의 철저한 권한 검증과 함께 사용할 때 가장 안전하고 효과적인 보안 방식을 구현할 수 있다.
 
이처럼, 인증과 인가는 시스템 보안의 근간을 이루며, 각각의 과정에서 발생할 수 있는 보안 리스크를 이해하고 적절한 조치를 취하는 것이 중요하다. 인증은 사용자의 신원을 확인하는 것이고, 인가는 사용자가 접근할 수 있는 리소스나 기능을 결정하는 것이라는 점을 기억해야 한다. 시스템 설계 시 이 두 가지를 명확히 구분하여 관리하는 것이 보안성을 높이는 핵심이다.
function Dashboard({ user }) {
  return (
    <div>
      <h1>Welcome to Dashboard</h1>
      {user.role === 'admin' ? (
        <button>Admin Settings</button>
      ) : (
        <p>You do not have access to admin settings</p>
      )}
    </div>
  );
}
import { Navigate } from 'react-router-dom';

function ProtectedRoute({ user, children }) {
  if (!user || !user.isAuthenticated) {
    // 사용자가 인증되지 않았다면 로그인 페이지로 리다이렉트
    return <Navigate to="/login" />;
  }
  // 사용자가 인증되었다면 자식 컴포넌트를 렌더링
  return children;
}

// 라우터 설정
<Routes>
  <Route path="/dashboard" element={<ProtectedRoute user={user}><Dashboard /></ProtectedRoute>} />
  <Route path="/login" element={<Login />} />
</Routes>
function AdminRoute({ user, children }) {
  if (!user || user.role !== 'admin') {
    // 관리자가 아니라면 접근 차단
    return <Navigate to="/no-access" />;
  }
  return children;
}