[TIL] CS공부 7일차

세션 기반의 인증 방식과 토큰(JWT) 기반의 인증 방식에 대해 설명해 주세요

세션 기반 인증
 사용자의 인증 정보가 서버의 세션 저장소에 저장됩니다. 사용자에게는 저장된 세션 정보의 식별자인 Session ID를 발급되며 브라우저에 쿠키 형태로 저장되지만 실제 인증 정보는 서버에 저장됩니다.
 Cookie 헤더에 세션 ID만 담아 보내면 되므로 트래픽을 적게 사용하며, 모든 인증 정보를 서버에서 관리하므로 Session ID가 탈취되어도 서버 측에서 무효 처리가 가능합니다.

JWT 기반 인증
 인증 정보를 클라이언트가 직접 가지고 있는 방식으로, 토큰 형태로 브라우저의 로컬 스토리지나 쿠키에 저장합니다.  인증이 필요한 경우 클라이언트가 브라우저에서 가지고 있는 토큰을 추출하여 서버에 요청 시 함께 담아 보냅니다.
 JWT는 디지털 서명이 존재하기 때문에 토큰 내용 변조 여부나 만료시간 등 사용자 인증 정보를 서버에서 확인할 수 있습니다.

 

JWT 방식의 장점 / 단점

장점
JWT는 디지털 서명이 존재하기 때문에 토큰 내용 변조 여부나 만료시간 등 사용자 인증 정보를 서버에서 확인할 수 있습니다. 
 JWT는 데이터베이스 조회 없이 토큰을 검증할 수 있어 서버는 세션 상태를 유지할 필요가 없습니다.
 또한 다양한 언어와 플랫폼에서 지원되며, 필요에 따라 사용자 정의 클레임(claim)을 추가하여 확장할 수 있습니다.

단점
하지만 payload 부분이 별도로 암호화되어 있지 않아 중요한 정보를 담기 어렵고, 클라이언트가 토큰을 가지고 있기 때문에 탈취당하면 보안상 위험하다는 단점이 있습니다.

 

 

 

 

 

---

 

 

 

 

 

 

Client의 쿠키, 세션, 로컬 저장소에 대해 알고 계신 만큼 설명해 주세요

HTTP는 요청과 응답이 끝나면 무상태성으로 클라이언트 상태를 유지하지 않습니다. 이 때문에 클라이언트에서 사용자 인증 정보를 저장해 두고 필요할 때마다 서버에 담아 보내기 위해 쿠키나 웹 스토리지(세션, 로컬) 방식을 사용합니다.

쿠키
쿠키는 사용자 인증 정보를 웹 브라우저에 저장하는 방식 중 하나로 사용자 인증에 대해 유효 시간을 명시할 수 있으며, 인증이 필요한 요청을 할 때 클라이언트는 브라우저에 저장하고 있는 쿠키를 HTTP 헤더에 담아 서버에 요청할 수 있습니다. 
쿠키는 클라이언트에서 자바스크립트로 조회할 수 있는데 쿠키를 탈취하려는 시도를 막기 위해 브라우저에서 쿠키에 접근할 수 없도록 쿠키 추가 시 HTTP Only Cookie 설정을 할 수도 있습니다.

세션 스토리지
클라이언트 측에서 데이터를 저장할 때 사용되며, 세선이 유지되는 동안에만 데이터를 저장합니다. 따라서 브라우저를 닫으면 데이터가 삭제되며, 주로 임시 데이터나 세션 관련 정보를 저장하는 데 사용됩니다.

로컬 스토리지
로컬 스토리지는 클라이언트 측에서 데이터를 브라우저에 영구적으로 저장하는 데 사용됩니다. 만료기간이 없으며 수동으로 삭제하지 않는 이상 계속해서 유지가 됩니다.

 

 

 

 

 

---

 

 

 

 

 

 

 

Restful API에 대해 알고 계신 만큼 설명해 주세요

 

Restful API는 REST API의 설계 원리를 따르는 시스템을 의미합니다. 

REST (Representational State Transfer)
하나의 HTTP URI는 하나의 고유한 자원(Resource)을 대표하도록 설계하는 전송방식으로,
HTTP Method(POST, GET, PUT, PATCH, DELETE 등)을 통해 서버에서 데이터 자체를 전송하며, 이를 통해 서버와 클라이언트의 역할을 명확하게 분리할 수 있습니다.

Controller가 REST 방식으로 처리하기 위한 것임을 명시하기 위해 @RestController 어노테이션을 사용합니다.

 

REST API의 단점

제가 느낀 바로는 서버와 클라이언트를 별도의 프레임워크를 이용하여 분리하면, 서버에서는 클라이언트가 필요로 하는 데이터만 반환하면 되므로 페이지 리다이렉트를 클라이언트쪽에서 처리하여 불편함이 없었습니다.
하지만 템플릿 엔진과 Restful API 방식을 혼합해서 사용할 경우, 데이터 반환과 동시에 리다이렉트를 하기가 어려워 필요에 따라 클라이언트쪽에서 javascript 언어로 브라우저 화면을 교체하거나 일반 컨트롤러를 생성하여 페이지 네비게이터 역할만 하도록 해야 해서 어려움이 있었습니다.

 

 

 

 

