기술 면접 준비

[기술면접] 네트워크 - 1/2

Lea Hwang 2023. 3. 23. 16:07

네트워크 기술면접을 따로 정리해 둔 것이 있지만(저작권의 이유로 비공개글), 공부하면 할수록 욕심이 생겨 추가로 정리를 해보려 합니다. 참고한 좋은 글을 통해 오늘도 성장합니다.

 

 

네트워크 질문 

다른 면접 스터디에서 네트워크 질문을 디테일하게 뽑아주셔서 출처를 남기고 가지고 오게 되었습니다. 

 

쿠키 vs 세션 vs JWT

  • 쿠키와 세션에 대해 설명해 주시고 둘의 차이점에 대해 말씀해 주세요.
  • 쿠키와 세션이 등장한 이유(사용하는 이유)
  • 쿠키란 무엇인가요?
    • 쿠키의 동작 순서에 대해 설명해 주세요
    • 쿠키가 실제로 사용되는 예시는 뭐가 있을까요
    • 쿠키 설정 옵션에 대해 아시는 것이 있다면 말씀해 주세요
  • 세션이 무엇인가요?
    • 세션의 동작 순서에 대해 설명해 주세요
    • 프로젝트에서 톰캣을 내렸다가 올렸을 때도 로그인 상태를 유지하려면 어떻게 할 수 있나요?
    • user라는 키로 세션 정보를 가져올 때 사용자 A와 B를 어떻게 구분하나요?
    • 여러 대의 서버가 있을 때 세션 정보를 공유하려면 어떤 방법이 있나요?
    • 세션 클러스터링이란 무엇인가요?
    • Sticky session 방식은 무엇인가요?
    • 세션 스토리지 분리 방식은 무엇인가요?
    • 세션 대신 쿠키를 사용하는 이유는?
    • 세션 인증 기반 방식의 단점은 무엇인가요?
  • 토큰 인증 기반 방식은 무엇인가요?
  • JWT가 무엇인가요?
    • JWT 기반 인증 과정에 대해 설명해 주세요
    • JWT의 구조에 대해 설명해 주세요
  • Access token과 Refresh token은 무엇인가요?
  • Refresh token은 서버와 클라이언트에서 어디에 저장되나요?

REST API & RESTful

  • REST API는 무엇이고, 왜 만들어졌나요?
  • RESTful API에서 RESTful 하다는 것이 어떤 것을 의미하는지 설명해 주세요.
  • REST 규약대로 API를 디자인할 때의 장단점?

OSI 7 계층

  • OSI 7 계층이 무엇인지 간략하게 설명해 주세요.
  • OSI 7 계층이 생긴 이유는 무엇인가요?
  • OSI 7 계층 중에 라우터나 Layer 3 스위치가 있어서 경로에 따라 패킷을 전달해 주는 계층은 어디이고, 그 계층의 대표적인 프로토콜은 무엇인지 말씀해 주세요.
  • OSI 7 계층에서 물리 계층의 역할은 무엇인가요?
  • OSI 7 계층에서 전송 계층의 역할은 무엇이고 프로토콜에는 어떤 것들이 있나요?
  • OSI 7 계층에서 응용 계층의 역할은 무엇이고 프로토콜에는 어떤 것들이 있나요?

TCP/UDP

  • TCP와 UDP의 차이점은 무엇인가요?
  • TCP의 Segment에는 어떤 정보들이 들어가나요?
  • TCP의 3 way handshake에 대해서 설명해 주세요.
  • TCP의 4 way handshake에 대해서 설명해 주세요.
  • TCP가 대역폭 사용량을 제어하는 방식에는 어떤 게 있나요?
  • UDP의 장점과 단점은 무엇이고 어떤 경우에 사용하나요?
  • TCP/IP 프로토콜 스택의 구조에 대해 간단하게 설명해 주세요.
  • TCP/IP 프로토콜 스택과 OSI 7 계층의 차이점은 무엇인가요?
  • TCP/IP 프로토콜 스택의 동작 방식에 대해서 설명해 주세요.
  • Packet의 구성 요소와 전송 순서에 대해 설명해 주세요.
  • 전이중 통신과 반이중 통신, 단방향 통신의 차이점은 무엇인가요?
  • IP 주소와 포트 번호의 역할과 차이점에 대해 설명해 주세요.

