기술면접 - 쿠키, 세션, 토큰

쿠키, 세션, 토큰

쿠키

쿠키는 웹 서버가 클라이언트에 저장하는 작은 데이터 조각입니다. 웹 서버가 클라이언트에게 응답할 때, 쿠키는 클라이언트의 컴퓨터에 저장됩니다. 그리고 이후에 클라이언트가 같은 웹 서버에 요청을 보낼 때마다 쿠키는 서버로 함께 전송됩니다. 주로 사용자 인증, 세션 유지, 사용자 설정 등을 저장하고 관리하는 데 사용됩니다. 쿠키는 클라이언트 측에서 관리되기 때문에 보안에 취약할 수 있습니다.

세션

세션은 서버 측에서 클라이언트와의 상호 작용을 유지하는 데 사용되는 개념입니다. 클라이언트가 서버에 접속하면 서버는 클라이언트에게 고유한 세션 ID를 부여합니다. 이 세션 ID는 보통 쿠키를 사용하여 클라이언트에게 전달됩니다. 클라이언트의 모든 요청에는 세션 ID가 함께 전송되며, 서버는 이를 통해 클라이언트를 식별하고 세션 데이터를 관리합니다. 세션을 사용하면 클라이언트의 상태 정보를 서버에 저장하여 보안을 강화할 수 있습니다.

토큰

토큰은 클라이언트 인증을 위해 사용되는 문자열입니다. 사용자가 로그인하면 서버는 클라이언트에게 토큰을 발급합니다. 이 토큰은 클라이언트의 인증 정보를 포함하고 있으며, 클라이언트는 매 요청마다 토큰을 서버에 제공하여 인증합니다. 서버는 토큰을 검증하여 클라이언트의 신원을 확인하고 요청을 처리합니다. 토큰은 보안성이 높고 확장성이 용이하여 인증 시스템에 널리 사용됩니다.

비교 테이블

기준	쿠키	세션	토큰
저장 위치	클라이언트(브라우저)에 저장됨	서버에 저장됨	클라이언트 또는 서버에 저장될 수 있음
데이터 저장	작은 데이터 파일로 사용됨	클라이언트와 서버 간의 상태 정보	사용자 인증 및 권한 부여에 사용됨
보안성	클라이언트 조작 가능성 있음	서버에 안전하게 보관됨	토큰 탈취에 대한 보안 조치 필요
사용 목적	사용자 식별, 선호 설정 등	클라이언트와 서버 간 상태 정보 유지	사용자 인증, 권한 부여, API 호출 등
관리	브라우저가 자동으로 관리	서버가 세션 ID를 생성하고 관리	서버 또는 클라이언트가 토큰을 관리

OAuth

OAuth

OAuth는 인증 및 권한 부여 프레임워크로, 클라이언트 애플리케이션이 사용자의 리소스에 접근할 수 있는 권한을 얻는 데 사용됩니다. OAuth는 다른 서비스(제공자)의 인증 시스템을 사용하여 사용자 인증을 처리하고, 클라이언트 애플리케이션이 사용자의 데이터에 접근할 수 있는 권한을 얻을 수 있도록 돕습니다.

OAuth의 작동 메커니즘

단계	설명
1. 클라이언트 등록	클라이언트 애플리케이션은 서비스 제공자에 등록되고 클라이언트 ID와 클라이언트 비밀번호를 받습니다.
2. 사용자 동의 요청	클라이언트 애플리케이션은 사용자에게 서비스 제공자에 대한 권한 요청을 보냅니다.
3. 리다이렉션 및 사용자 인증	서비스 제공자는 사용자를 로그인 페이지로 리다이렉션하고 사용자는 인증을 위해 자신의 인증 정보를 입력합니다.
4. 권한 부여 동의	인증이 완료되면 서비스 제공자는 사용자에게 클라이언트 애플리케이션의 요청에 대한 권한 부여를 요청합니다. 사용자는 동의 여부를 결정합니다.
5. 액세스 토큰 발급	사용자가 클라이언트 애플리케이션에 권한을 부여하면, 서비스 제공자는 액세스 토큰을 발급합니다.
6. 액세스 토큰 사용	클라이언트는 액세스 토큰을 사용하여 서비스 제공자에게 요청을 보내고 사용자의 데이터에 접근합니다.

JWT

JWT

JWT(Jason Web Token)는 웹 표준으로 정의된 토큰 기반의 인증 방식입니다. JWT는 정보는 안전하게 전송하기 위해 사용되며, 특히 분산 시스템과 마이크로서비스 아키텍처에서 인증과 권한 부여를 처리하는 데 널리 사용됩니다.

JWT의 구조

1. Header: JWT의 유형 및 암호화 알고리즘 정보를 포함합니다.
2. Payload: 토큰에 담길 클레임(claim) 정보를 포함합니다. 클레임은 토큰에 관련된 데이터를 나타내며, 등록된 클레임, 공개 클레임, 비공개 클레임으로 구분됩니다.
3. Signature: 토큰의 유효성 검증을 위한 서명 부분입니다. 헤더와 페이로드, 비밀키를 사용하여 생성됩니다.

JWT의 작동 메커니즘

