인가

보통 인가 방식은 크게 3가지가 있다.

1. 쿠키 방식

장점

• 사용자의 인증 정보를 클라이언트가 관리하기 때문에 서버 부하가 적다.
• 인증 상태를 서버가 관리하지 않고 매번 클라이언트의 인증 정보를 담은 쿠키의 요청을 받을 때 처리하므로 Stateless하다

단점

• 클라이언트(사용자)가 쉽게 쿠키에 담긴 인증 정보를 위조할 수 있다.
• 쿠키의 데이터 크기가 제한적이고, 또 크기가 커진다면 네트워크 부하가 심해진다.

2. 세션 방식

장점

• 서버에서 인증 정보를 관리하기 때문에 보안상 훨씬 안전하다
• 한 사용자의 디바이스별 인증을 관리할 수 있다.
• 하나의 계정 공유를 관리할 수 있다.
• 비정상적인 접근 신고가 들어오면, 서버에서 판단하여 해당 세션을 삭제해서 바로 로그아웃시킬 수 있다.

단점

• 확장성 문제:

  세션 정보가 서버에 저장되기 때문에 서버의 메모리나 데이터베이스 리소스를 소비한다. 사용자가 많아질수록 서버의 리소스 사용량이 증가하여 확장성이 떨어질 수 있다.
  특히 분산 시스템에서는 여러 서버 간에 세션 정보를 동기화해야 하므로 부하가 증가하거나 복잡해질 수 있다.

• 상태 유지 문제:

  세션 방식은 서버가 클라이언트의 상태를 유지해야 한다. 이는 서버가 상태 정보를 관리하는 추가적인 책임을 갖게 되고, 이를 위해 더 많은 메모리와 리소스를 소모하게 된다.
  무상태 아키텍처(RESTful API 등)와 잘 맞지 않기 때문에, 이런 아키텍처에서는 세션 기반 방식이 부적합할 수 있다.

• 보안 위험:

세션 하이재킹(Session Hijacking):

공격자가 세션 ID를 탈취하면 사용자의 계정에 접근할 수 있다.

세션 고정(Session Fixation):

공격자가 미리 생성한 세션 ID로 사용자를 로그인시키는 방식의 공격이 가능하다.

세션 타임아웃:

사용자의 보안을 위해 세션에 만료 시간을 설정해야 하지만, 사용자가 세션 타임아웃을 불편하게 느낄 수 있다.

• 클라이언트 디펜던시:

  세션 쿠키는 클라이언트가 브라우저에서 지원해야 한다. 만약 사용자가 쿠키를 비활성화하면 세션 관리가 어려워진다.
  쿠키를 통해 세션 정보를 전달하는 경우, HTTPS를 사용하지 않으면 정보가 도청될 위험이 있다.

• 복잡성 증가:

  세션을 효과적으로 관리하려면 추가적인 코드와 로직이 필요하다. 예를 들어, 로그아웃 시 세션을 올바르게 정리하거나 타임아웃 처리를 해야 하는 등 세션 관리가 복잡해질 수 있다.
  캐시 서버나 데이터베이스를 활용한 세션 저장소 구현 시, 시스템 아키텍처가 더 복잡해질 수 있다.

3. JWT 방식

JWT(Json Web Token)이란?

Json 객체에 인증에 필요한 정보들을 담은 후 비밀키로 서명한 토큰으로, 인터넷 표준 인증 방식이다.
공식적으로 인증(Authentication) & 권한허가(Authorization) 방식으로 사용된다.

장점

• 무상태(Stateless) 및 확장성:

  JWT는 서버가 상태를 관리하지 않기 때문에 확장성이 뛰어나다. 모든 인증 정보가 토큰에 포함되어 있으므로 서버는 세션 정보를 저장하거나 관리할 필요가 없다.
  분산 시스템에 적합하며, 로드 밸런싱 및 확장 시에도 효율적!

• 빠른 성능:

  인증 요청 시 서버가 세션 데이터를 조회할 필요 없이 토큰을 검증하면 되기 때문에 성능이 더 좋다. 이는 특히 대규모 애플리케이션에서 이점이 된다.

• 자체 포함(Self-contained):

  JWT는 페이로드에 사용자 정보와 메타데이터를 포함하고 있기 때문에 추가적인 데이터베이스 조회 없이도 인증된 사용자 정보를 사용할 수 있다.
  사용자 정보 및 권한을 쉽게 파악할 수 있어, 일부 애플리케이션에서는 이를 사용해 요청을 처리할 때 효율적이다.

• 다양한 클라이언트 지원:

  웹 애플리케이션뿐만 아니라 모바일 앱, 서버 간 통신 등 다양한 클라이언트에서 쉽게 사용할 수 있다.
  클라이언트와 서버 간의 토큰 전달이 HTTP 헤더를 통해 이루어져 RESTful API와 잘 맞다.

• 편리한 통합 및 표준화:

  JWT는 널리 사용되는 표준(RFC 7519)으로, 다양한 프로그래밍 언어와 프레임워크에서 쉽게 구현할 수 있다.
  여러 서비스에서 동일한 토큰을 사용할 수 있어 SSO(Single Sign-On) 구현에 적합하다.

단점

• 토큰 크기:

  JWT는 일반적으로 Base64로 인코딩되어 있어 크기가 비교적 크며, 특히 페이로드에 많은 데이터를 포함하면 크기가 더 커진다. 이는 네트워크 비용을 증가시킬 수 있다.
  토큰이 클수록 모바일 환경이나 네트워크 대역폭이 제한된 환경에서 부담이 될 수 있다.

• 만료 전 토큰 취소 어려움:

  JWT는 발급 후 만료 기간이 지나기 전까지는 유효하므로, 사용자가 로그아웃하거나 토큰을 강제로 무효화해야 하는 경우 관리가 어렵다.
  이를 해결하기 위해 별도의 블랙리스트를 구현해야 하며, 이로 인해 시스템 복잡성이 증가할 수 있다.

• 보안 문제:

  JWT는 페이로드를 암호화하지 않고 기본적으로 인코딩만 하기 때문에, 민감한 정보를 포함해서는 안 된다. 누구나 디코딩하여 페이로드 내용을 볼 수 있다.
  토큰이 탈취되면 유효 기간 동안 공격자가 사용자의 권한을 사용할 수 있다. 따라서 HTTPS를 반드시 사용해야 하고, 적절한 토큰 만료 시간과 보안 대책을 적용해야 한다.

• 페이로드 조작:

  토큰이 클라이언트 측에 저장되기 때문에 조작 시도가 있을 수 있다. 다만, 서명이 유효하지 않으면 서버에서 이를 감지할 수 있다.
  악의적인 사용자가 토큰을 변조하려 해도 기본적으로 서명 검증을 통해 방지할 수 있지만, 서명 키 관리에 신경써야 한다.

• 리프레시 토큰 관리:

  JWT는 짧은 만료 시간을 사용하는 경우가 많아, 리프레시 토큰을 사용하여 새 토큰을 발급해야 한다. 이 과정에서 리프레시 토큰의 보안 관리와 관련된 추가적인 복잡성이 발생할 수 있다.