HTTP/HTTPS

  • HTTP에 대해 설명해 주세요.
  • 클라이언트에서 서버로 요청 보낼 때 Request Message를 사용하는데 여기에는 어떤 정보들이 포함되어 있나요?
    • HTTP 메서드를 종류별로 설명해 주세요.
    • HTTP 메서드가 가진 특징인 멱등성에 대해 설명해 주시고 멱등한 메서드와 그렇지 않은 메서드에 대해 말씀해 주세요.
  • Response Message에는 어떤 정보들이 포함되나요?
    • Status Code를 예로 들어서 몇 가지 설명해 주세요.
  • HTTP와 HTTPS의 차이점에 대해서 설명해 주세요.
    • HTTPS 통신의 흐름을 SSL 인증서를 포함해서 설명해 주세요.
    • HTTPS로 통신할 때 보장되는 기밀성, 무결성, 인증에 대해서 각각 설명해 주세요.

WAS/Web Server

  • Web Server와 WAS의 차이점은 무엇인가요?
  • Web Server와 WAS의 역할은 무엇인가요?
  • WAS의 예시로는 어떤 것이 있나요?
  • Web Server와 WAS를 분리할 때의 이점은 무엇이 있나요?
  • Reverse Proxy에 대해 설명해 주세요.

 

 

 

목차

  • HTTP 프로토콜
  • 쿠키와 세션
  • 토큰
  • 토큰 기반 인증 방식
  • JWT(JSON Web Token)
  • 세션 기반 인증과 토큰 기반 인증의 차이
  • www.google.com에 접속할 때 생기는 과정에 대해 네트워크 관점에서 설명해 주세요.
  • OSI 7 계층
  • HTTP와 HTTPS의 차이점
  • HTTP 1 vs HTTP 2
  • GET과 POST의 차이
  • Connection Timeout과 Read Timeout의 차이
  • 공인(public) IP와 사설(private) IP의 차이
  • TCP와 UDP는 왜 나오게 됐는가?
  • 로드 밸런싱(Load Balancing)
  • Blocking/Non-blocking & Synchronous 동기/Asynchronous 비동기

 

 

 

 

😎 HTTP 프로토콜에 대해 설명해 주세요.

HTTP(Hyper Text Transfer Protocol)이란 데이터를 주고받기 위한 프로토콜이며,

서버/클라이언트 모델을 따릅니다.

상태 정보를 저장하지 않는 Stateless의 특징과

클라이언트의 요청에 맞는 응답을 보낸 후 연결을 끊는 Connectionless의 특징을 가지고 있습니다.

 

  • 장점
    • 통신간의 연결 상태 처리나 상태 정보를 관리할 필요가 없어 서버 디자인이 간단하다.
    • 각각의 HTTP 요청에 독립적으로 응답만 보내주면 OK
  • 단점
    • 이전 통신의 정보를 모르기 때문에 매번 인증을 해줘야 한다.
    • 이를 해결하기 위해 쿠키(cookie)나 세션(session)을 사용해서 데이터를 처리한다.

 

 

 

😎 쿠키와 세션을 사용하는 이유?

HTTP 프로토콜의 특징이자 약점을 보완하기 위해서 사용한다.

 

HTTP 프로토콜의 특징

1. Connectionless 프로토콜 (비연결성)

클라이언트가 서버에 요청(Request)을 했을 때, 그 요청에 맞는 응답(Response)을 보낸 후 연결을 끊는 처리방식이다.

 

2. Stateless 프로토콜 (비상태성)