단계	설명
1. 인증	사용자가 로그인하면 서버는 유효한 사용자임을 확인하고 JWT를 발급합니다.
2. JWT 발급	서버는 필요한 클레임 정보를 포함한 JWT를 생성하여 발급합니다.
3. 클라이언트 응답	서버는 클라이언트에게 JWT를 응답으로 전달합니다.
4. 토큰 전송	클라이언트는 JWT를 요청의 Authorization 헤더나 쿠키 등을 통해 서버로 전송합니다.
5. 토큰 검증	서버는 수신한 JWT의 유효성을 확인하고 필요한 클레임 정보를 사용하여 인증 및 권한 검사를 수행합니다.
6. 응답 처리	서버는 요청을 처리하고 응답을 클라이언트에게 반환합니다.

JWT의 장점

• 클라이언트와 서버 간의 상태를 저장하지 않기 때문에 확장성이 용이합니다.
• 클라이언트가 토큰을 가지고 있기 때문에 세션 관리에 대한 부담이 없습니다.
• 정보를 토큰 자체에 포함시키기 때문에 데이터베이스 조회를 최소화할 수 있습니다.
• 토큰은 서명되어 있어 위조를 방지하고, 정보의 무결성을 검증할 수 있습니다.

면접 질문

1. 쿠키, 세션, 토큰에 대해서 설명해주세요.

• 꼬리질문: 쿠키의 수명은 어떻게 결정되나요?
  쿠키의 수명은 서버에서 쿠키를 생성할 때 설정되는 만료 기간에 의해 결정됩니다.
• 꼬리질문: 쿠키를 사용하여 어떤 종류의 정보를 저장할 수 있나요?
  쿠키를 사용하여 사용자의 선호 설정, 로그인 정보, 장바구니 정보 등을 저장할 수 있습니다.
• 꼬리질문: 세션 ID는 어떤 방식으로 생성되나요?
  세션 ID는 일반적으로 랜덤한 문자열로 생성되며, 보안적으로 안전한 알고리즘을 사용하여 생성됩니다.
• 꼬리질문: 세션은 어떤 시점에 종료되고 상태 정보는 어떻게 유지되나요?
  세션은 클라이언트가 로그아웃하거나 일정 시간 동안 비활성 상태일 때 종료될 수 있습니다. 상태 정보는 서버 측에서 관리되며, 일반적으로 메모리나 데이터베이스에 저장됩니다.
• 꼬리질문: 토큰의 종류에는 어떤 것들이 있고 어떤 용도로 사용되나요?
  토큰의 종류로는 액세스 토큰, 리프레시 토큰, JWT 등이 있으며, 사용자 인증 및 API 요청 인증에 사용됩니다.

2. OAuth란 무엇이고, 작동 메커니즘은 어떻게 되는지 설명해주세요.

• 꼬리질문: OAuth 2.0과 OAuth 1.0의 주요 차이점은 무엇인가요?
  OAuth 2.0은 더 간단하고 유연한 프로토콜로 개선되었으며, 토큰 기반 인증을 지원합니다. OAuth 1.0은 서명된 요청과 공유 비밀 키를 사용하여 인증을 처리하는 방식이었습니다.
• 꼬리질문: OAuth의 장점과 주요 사용 사례는 어떤 것이 있나요?
  OAuth는 사용자가 서드파티 애플리케이션에 대한 접근 권한을 안전하게 제어할 수 있으며, 주요 사용 사례로는 소셜 미디어 로그인, API 인증, 클라이언트 애플리케이션 간 인증 등이 있습니다.

3. Session과 token의 인증 방식 차이에 대해 설명해주세요.

• 꼬리질문: 세션과 토큰 중 어떤 인증 방식이 보안적으로 강력한가요?
  토큰 기반의 인증 방식이 보안적으로 강력합니다. 토큰은 서버에서 생성되고 암호화되며, 유효 기간과 범위를 지정하여 보안을 강화할 수 있습니다.
• 꼬리질문: 세션과 토큰을 사용할 때 발생할 수 있는 보안 위협은 무엇인가요?
  세션과 토큰을 관리하는 과정에서 CSRF(Cross-Site Request Forgery), XSS(Cross-Site Scripting), 토큰 유출 등의 보안 위협이 발생할 수 있습니다.

4. JWT 에 대해 설명해주세요.

• 꼬리질문: JWT의 구성 요소는 무엇이며 각각의 역할은 무엇인가요?
  JWT는 헤더(Header), 페이로드(Payload), 서명(Signature)으로 구성됩니다. 헤더는 토큰의 유형과 암호화 알고리즘 등의 정보를 담고, 페이로드는 클레임(클라임) 정보를 포함하며, 서명은 토큰의 무결성을 검증하는 역할을 합니다.
• 꼬리질문: JWT의 장점과 주의해야 할 점은 무엇인가요?
  JWT는 서버에 세션 정보를 저장하지 않고도 확장성과 분산 시스템에서의 효율성을 제공합니다. 그러나 토큰이 클라이언트에 저장되므로 토큰 유출에 대한 주의가 필요하며, 토큰 자체의 크기가 커질 수 있습니다.