---

 

 

 

 

 

HTTP METHOD에 대해 아는 만큼, 중요하다고 생각하는 순서로 설정해 주세요

HTTP Method는 주로 RESTful 한 웹 서비스에서 클라이언트가 서버에 요청을 보낼 때 사용되며, 어떤 동작을 수행해서 데이터를 전송할지 결정합니다.

종류는 대표적으로 POST, GET, PUT, PATCH, DELETE 등이 있으며,
개인적으로는 서비스에 있어서 중요도와 사용 빈도를 고려하여 GET, POST, PATCH, PUT, DELETE 순으로 중요하다고 생각합니다.

GET 메서드는 조회할 때 사용되는 메서드로 클라이언트에 보이는 대부분의 화면이 데이터베이스의 정보를 받아오는 것으로 이루어져 있어 가장 빈번하게 사용됩니다.

POST 메서드는 사용자가 입력한 데이터를 서버에 전송하여 새로운 리소스를 생성하는 데 사용됩니다. 이 메서드는 클라이언트가 서버로 데이터를 제출하고, 서버가 해당 데이터를 처리하여 사용자의 요구에 따라 데이터베이스에 반영하는 중요한 역할을 합니다.

PATCH와 PUT은 데이터를 업데이트할 때 사용하는 메서드로 사용자가 데이터 수정을 요청하면 서버는 해당 데이터를 처리하여 데이터베이스에 반영합니다.

DELETE 메서드는 기존에 존재하는 데이터를 삭제하는 역할로,  사용자가 삭제 요청을 보내면 서버는 데이터를 완전히 삭제하기보다는 일정 기간 동안 보관해야 할 경우가 있습니다. 
이런 경우 SOFT DELETE 방식을 고려하게 되는데 실제로 데이터를 삭제하는 대신 데이터의 상태를 변경하여 삭제된 것처럼 보이게 하는 방식입니다. 이러한 접근 방식은 데이터 복구나 추적이 필요한 경우에 유용하며 결국 DELETE 메서드는 보수적으로 사용하여 사용 빈도가 가장 낮다고 볼 수 있습니다.

 

PUT과 PATCH의 차이점에 대해 설명해 주세요

PATCH와 PUT은 모두 데이터를 업데이트할 때 사용되는 HTTP 메서드지만 다른 용도와 동작을 가지고 있습니다.

PUT 메서드
PUT 메서드는 데이터의 전체 필드를 수정합니다. 

PATCH 메서드
PATCH 메서드는 데이터의 일부 필드만 수정합니다.

예를 들어 사용자가 수정할 일부 필드 값만 담아 데이터 수정 요청을 하면 
PUT  메서드는 사용자가 요청하지 않은 필드값에 대해서는 null값으로 반영하여 업데이트하며
PATCH 메서드는 요청에 포함된 필드만 수정하기 때문에 나머지 필드 값은 기존 값을 그대로 유지할 수 있습니다.

 

PATCH 메서드의 단점

간단하고 일관된 리소스 업데이트를 위해 PUT을 사용하는 것이 더 권장됩니다.
PATCH의 경우 부분 수정할 데이터만 보내기 때문에 그에 따른 DTO를 생성해야 하며,
여러 PATCH 요청이 동일한 리소스에 대해 동시에 발생하는 경우 리소스의 현재 상태에 대한 기준점이 모호해 충돌이 발생하고 기존의 리소스가 손상될 가능성이 있습니다.

PATCH 메서드를 사용할 경우 이런 문제를 방지하기 위해 조건부 요청 처리를 통해 기존 리소스 상태를 확인한 후 수정 작업을 해야 합니다.

 

본인의 프로젝트에서 HTTP METHOD가 어떻게 적용되어 있는지 예시를 들어 설명해 주세요

GET 
게시글 목록, 유저 목록 등 주로 리스트 형태의 데이터를 반환하기 위해 사용하였습니다.

POST 
회원가입 및 로그인, 게시글, 댓글 작성 등 데이터를 새로 생성할 때 사용하였습니다.

PATCH
유저 정보 수정이나 게시글 및 댓글 수정 등 기존 데이터의 내용을 변경할 때 사용하였습니다. 수정하는 필드 외에 다른 필드는 기존 값을 유지할 수 있도록 PUT이 아닌 PATCH를 이용하였습니다.

DELETE 
게시글 및 댓글을 삭제할 때 DELETE 메서드를 사용하였습니다.
회원탈퇴의 경우 처음에는 DELETE 메서드로 구현하고자 했으나 연관된 데이터들이 많아서 SOFT DELETE 방식을 적용하여 탈퇴여부를 확인하는 필드를 추가 후 상태변경만 처리하는 방식으로 구현하였습니다.