커넥션을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있다.

  • 클라이언트와 첫 번째 통신에서 데이터를 주고받았다 해도, 두 번째 통신에서 이전 데이터를 유지하지 않는다.
  • 하지만, 실제로는 데이터 유지가 필요한 경우가 많다. 정보가 유지되지 않으면, 매번 페이지를 이동할 때마다 로그인을 다시 하거나, 상품을 선택했는데 구매 페이지에서 선택한 상품의 정보가 없거나 하는 등의 일이 발생할 수 있다.

 

 

서버와 클라이언트가 통신을 할 때 통신이 연속적으로 이어지지 않고 한 번 통신이 되면 끊어진다.

따라서 서버는 클라이언트가 누구인지 계속 인증을 해줘야 한다. 하지만 그것은 매우 귀찮고 번거로운 일이다. 그런 번거로움을 해결하는 방법이 바로 쿠키와 세션이다.

  • 쿠키와 세션의 차이점은 크게 상태 정보의 저장 위치이다.
    • 쿠키는 '클라이언트(=로컬 PC)'에 저장하고, 세션은 '서버'에 저장한다

 

 

😎 쿠키(Cookie)

HTTP에서 클라이언트의 상태 정보를 클라이언트의 PC에 저장하였다가 필요시 정보를 참조하거나 재사용할 수 있다.

 

  • 쿠키 특징
    1. 이름, 값, 만료일(저장기간), 경로 정보로 구성되어 있다.
    2. 클라이언트에 총 300개의 쿠키를 저장할 수 있다.
    3. 하나의 도메인 당 20개의 쿠키를 가질 수 있다.
    4. 하나의 쿠키는 4KB(=4096byte)까지 저장 가능하다.
  • 쿠키의 동작 순서
    1. 클라이언트가 페이지를 요청한다. (사용자가 웹사이트에 접근)
    2. 웹 서버는 쿠키를 생성한다.
    3. 생성한 쿠키에 정보를 담아 HTTP 화면을 돌려줄 때, 같이 클라이언트에게 돌려준다.
    4. 넘겨받은 쿠키는 클라이언트가 가지고 있다가(로컬 PC에 저장) 다시 서버에 요청할 때 요청과 함께 쿠키를 전송한다.
    5. 동일 사이트 재방문 시 클라이언트의 PC에 해당 쿠키가 있는 경우, 요청 페이지와 함께 쿠키를 전송한다.
  • 사용 예시
    1. 방문 사이트에서 로그인 시, "아이디와 비밀번호를 저장하시겠습니까?"
    2. 팝업창을 통해 "오늘 이 창을 다시 보지 않기" 체크

 

 

😎 세션(Session)

일정 시간 동안 같은 사용자(브라우저)로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 유지시키는 기술이다.

여기서 일정 시간은 방문자가 웹 브라우저를 통해 웹 서버에 접속한 시점부터 웹 브라우저를 종료하여 연결을 끝내는 시점을 말한다.

 

즉, 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보는데, 그것을 세션이라고 한다.

 

 

  • 세션 특징
    1. 웹 서버에 웹 컨테이너의 상태를 유지하기 위한 정보를 저장한다.
    2. 웹 서버의 저장되는 쿠키(=세션 쿠키)
    3. 브라우저를 닫거나, 서버에서 세션을 삭제했을 때만 삭제가 되므로, 쿠키보다 비교적 보안이 좋다.
    4. 저장 데이터에 제한이 없다. (서버 용량이 허용하는 한에서)
    5. 각 클라이언트에 고유 Session ID를 부여한다. Session ID로 클라이언트를 구분해 각 요구에 맞는 서비스를 제공
  • 세션의 동작 순서
    1. 클라이언트가 페이지에 요청한다. (사용자가 웹사이트에 접근)
    2. 서버는 접근한 클라이언트의 Request-Header 필드인 Cookie를 확인하여, 클라이언트가 해당 session-id를 보냈는지 확인한다.
    3. session-id가 존재하지 않는다면 서버는 session-id를 생성해 클라이언트에게 돌려준다.
    4. 서버에서 클라이언트로 돌려준 session-id를 쿠키를 사용해 서버에 저장한다.
    5. 클라이언트는 재접속 시, 이 쿠키를 이용해 session-id 값을 서버에 전달
  • 사용 예시
    • 화면을 이동해도 로그인이 풀리지 않고 로그아웃하기 전까지 유지

 

