[항해 취업코스] 개발자 취준 기록 5일차

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

 

세션 기반 인증 방식은 클라이언트에서 서버로 로그인 요청을 보낼 때, 서버가 해당 사용자의 인증 정보를 검증한 후 인증 성공 시 사용자의 세션 정보를 서버에 저장하고, 해당 세션의 고유한 식별자(세션 ID)를 클라이언트에게 반환합니다. 클라이언트는 이후의 요청에서 이 세션 ID를 서버에 전송하여 자신을 인증합니다. 

(문제점) 이러한 방식은 여러 대의 서버로 운영하는 경우, 처음 인증받은 서버와 다른 서버로 요청이 전달될 때, 해당 서버는 사용자의 세션 정보가 없어 인증을 실패하는 문제가 발생할 수 있습니다.

(해결) 이 문제를 해결하기 위한 방법 중 하나는 세션 데이터베이스를 사용하는 것입니다. 세션 데이터베이스는 모든 서버가 공통으로 접근할 수 있는 외부 저장소에 세션 정보를 저장하는 구조입니다. 이렇게 하면, 사용자의 세션 정보가 특정 서버에 종속되지 않고, 어느 서버에서든 세션 정보에 접근할 수 있게 됩니다. 따라서, 로드 밸런서를 통해 어떤 서버로 요청이 전달되더라도, 해당 서버는 공통 세션 데이터베이스에서 사용자의 세션 정보를 조회하여 인증을 처리할 수 있게 되는 것입니다. 서버 간 세션 정보의 일관성을 유지하고, 서버의 확장성과 가용성을 높이는 데에 효과적인 해결책입니다.

토큰 기반 인증 방식은 서버가 사용자 인증 후, 인증 토큰을 생성하여 클라이언트에게 전달합니다. 이 토큰에는 사용자의 식별 정보와 권한 등이 암호화되어 저장됩니다. 사용자는 이후 서버에 요청을 할 때마다 이 토큰을 Authorization 헤더에 포함시켜 전송합니다. 서버는 토큰의 유효성을 검증하고 요청을 처리합니다. 

+ JWT를 이용한 인증 방식의 장점을 설명해주세요.

세션을 서버에 저장할 필요가 없어 서버 리소스를 절약할 수 있습니다. 스케일 아웃이 용이하여 대규모 분산 시스템에 적합합니다. 

토큰이 탈취되면 보안상의 문제가 발생할 수 있습니다. 토큰의 유효기간 관리가 필요합니다. 

참조

 

 

---

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

쿠키란 웹 사이트에 접속할 때, 브라우저에 저장되는 key-value 형태의 작은 데이터 파일

어떤 데이터를 저장할까?
사이트에 대한 방문 이력, 검색 기록, 로그인 상태 등

쿠키의 특징

1. 브라우저 단위로 쿠키를 생성
: 예를 들어 크롬에서 저장된 쿠키는 사파리에서 사용할 수 없다.

2. 다른 도메인을 대신하여 쿠키를 발급할 수 없다.

3. 만료 시간까지 상태 정보를 유지합니다.

쿠키를 왜 사용할까요?

무상태성인 HTTP 특정상 사용자에게 맞춤형 서비스를 제공하는 것이 불가능합니다. 때문에 쿠키를 사용하여 로그인 상태를 관리한다면 웹 사이트 방문 시 사용자에게 효율적으로 서비스를 제공할 수 있습니다.

이러한 쿠키의 특성으로 인해 사용자는 장바구니 기능, 오늘 이 창을 다시 보지 않기, 로그인 유지 등의 기능을 사용할 수 있습니다.

그러나 쿠키는 브라우저에 저장되어 있기 때문에 탈취당할 위험이 큽니다. 쿠키를 탈취당한다면 쿠키 값을 임의로 바꾸거나, 다른 사용자가 대신 로그인할 수도 있습니다. 이러한 문제점을 해결하기 위해 세션과 함께 사용할 수 있습니다. 

세션이란?