▶ 쿠키와 세션의 차이

  • 쿠키와 세션은 비슷한 역할을 하며, 동작 원리도 비슷하다. 그 이유는 세션도 결국 쿠키를 사용하기 때문이다.
  • 큰 차이점은 사용자의 정보가 저장되는 위치이다. 쿠키는 서버의 자원을 전혀 사용하지 않으며, 세션은 서버의 자원을 사용한다.
  • 보안 면에서 세션이 더 우수하며,
  • 쿠키는 클라이언트 로컬에 저장되기 때문에 변질되거나 request에서 스니핑 당할 우려가 있어서 보안에 취약하지만
  • 세션은 쿠키를 이용해서 session-id만 저장하고 그것으로 구분하여 서버에서 처리하기 때문에 비교적 보안성이 높다.
  • 라이프 사이클은 쿠키도 만료기간이 있지만 파일로 저장되기 때문에 브라우저를 종료해도 정보가 유지될 수 있다. 또한 만료기간을 따로 지정해 쿠키를 삭제할 때까지 유지할 수도 있다.
  • 반면에 세션도 만료기간을 정할 수 있지만, 브라우저가 종료되면 만료기간에 상관없이 삭제된다.
  • 속도 면에서 쿠키가 더 우수하며,
  • 쿠키는 쿠키에 정보가 있기 때문에 서버에 요청 시 속도가 빠르고
  • 세션은 정보가 서버에 있기 때문에 처리가 요구되어 비교적 느린 속도를 낸다.

 

 

▶쿠키와 세션 그리고 캐시(Cache)

한 번 전송받은 데이터는 임시로 저장해 놨다가 다시 사용할 때 꺼내 쓴다면 반복적으로 서버에 데이터 전송을 요청할 필요가 없습니다. 이때 사용되는 기술이 캐시입니다.

 

캐시 장점

덕분에 우리는 반복적으로 사용하는 콘텐츠를 빠르게 이용할 수 있고 데이터 사용량도 줄일 수 있습니다.

 

캐시 특징

  • 캐시는 데이터나 값을 미리 복사해 놓는 리소스 파일들의 임시 저장소이다.
  • 저장 공간이 작고 비용이 비싼 대신 빠른 성능을 제공한다.
  • 같은 웹 페이지에 접속할 때 사용자의 PC에서 로드하므로 서버를 거치지 않아도 된다.
  • 이전에 사용된 데이터가 다시 사용될 가능성이 많으면 캐시 서버에 있는 데이터를 사용한다.
  • 그래서 다시 사용될 확률이 있는 데이터들이 빠르게 접근할 수 있어진다. (페이지의 로딩 속도 ↑)
    • 캐시 히트(hit) : 캐시를 사용할 수 있는 경우 (ex. 이전에 왔던 요청이랑 같은 게 왔을 때)
    • 캐시 미스(miss) : 캐시를 사용할 수 없는 경우 (ex. 웹서버로 처음 요청했을 때)

 

▶ 쿠키/세션과 캐시의 차이
모두 정보를 저장하여 재활용하는 기술이지만,

쿠키/세션은 사용자의 인증을 돕는데 목적을 두고

캐시는 데이터의 전송량을 줄이고 서비스 이용 속도를 높이는 데 목적을 둡니다.

 

 

▶ 쿠키와 세션을 같이 사용해야 하는 이유

  1. 쿠키는 클라이언트 측에 저장되기 때문에 서버의 부담을 줄일 수 있다. 클라이언트에 저장된 쿠키를 이용하면 서버에서 매번 클라이언트의 정보를 가져오지 않아도 된다.
  2. 세션은 쿠키에 저장된 세션 ID를 기반으로 서버에서 클라이언트의 상태를 관리하기 때문에, 보안적인 측면에서 더 안전하다. 즉, 클라이언트 측에 저장되는 쿠키와는 달리, 서버 측에서만 데이터를 유지하고 관리하기 때문에 보안에 더욱 강력하다.
  3. 쿠키와 세션은 각각의 장단점이 있기 때문에, 서로 보완하는 역할을 할 수 있다. 예를 들어, 쿠키는 클라이언트 측에 저장되기 때문에 사용자가 매번 로그인할 필요 없이 웹 사이트를 방문할 때마다 자동으로 로그인 상태를 유지할 수 있지만 보안상의 위험이 있다. 이러한 경우, 쿠키를 사용해서 로그인 상태를 유지하고, 세션을 사용해서 보안적인 정보를 유지할 수 있다.
  4. 마지막으로, 쿠키와 세션을 같이 사용하면 웹 사이트에서 더욱 효과적으로 개인화된 서비스를 제공할 수 있다. 쿠키를 이용해서 사용자의 취향이나 검색 기록 등을 추적하면, 세션은 이를 이용해서 이전 검색 기록에 기반하여 새로운 검색 결과를 제공할 수 있다.

따라서, 쿠키와 세션을 같이 사용하는 것은 더욱 강력한 상태 관리와 보안을 제공하며, 개인화된 서비스를 제공할 수 있기 때문에 일반적으로 권장되는 방식이다.

 

 

▶ 쿠키와 세션을 이용한 인증방식의 문제점

쿠키와 세션을 이용한 인증 방식에는 다음과 같은 문제점이 있습니다.

  1. 쿠키를 탈취당할 수 있다. 쿠키는 클라이언트의 브라우저에 저장되기 때문에, 탈취당할 가능성이 있습니다. 만약 쿠키가 탈취된다면 해당 사용자의 인증 정보가 노출될 수 있으며, 이로 인해 보안상 큰 문제가 발생할 수 있습니다.
  2. 세션 하이재킹(Session Hijacking)은 세션 ID를 탈취하여, 다른 사용자로 위장하여 웹 사이트에 로그인하는 공격 기법입니다. 이 경우 공격자는 해당 사용자와 동일한 권한으로 웹 사이트를 이용할 수 있으므로, 큰 보안 위협이 될 수 있습니다.
  3. 세션 변조(Session Fixation)은 공격자가 로그인하지 않은 상태에서 먼저 세션 ID를 발급받아, 이를 유지한 상태에서 피해자가 로그인하도록 유도하여, 세션 ID를 탈취하는 공격 기법입니다. 이 경우 공격자는 피해자와 동일한 세션을 유지하므로, 해당 사용자와 동일한 권한으로 웹 사이트를 이용할 수 있습니다.
  4. CSRF(Cross-Site Request Forgery)는 인증된 사용자의 권한을 이용하여, 사용자의 의지와는 무관하게 원치 않는 요청을 보내는 공격 기법입니다. 이 경우 인증된 사용자가 악성 웹 사이트를 방문하거나 악성 이메일 링크를 클릭하는 등의 방법으로 공격을 받을 수 있습니다.

따라서 보안에 취약한 쿠키와 세션을 이용한 인증 방식을 사용할 때는 보안에 대한 충분한 고려가 필요합니다.

이를 해결하기 위해서는 SSL/TLS 프로토콜을 이용하여 통신을 암호화하고, 쿠키를 HttpOnly와 Secure 속성으로 설정하여 탈취 및 변조를 방지하고, 세션 하이재킹과 CSRF를 방지하는 방법 등을 적용해야 합니다.

 

 

 

😎 토큰이란?

토큰은 토큰화 시스템과 결합된 데이터로 사용자를 인증할 때 암호화하여 보안을 향상하는 데 사용된다.