웹 상에서 사용자의 상태를 유지하고 관리하기 위한 기술입니다. 기본적으로 클라이언트에게 임의의 세션 ID를 세션 쿠키를 통해 부여하며, 이 세션 ID를 외부 저장소의 키로 사용하여 클라이언트의 상태를 추적합니다. 클라이언트의 요청에 따라 이 키에 매핑된 값을 변경함으로써, 사용자의 상태 정보를 유지하게 됩니다.

세션의 주요 목적은 웹 사이트 이용 시 사용자 정보를 안전하게 서버 측에 저장하여 관리하는 것입니다. 이는 쿠키에 사용자의 세션 ID 이외의 정보를 저장하지 않음으로써 정보의 안정성을 확보할 수 있습니다. 즉, 사용자의 민감한 정보는 서버에 저장되며, 클라이언트 측에는 해당 정보에 접근할 수 있는 세션 ID만이 존재하게 됩니다.

하지만, 이러한 세션 기반 방식은 몇 가지 단점을 가집니다. 첫째, 클라이언트에서 사용자 정보에 대한 처리를 할 경우 처리 속도가 저하될 수 있습니다. 둘째, 사용자 정보를 서버에 저장해야 하므로 서버의 저장 공간에 대한 비용이 증가할 수 있습니다.

요약하자면, 세션은 웹에서 사용자의 상태를 안전하고 효율적으로 관리하기 위한 기술이지만, 처리 속도 저하와 서버 저장 공간 비용 증가와 같은 단점도 존재합니다.

로컬 스토리지란?

만료기간이 존재하지 않으며 페이지를 변경하거나 브라우저를 닫아도 반 영구적으로 유지되는 저장소를 의미합니다.

참조

https://www.youtube.com/watch?v=XgcCkcKGbys

---

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

RESTful API는 웹 서비스 설계에 널리 사용되는 아키텍처 스타일입니다. REST는 Representational State Transfer의 약자로, 자원(Resource)의 표현(Representation)에 의해 상태(State)를 전달(Transfer)한다는 의미를 담고 있습니다. RESTful API를 사용하면, 웹 상의 데이터와 상호작용하는 방식이 단순화되며, 이해하기 쉽고 사용하기 편리해집니다.

기본 원리

RESTful API의 핵심 원리는 자원(Resource), 메서드(Method), 메시지(Message)의 세 가지 요소로 구성됩니다.

1. 자원(Resource): REST는 웹 상의 모든 것을 자원으로 간주합니다. 예를 들어, 문서, 이미지, 서비스 처리 결과 등이 될 수 있으며, URI(Uniform Resource Identifier)를 통해 해당 자원을 고유하게 식별합니다.
2. 메서드(Method): 자원에 대한 행위는 HTTP 메서드(GET, POST, PUT, DELETE 등)를 통해 정의됩니다. 이 메서드들은 각각 자원을 조회, 생성, 수정, 삭제하는 표준화된 방식을 제공합니다.
3. 메시지(Message): 클라이언트와 서버 간의 요청(Request)과 응답(Response)에 포함된 정보입니다. HTTP 헤더와 바디를 통해 데이터 형식, 인증 정보 등을 전달합니다.

특징

RESTful API는 다음과 같은 특징을 가집니다.

• 무상태성(Stateless): 각 요청은 독립적이며, 서버는 클라이언트의 상태를 저장하지 않습니다. 이는 서버 설계를 간단하게 하고, 확장성을 높입니다.
• 캐시 처리 가능(Cacheable): RESTful API 응답은 캐시될 수 있어야 합니다. 이를 통해 네트워크 지연 시간을 줄이고, 서버 부하를 감소시킬 수 있습니다.
• 계층화(Layered System): 클라이언트는 중간 서버를 통해 자원에 접근할 수 있습니다. 이러한 계층화는 보안, 로드 밸런싱, 암호화 계층 등을 추가할 수 있는 유연성을 제공합니다.
• 일관된 인터페이스(Uniform Interface): RESTful API는 일관된 인터페이스를 통해 자원에 접근합니다. 이는 API의 사용법을 쉽게 만들고, 코드의 재사용성을 높입니다.

+ RestfulAPI의 단점은 무엇인가요?

참조

 

---

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