토큰의 종류

  • Physical token : 장치를 사용하여 사용자의 정보를 저장하고 신원을 확인하는 데 이용된다.
    • Hard token : 스마트카드, USB
    • Soft token : 모바일 또는 컴퓨터 상에서 인증된 앱 또는 SMS를 통해 암호화된 코드(예: OTP)
  • Web token : 클라이언트가 요청한 증명을 통해 서버가 서명을 생성하여 인증을 하는 데 이용된다.

 

😎 토큰 기반 인증 방식

토큰 기반 인증 방식이 생긴 이유

기존의 세션 기반 인증 방식은 서버 측에서 세션 저장소를 두고 정보를 저장하여 사용하기 때문에 사용하는 메모리가 계속해서 증가된다는 점과, 쿠키를 사용해야 하기 때문에 쿠키를 지원하지 않는 브라우저 혹은 모바일 환경에서 사용하기 어려우므로 확장성의 문제가 있었다.

그래서 상태를 유지하지 않고 사용자에 대한 인증 프로세스를 토큰을 통해 진행하는 토큰 인증 방식이 생겼다.

 

 

동작과정

 

  • 사용자가 서버 또는 보호된 리소스에 대한 액세스를 요청한다. (로그인)
  • 서버는 사용자의 정보를 암호화하여 토큰을 발급한다.
  • 사용자는 토큰을 브라우저에 저장하고 서버에 요청할 때마다 해당 토큰을 헤더에 담아 전달한다.
  • 서버는 전달받은 토큰을 검증하고 요청에 응답한다.

 

▶ 토큰 기반 인증 방식 장, 단점

  • 장점
    • 토큰 자체에 정보가 포함되어 있으므로 네트워킹 상태를 유지하지 않아도 된다.
    • 세션 저장소에서 다시 사용자의 정보를 가져와야 하는 등의 추가 작업이 필요하지 않으므로 인증 프로세스를 간소화할 수 있다.
    • 인증을 위한 별도의 저장소가 필요하지 않다.
    • 여러 플랫폼에서 사용이 가능하다. (확장성이 우수하다)
  • 단점
    • 토큰 자체의 데이터 길이가 길기 때문에 인증 요청이 많아짐에 따라 네트워크 부하가 생길 수 있다.
    • 사용자의 중요한 데이터를 담을 수 없다.
    • 토큰 또한 탈취당할 위험이 있다.

 

 

▶ 토큰 기반 인증 방식 종류

  • JWT(JSON Web Token)
    • 암호화를 이용하여 인증을 위한 데이터를 만들기 위해 사용되는 표준으로 JSON 형태로 만들어진다.
  • OAuth(Open Authorization)
    • 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로써 사용되는, 접근 위임을 위한 개방형 표준이다.
  • SAML(Security Assertion Markup Language)
    • 인증 정보 제공자(IDP; IDentity Provider)와 서비스 제공자(SP; Service Provider) 간의 인증 및 인가 데이터를 교환하기 위한 XML 기반의 개방형 표준이다.
  • OIDC(OpenID Connect)
    • OAuth 2.0 프로토콜을 사용해서 사용자를 고유하게 식별하는 ID를 생성한다.

 

 

😎 JWT(JSON Web Token)

서버와 클라이언트가 전달하려는 정보를 JSON 형식으로 안전하게 전송하기 위해 사용하는 표준이다. 정보가 디지털 서명되었기 때문에 확인하고 신뢰할 수 있다.

 

▶ JWT 특징 및 장, 단점

  • 권한 부여
    • 사용자가 로그인한 이후에 토큰을 발급받으면 허용된 경로, 서비스 및 리소스에 접근할 수 있다.
  • 정보 교환
    • 정보를 안전하게 전송할 수 있으며 헤더와 페이로드를 이용해서 서명을 생성하기 때문에 정보가 변경되었다면 확인할 수 있다.
  • 장점
    • 다른 토큰 기반 인증 방식에 비해 JSON 형식을 사용하기 때문에 크기가 작아 전달하기에 좋다.
    • Header와 Payload를 통해 Signature를 생성하므로 데이터 위변조를 막을 수 있다.
    • 토큰 탈취의 위험성을 낮추기 위해 refresh token을 활용할 수 있다.
  • 단점
    • 토큰의 Payload에 세 종류의 Claim을 저장하기 때문에, 정보가 많아질수록 길이가 늘어나 네트워크에 부하를 줄 수 있다.
    • Payload에 담기는 데이터들은 모두 Base64로 디코딩될 수 있기 때문에 중요한 정보를 담을 수 없다.

 

▶ JWT 구조

점(.)으로 구분된 세 부분으로 구성된다.

  • Header
  • Payload
  • Signature

 

Header

서명 알고리즘(예: HMAC SHA256 또는 RSA)과 토큰 유형의 두 부분으로 구성된다.

{
	"alg": "HS256",
	"typ": "JWT"
}
  • 이 JSON은 Base64로 인코딩 되어 JWT의 첫 번째 부분을 구성한다.
  • 토큰 유형
    • Basic : 사용자 아이디와 암호를 Base64로 인코딩한 값을 토큰으로 사용한다. (RFC 7617)
    • Bearer : OAuth에 대한 토큰에 사용하지만 JWT에도 사용한다. (RFC 6750)
    • JWT : JWT에서 토큰 타입을 지정할 때 사용한다.

 

💡 인코딩 방식에 Base64를 선택한 이유는 무엇일까?
시스템 간에 데이터를 전달할 때 안정성을 보장할 수 있기 때문에 Base64를 선택해서 사용한다.

 

💡 Bearer과 JWT 중 어느 것을 사용해야 할까?
정답은 Bearer이다. Bearer은 IANA(인터넷 할당 번호 관리 기간)에 등록되어 있는 체계이기도 하고, 클라이언트가 토큰을 전송할 때 가장 적합한 HTTP 헤더가 Bearer 인증 체계가 있는 Authorization이기 때문이다.

 

 

Payload

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

사용자 및 추가 데이터에 대한 설명인 클레임을 포함한다.

  • Registered claim : 필수는 아니지만 권장되는 미리 정의된 클레임 집합
    • iss : 발급자
    • exp : 만료 시간
    • sub : 주제
    • aud : 대상
    • 기타
  • Public claim : 사용자가 정의할 수 있으며 공개용 정보 전달용으로 사용된다. 충돌이 일어날 수 있으니 주의해야 한다.
  • Private claim : 정보를 공유하기 위해 생성된 사용자 정의 클레임으로 해당 유저를 특정할 수 있는 정보들을 담는다.

 

 

Signature

HMACSHA256 (
  base64UrlEncode(헤더) + "." +
  base64UrlEncode(페이로드),
  your-256-bit-secret
)
  • 서명을 생성하려면 인코딩 된 헤더, 인코딩된 페이로드, 비밀키(private key), 헤더에 지정된 알고리즘이 필요하다.
  • 서명으로 도중에 메시지가 변경됐는지 판별할 수 있고, 비밀키(private key)로 서명된 토큰의 경우 JWT 발신자도 확인할 수 있다.
  • 과정
    • Header, Payload를 Base64로 인코딩한다.
    • Header에 지정된 알고리즘으로 해싱한다.
    • 이를 대상으로 비밀키로 서명한다.

 

 

▶ JWT 동작 과정

❶ 사용자가 사용자 정보를 통해 로그인한다.

❷ 서버에서는 사용자 정보를 증명하고 JWT 토큰을 응답으로 반환하는데 이때 access token과 함께 refresh token을 같이 전송한다.

❸ 그 이후에 사용자는 access token을 통해 서버에 요청을 보내는데 만약 토큰이 만료되었다면, 서버에서는 만료된 토큰임을 확인하고 401 에러를 반환한다.

❹ 웹 브라우저가 토큰이 만료됐음을 확인하면, 자동으로 refresh token으로 새로운 토큰 발급 요청을 보낸다.

❺ 서버는 refresh token을 검증한다.

❻ 검증이 끝난 후에 새로운 access token과 refresh token을 반환한다.