HTTP 메서드는 웹 상에서 클라이언트와 서버 간의 상호작용을 정의하는데 사용되는 명령어입니다. 각각의 메서드는 다른 유형의 액션을 나타내며, RESTful API 디자인에서 중요한 역할을 합니다. 중요도는 사용 빈도와 API 설계에서의 역할에 따라 다르게 평가될 수 있지만, 일반적으로 가장 널리 사용되고 핵심적인 메서드 순으로 나열해 보겠습니다.

저의 프로젝트에서 사용된 빈도 수와 일반적으로 가장 널리 사용되고 핵심적인 메서드 순서로 중요하다고 생각했습니다.

1. GET: 리소스를 조회하는 데 사용됩니다. GET 요청은 데이터를 가져오기만 하며, 서버의 상태를 변경시키지 않아야 합니다(멱등성). 가장 기본적이고 널리 사용되는 HTTP 메서드입니다.
2. POST: 새로운 리소스를 생성하거나 데이터를 서버로 전송할 때 사용됩니다. 예를 들어, 폼 데이터 제출이나 파일 업로드 시 주로 사용됩니다. POST는 서버의 상태를 변경시킬 수 있으며, 멱등성이 없습니다.
3. PUT: 기존 리소스를 대체하거나 존재하지 않는 경우 새 리소스를 생성하는 데 사용됩니다. PUT 요청은 주어진 URI에 대한 리소스의 상태를 완전히 대체하므로, 멱등성을 가집니다.
4. DELETE: 지정된 리소스를 삭제하는 데 사용됩니다. DELETE 요청은 해당 리소스를 제거함으로써 서버의 상태를 변경시키며, 멱등성을 가집니다.
5. PATCH: 리소스의 부분적인 수정을 위해 사용됩니다. PATCH는 PUT과 비슷하지만, 전체 대신 리소스의 일부만 업데이트하는 데 초점을 맞춥니다. 멱등성은 구현 방법에 따라 다를 수 있습니다.
6. OPTIONS: 웹 서버에서 지원하는 메서드를 확인하기 위해 사용됩니다. 주로 CORS(Cross-Origin Resource Sharing)의 사전 요청 처리에 사용되며, 서버가 어떤 HTTP 메서드를 지원하는지 알려줍니다.
7. HEAD: GET과 유사하지만, 본문(body) 없이 헤더(header)만 반환됩니다. 리소스의 메타데이터를 가져올 때 사용되며, 멱등성을 가집니다.

+ HTTP 메서드 PUT과 PATCH의 차이점에 대해 설명해주세요

HTTP 메서드인 PUT과 PATCH는 모두 리소스를 서버에 업데이트하는 데 사용되지만, 사용 목적과 방식에서 차이가 있습니다.

PUT 메서드는 대상 리소스의 전체 교체를 목적으로 합니다. 즉, PUT 요청을 할 때는 해당 리소스의 현재 상태와 관계없이 요청의 본문(body)에 포함된 데이터로 리소스를 완전히 대체하게 됩니다. 만약 업데이트하려는 리소스가 서버에 존재하지 않으면, PUT 요청은 새 리소스를 생성할 수도 있습니다. 이 과정에서 요청 본문에 포함된 데이터는 대상 리소스의 새로운 전체 상태를 반영해야 합니다.

PATCH 메서드는 리소스의 부분적인 수정을 위해 사용됩니다. PATCH 요청은 전체 리소스를 대체하는 것이 아니라, 변경하고자 하는 부분만을 전달하여 해당 부분만을 수정합니다. 이는 특히 리소스의 일부만 변경하고자 할 때 더 효율적이며, 네트워크 대역폭을 절약할 수 있습니다. PATCH는 리소스의 일부분만을 업데이트하는 경우에 사용하기에 적합하며, 서버는 요청된 변경 사항만을 리소스에 적용합니다.

요약하자면, PUT은 리소스의 전체 교체를 위해 사용되며, PATCH는 리소스의 일부분만을 수정하기 위해 사용됩니다. 따라서, 리소스의 일부분만 변경하고자 할 때는 PATCH가, 전체 리소스를 업데이트하거나 새로 생성하고자 할 때는 PUT이 더 적합합니다.

+ 본인의 프로젝트에서 1번에서 답변해주신 METHOD가 어떻게 적용되어있는지 예시를 들어 설명해주세요.

 

참조