❼ 사용자는 새로운 토큰으로 서버에 요청을 보낼 수 있다.

 

💡 Refresh Token은 어디에 저장이 되는가?
서버에서는 Refresh Token을 DB에 저장한다. 클라이언트에서는 Refresh Token을 어디에 저장하느냐에 대한 의견이 다양한데 가장 문제가 되는 것은 역시 보안이다. HTTPOnly와 Secure 속성을 이용해서 쿠키에 저장하는 것을 가장 많이 선택한다.

 

 

 

정리하자면, JWT 토큰은?

JWT는 JSON 포맷을 이용하는 Claim 기반의 웹 토큰이며, 토큰 자체를 정보로 사용하는 방식으로 정보를 안전하게 전달합니다.
JWT는 헤더(Header). 내용(Payload). 서명(Signature)으로 구성되며 각 파트를 점(.)으로 구분합니다.

헤더(Header) : 
토큰의 타입과 해시 암호화 알고리즘으로 이루어져 있다.

내용(Payload) : 
토큰에 사용자가 담고자 하는 정보를 담는다. 내용에는 Claim이 담겨있고, JSON(Key/Value) 형태의 한 쌍으로 이루어져 있다.

서명(Signature) : 
토큰을 인코딩하거나 유효성 검증할 때 사용하는 고유한 암호화 코드이다. 헤더와 내용의 값을 인코딩한다.

 

 

 

😎 세션 기반 인증과 토큰 기반 인증의 차이에 대해 얘기해 주세요.

세션 기반 인증은 클라이언트로부터 요청을 받으면 클라이언트의 상태 정보를 저장하므로 Stateful 한 구조를 가지고,
토큰 기반 인증은 상태 정보를 서버에 저장하지 않으므로 Stateless 한 구조를 가집니다.

* 세션 기반 인증 방식의 예) 쿠키, 세션

 

▶그렇다면 Stateful 한 세션 기반의 인증 방식을 사용하게 된다면 어떠한 단점이 있을까요?

1. 서버에 세션을 저장하기 때문에 사용자가 증가하면 서버에 과부하를 줄 수 있어 확장성이 낮습니다.

2. 해커가 훔친 쿠키를 이용해 요청을 보내면 서버는 올바른 사용자가 보낸 요청인지 알 수 없습니다. (세션 하이재킹 공격)

 

▶ 그렇다면 세션 기반 인증과 토큰 기반 인증은 각각 어느 경우에 적합한가요?

단일 도메인이라면 세션 기반 인증을 사용하고, 아니라면 토큰 기반 인증을 사용하는 것이 적합하다고 생각합니다.

왜냐하면 , 세션을 관리할 때 사용되는 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어 있기 때문에 여러 도메인에서 관리하는 것은 어렵습니다. (CORS 문제)

 

 

 

 

 

 

 

 

 

 

관련 포스팅

[기술면접] 네트워크 - 1/2

[기술면접] 네트워크 - 2/2

 

 

 

 

 

참고한 포스팅, 감사합니다 :

네트워크 질문

토큰 기반 인증 방식

https://github.com/JaeYeopHan/Interview_Question_for_Beginner/tree/master/Network

https://gyoogle.dev/blog/computer-science/network/OSI%207%EA%B3%84%EC%B8%B5.html

https://dev-coco.tistory.com/161

https://mangkyu.tistory.com/91

저작자표시 비영리 변경금지

'기술 면접 준비' 카테고리의 다른 글

[운영체제] 운영체제는 프로그램이다?! - 1/5  (0) 2023.03.31
[기술면접] 네트워크 - 2/2  (0) 2023.03.23
[기술면접] 데이터베이스  (0) 2023.03.23
[기술면접] JAVA - 4/4  (0) 2023.03.03
[기술면접] JAVA - 3/4 (주로 컬렉션 프레임워크)  (0) 2023.03.03

'기술 면접 준비'의 다른글

  • 현재글[기술면접] 네트워크 - 1/2

관련글

티스토리툴바