쿠키/세션/웹스토리지

쿠키

쿠키는 클라이언트(브라우저) 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일
사용자 인증이 유효한 시간을 명시 가능

세션

세션은 쿠키를 기반하고 있지만, 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 세션은 서버 측에서 관리
세션 ID를 부여하며 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지
사용자에 대한 정보를 서버에 두기 때문에 쿠키보다 보안에 좋지만, 사용자가 많아질수록 서버 메모리를 많이 차지하게 됨

쿠키와 세션의 차이점

사용자의 정보가 저장되는 위치가 다름
세션의 서버의 처리가 필요하기 때문에 요청 속도가 더 빠르고 보안 면에서도 더 좋다.
하지만 무분별하게 만들다보면 서버의 메모리가 감당할 수 없다.

로컬 스토리지와 쿠키의 차이

1) 로컬 스토리지는 5MB~10MB 정도로 큰 양의 데이터 저장에 적합, 쿠키는 각각 약 4KB의 작은 데이터 크기를 가지고 있으며, 도메인 당 쿠키 수와 크기에 제한이 있고 작은 데이터 조각을 저장하기 적합
2) 로컬 스토리지 데이터는 브라우저와 서버 간에 자동으로 전송X, 쿠키는 HTTP 요청과 함께 서버로 자동 전송됨 -> 쿠키를 사용하여 사용자의 세션 관리, 사용자 식변 및 기타 서버-클라이언트 간 정보 교환 수행 가능
3) 로컬 스토리지의 데이터는 수동으로 삭제하기 전까지 계속 유지되며 만료 기간 X, 쿠키는 만료 날짜 또는 기간 설정 가능하고 쿠키는 세션 쿠기나 영속 쿠키로 설정 가능
4) 로컬 스토리지에 저장된 데이터는 JS를 통해 쉽게 읽고 쓸 수 있고 안전하지 X, HTTP-Only 및 Secure와 같은 속성을 설정해 스크립틑 접근 제한 가능해서 보안적으로 더 안전

다크 모드 상태 정보를 저장하는 것은 매우 적은 양의 데이터이다. 그래서 데이터 저장 크기는 고려 X
다크 모드에 대한 정보를 서버에 전송할지 여부는 프로젝트의 경우마다 다르겠지만 사용자의 경험을 향상시킬 수 있고 어떤 비율로 사용자가 다크 모드를 사용하는지 추적해서 향후 개선을 위한 데이터로 사용할 수 있고 사용자 환경 설정 관리 가능
하지만 대부분의 경우, 사용자 환경 설정은 주로 클라이언트 측에서 관리되고, 서버에 전송할 필요가 없을 수 있다.
서버에서 필요하지 않은 정보인 경우 수신할 필요가 없다.

면접 질문

1. 다크 모드 기능을 설정한다면 다크 모드에 대한 정보를 어디에 저장할 것 인지에 대해서 말해주세요.
   (예시 : 로컬 스토리지에 저장하겠다. 왜냐하면…. or 쿠키에 저장하겠다. 왜냐하면 …)

• 로컬 스토리지에 저장할 것입니다. 쿠키는 HTTP 요청과 함께 자동으로 서버로 전송됩니다. 사용자 환경 설정을 서버에 전송할 필요가 없는 경우, 로컬 스토리지를 사용해 불필요한 데이터 전송을 피할 수 있습니다. 그리고 JS를 이용해서 데이터를 쉽게 삭제할 수 있습니다. 쿠키의 경우는 만료 날짜를 설정하거나 클라이언트 측에서 삭제하기 더 복잡할 수 있기 때문입니다.

2. 쿠키와 세션의 차이점을 말해주세요.
   쿠키는 클라이언트 측에서 사용자 상태 정보를 유지하고 서버로 전송하는 데 사용되며, 세션은 서버 측에서 사용자 상태 정보를 유지하고 관리하는 데 사용됩니다
   => 사용자의 정보가 저장되는 위치가 다름
   세션 데이터는 서버에 저장되므로 클라이언트와 서버 간의 데이터 전송이 필요하지 않다. 하지만 무분별하게 만들다보면 서버의 메모리가 감당할 수 없다.
   세션은 서버 측에 저장되므로 쿠키보다 일반적으로 더 안전합니다.

3. 웹스토리지가 무엇이며, 이것의 장단점은?
   웹 브라우저에서 데이터를 클라이언트 측에서 저장하고 관리하기 위한 웹 플랫폼의 기술이다.

• 주로 2가지 형태로 나뉨 => 키-값 쌍을 사용해 데이터를 저장하는 로컬 스토리지, 브라우저를 닫아도 지속된다. 브라우저 세션이 유지되는 동안에만 지속되는 세션 스토리지, 브라우저를 닫으면 데이터가 삭제됨
• 장점은 클라이언트 측에 데이터를 저장하고 읽어서 서버와 통신 필요 X, 그래서 데이터 액세스가 더 빠름, 비교적 큰 양의 데이터를 저장하는 데 충분하다.
• 단점은 보안 및 개인 정보 보호에 주의해야 한다. 중요한 데이터는 서버 측에서 저장하고 관리하는 것이 안전할 수 있다.
  => 이유는 데이터의 기밀성, 무결성 및 가용성을 유지하고, 보안을 강화한다.

기밀성

정보를 오직 인가(authorization)된 사람들에게만 공개하는 것

무결성

신뢰할 수 있는 서비스 제공을 위해서 의도하지 않은 요인에 의해 데이터, 소프트웨어, 시스템 등이 변경되거나 손상되지 않고 완전성, 정확성, 일관성을 유지함을 보장하는 특성.
http://terms.tta.or.kr/dictionary/dictionaryView.do?subject=%EB%AC%B4%EA%B2%B0%EC%84%B1

가용성

이란 서버와 네트워크, 프로그램 등의 정보 시스템이 정상적으로 사용 가능한 정도 (항상 서비스할 수 있는 시스템 = 가용성이 높은 시스템)

4. local storage와 session storage의 차이점을 설명해 주세요.

• 로컬 스토리지는 브라우저를 닫아도 저장된 데이터가 유지되고 세션 스토리지에 저장된 데이터는 브라우저 세션이 유지되는 동안에만 유지됨
• 로컬 스토리지 데이터는 동일한 사이트의 모든 사이트의 모든 페이지에서 공유 가능, 세션 스토리지 데이터는 동일한 세션 내에서만 공유됨 (다른 탭 또는 창에서 액세스 불가)

5. 쿠키와 세션을 사용하는 이유를 설명해주세요.
   사용자를 고유하게 식별하고 사용자 상태 및 세션 정보를 관리하기 위해 사용됨, 사용자 경험을 향상시킨다.
   로그인한 사용자에게 세션 ID를 부여하고, 이를 사용해 사용자를 식별하고 보호된 리소스에 액세스 권한을 부여함
   맞춤형 광고를 제공
   세션은 클라이언트 측에서 데이터를 저장해서 관리하기 때문에 서버 부하를 감소시키는 데 도움을 준다.

https://interconnection.tistory.com/74

세션/토큰 기반 인증

인증

클라이언트가 사용자를 검증하는 과정
자격 증명 확인
ex) 로그인

인가

권한 부여
인증 작업 이후에 행해지는 작업, 인증된 사용자에 대한 자원에 대한 접근 확인 절차

Session 기반 인증

사용자의 인증 정보가 서버의 세션 저장소에 저장되는 방식

• 서버가 상태 관리하므로 로그아웃 및 세션 관리가 간편
• 서버가 사용자 상태를 관리해야 하므로 서버 부하가 발생할 수 있다.

Token 기반 인증

현재 가장 널리 사용되는 JWT 기준으로 설명한다.
인증 정보를 클라이언트가 직접 들고 있는 방식. 토큰 형태로 브라우저의 로컬 스토리지(혹은 쿠키)에 저장된다.
토큰의 종류에 따라 다르겠지만, 대표적인 토큰 JWT의 경우 디지털 서명이 존재해 토큰의 내용이 위변조 되었는지 서버측에서 확인 가능

• 서버가 상태를 유지하지 않아도 되므로 서버 확장성 향상
• 서버 간의 사용자 상태를 공유할 필요할 필요가 없어 분산 시스템에 효과적
• 단점은 클라이언트에 토큰이 저장되므로 토큰 유출에 주의해야 함

토큰 기반 인증을 사용하는 경우, 서버 간에 세션을 공유하기는 더 쉽다
그 이유는 여러 서버 간에 동일한 토큰 검증 로직을 사용해 사용자를 인증하고 서로 다른 서버에서도 토큰을 신뢰할 수 있다. 각 요청은 토큰을 포함하므로 다른 서버에서도 토큰을 검증하고 인증할 수 있기 때문이다.

두 인증 방식 비교

1. 사이즈
   세션의 경우, 쿠키 헤더에 세션 ID만 실어 보내면 되어서 트래픽 적게 사용함
   JWT는 사용자 인증 정보와 토크늬 발급시각, 만료시각, 토근의 ID 등 담여있는 정보가 세션 ID에 비해 커서 훨씬 더 많은 네트워크 트래픽 사용
2. 안전성과 보안
   세션의 경우, 모든 인증 정보를 서버에서 관리하기 때문에 보안 측면에서 더 유리함
   토큰의 경우, 서버가 트래킹하지 X, 클라이언트가 모든 인증 정보를 가지고 있어서 토큰이 탈취되면 해당 토큰이 만료되기 전까지 피해를 입는다.
   JWT 특성 상, 토큰에 실린 Payload가 별도로 암호화 되어있지 X, 누구나 내용 확인 가능
   세션의 경우, 모든 데이터가 서버에 저장되기 때문에 아무나 함부로 열람 X, 저장 데이터 제한 X
3. 확장성
   그럼에도 불구하고 웹 어플리케이션에서 토큰 기반 인증 사용 이유? 확장성
   토큰 기반 인증 방식의 경우 서버가 직접 인증 방식을 저장하지 않고, 클라이언트가 저장하는 방식을 취하기 때문에 세션 불일치 문제로부터 자유롭다. HTTP의 비상태성을 그대로 활용 가능, 높은 확장성을 가질 수 있다.
4. 서버의 부담
   세션 기반 인증 방식은 세션 데이터의 양이 많아지면 많아질수록 서버의 부담이 증가할 것이다.
   토큰 기반 방식은 유저의 수가 얼마나 되던 서버의 부담이 증가하지 않는다.

https://hudi.blog/session-based-auth-vs-token-based-auth/

세션 불일치 문제

일반적으로 웹 어플리케이션의 서버 확장 방식은 수평 확장을 사용. 즉, 한대가 아닌 여러대의 서버가 요청을 처리하게 된다. 이 때, 별도의 작업을 해주지 않는다면, 세션 기반 인증 방식은 세션 불일치 문제를 겪게 된다.

HTTP의 비상태성

면접 질문

1. 최근 모던 웹 어플리케이션에서 세션 기반 인증보다 토큰 기반 인증을 많이 사용하는 이유가 무엇입니까?

• 토큰 기반 인증은 서버가 클라이언트의 상태를 유지하지 않고도 인증 처리 가능
  세션 기반 인증은 서버에서 세션 상태를 관리해야 하므로 서버 부하와 복잡성을 증가시킬 수 있다.
• 토큰 기반 인증은 서버의 확장성을 향상시킴. 각 요청은 토큰을 포함 -> 서버 간의 상태 공유할 필요 X -> 더 많은 동시 사용자를 지원하는데 도움이 됨
• 모바일 앱은 HTTP 요청 헤더에 토큰을 포함하여 인증을 처리 가능
• 많은 플랫폼과 서비스에서 토큰 기반 인증을 지원하고 있다. (OAuth와 OpenID Connect와 같은 표준 프로토콜을 사용)
• 토큰은 주로 JWT(Json Web Tokens) 형식으로 사용되며, 이는 클라이언트 측에서도 검증이 가능한 서명된 토큰을 제공
• 토큰 기반 인증은 비동기 통신에 이상적입니다. AJAX 호출, WebSocket 및 기타 비동기 통신 방식에서 쉽게 사용 가능
• 토큰 기반 인증은 무상태, 확장 가능하며 보안 강화를 제공하여 모던 웹 어플리케이션에서 널리 사용됨 -> 이것을 풀어서 답변하기
  

2. 세션/토큰 기반 인증의 특징을 말하고, 세션/토큰 기반 인증 실제 예시를 각각 1개씩 알려주세요.

• 세션 기반 인증은 클라이언트가 로그인을 하면 서버에서 세션ID를 생성하고 클라이언트에게 제공함

• 상태가 있는 인증 방식으로 서버 측에서 사용자 상태를 유지하기 땜에 서버 부하 발생 가능

• 서버가 사용자의 로그인 상태를 서버 메모리나 데이터베이스에 유지하고 관리해야 함

• 로그아웃하면 해당 세션 종료되고 서버에서 제거됨

• 전통적인 웹 애플리케이션에서 세션 기반 인증 사용함

• 토큰 기반 인증 상태가 없는 인증 방식으로 서버는 클라이언트의 상태를 유지하지 X, 서버는 클라이언트가 로그인을 함녀 액세스 토큰을 발급해주고, 이 토큰을 사용해 클라이언트를 인증함

• 서버의 확장성을 향상시킴, 각 요청은 토큰을 포함

• 모바일 애플리케이션에서 사용 가능, 상태를 유지하지 않고도 사용자를 인증 가능 (stateless -> 서버가 클라이언트의 로그인 상태나 세션 정보를 서버 측에서 관리하지 X)
  => 서버는 토큰을 검증하고, 사용자를 인증할 뿐...

• 토큰 기반 인증의 주요 이점 중 하나는 서버가 사용자 상태를 관리하지 않아도 되므로 서버의 확장성이 향상되며, 분산 시스템에서도 효과적으로 작동할 수 있다는 것입니다. 클라이언트가 토큰을 소지하고 있으면 어느 서버에서든 인증을 처리할 수 있으므로 서버 간에 사용자 상태를 공유할 필요가 없습니다. 이로써 사용자 인증을 간단하고 확장 가능하게 만들 수 있다.

3. 토큰 기반 인증 방식의 동작 과정을 설명해주세요.

• 로그인을 한다. 서버에 로그인 요청 -> 아이디와 비번이 유효한 경우, 액세스 토큰 발급 -> 액세스 토큰은 일반적으로 JSON Web Token (JWT) 형식으로 인코딩됨 (사용자 정보와 권한 정보 포함 가능) -> 토큰은 로컬 스토리지, 세션 스토리지 또는 모바일 앱의 메모리에 저장됨 -> 인증 필요한 서비스나 리소스에 접근 시, 요청의 헤더나 쿼리 매개변수에 액세스 토큰을 첨부해서 보냄 -> 서버에서 액세스 토큰 검증 -> 사용자 권한 확인하고 승인/응답
  -> (액세스 토큰 갱신 => 선택 사항)
  -> (로그아웃 시, 액세스 토큰 삭제하거나 무효화 => 선택 사항)

4. Access Token과 Refresh Token에 대해서 설명해주세요.

• Access Token과 Refresh Token은 토큰 기반 인증 시스템에서 사용되는 두 가지 중요한 유형의 토큰이다.
• Access Token : Access Token은 사용자가 인증된 후에 소스 서버(Resource Server)에 접근하고 API 요청을 보낼 때 사용되고 일반적으로 JSON Web Token (JWT) 형식을 사용하며, 사용자의 식별 정보와 권한 정보를 포함할 수 있다.
  보통 짧은 유효 기간을 가지며, 일반적으로 15분에서 1시간 정도...
  사용자를 식별하고, 해당 사용자가 어떤 권한을 가지고 있는지 확인하는 데 사용됨
  HTTPS와 같은 보안 프로토콜을 통해 전송되어야 하며, 클라이언트 측에서 안전하게 저장되어야 함

• Refresh Token : Access Token을 갱신하거나 새로 발급하기 위해 사용되고 일반적으로 긴 수명을 가지며, 사용자를 식별하는 정보를 포함하지 않는다. 일반적으로 여러 일 또는 몇 주에서 몇 달 동안 유효함.
  매우 민감한 정보이므로 안전하게 저장되어야 하며, 일반적으로 클라이언트의 서버에서 관리
  사용자의 비밀번호를 다시 입력하지 않고도 Access Token을 갱신할 수 있어 사용자 경험을 향상시킴
  Access Token은 일반적으로 짧은 유효 기간(예: 15분)을 가지는데 만료되면, Refresh Token을 사용하여 새로운 Access Token을 얻고 다시 로그인할 필요 없음
  Refresh Token 역시 일정 기간 후에 만료될 수 있으며, 이 경우 사용자는 다시 로그인해야 함

5. 세션 기반 인증 방식의 동작 과정을 설명해 주세요.

• 사용자 로그인 시도 -> 서버에 전송 -> 서버는 사용자를 인증하고 해당 사용자에 대한 세션을 생성 (세션은 서버 측에서 관리되고 고유한 세션 ID를 할당함) -> 서버는 세션 ID를 클라이언트에게 전송함 (일반적으로 쿠키를 통해 클라이언트에게 저장됨) -> 클라이언트는 세션 ID를 가지고 서버에 요청을 보낼 때, 요청 헤더 또는 쿠키에 세션 ID를 포함하여 전송함
  클라이언트는 세션 ID를 저장하고 요청에 포함하여 서버와의 상호 작용을 수행하며, 서버는 세션을 관리하고 유지함

  토큰 기반 인증 방식과 세션 기반 인증 방식의 큰 차이점은???

• 토큰 기반 인증에서는 사용자 정보와 권한 정보가 토큰(주로 JSON Web Token 또는 JWT)에 포함되어 클라이언트 측에 저장됩니다. 토큰은 클라이언트에서 안전하게 관리됨

• 세션 기반 인증에서는 사용자 정보와 세션 상태가 서버 측에 저장되며, 서버에서 관리됨.. 라이언트는 세션 ID만을 저장하고 서버에 전달함

• 토큰 기반 인증은 상태를 서버에 저장하지 않기 때문에 서버는 세션 상태를 유지하지 않아도 되며, 확장성이 높다.

• 세션 기반 인증은 상태를 서버에 저장하고 관리합니다. 서버는 클라이언트의 상태를 유지하고, 클라이언트가 로그인 상태를 유지하려면 세션 ID를 보내야 함

• 토큰 기반 인증은 서버 확장성 측면에서 우수한 성능을 제공합니다. 각 요청은 자체 포함된 토큰을 가지고 있으므로, 서버 간에 상태 공유나 세션 관리가 필요하지 않다.

• 클라이언트가 토큰을 폐기하거나 만료시키면 로그아웃을 간단하게 처리 가능

• 세션은 서버 측에서 종료해야 하므로 로그아웃 및 세션 종료 과정이 좀 더 복잡할 수 있음.

토큰 기반 인증 방식이 모바일 애플리케이션에서 많이 사용되는 이유???
모바일 애플리케이션은 서버 상태를 관리하지 않고도 사용자 인증을 처리할 수 있으며, 서버 확장성을 높일 수 있음
종합적으로, 모바일 애플리케이션에서 토큰 기반 인증은 보안(모바일 앱은 사용자 개인 정보와 민감한 데이터에 대한 강력한 보안 요구를 가집니다. 토큰 기반 인증은 토큰이 암호화되고 안전하게 저장되므로 사용자 데이터 보호를 강화 가능), 오프라인 작동(사용자 인증 정보를 클라이언트에 저장), API 통합(토큰은 API 요청과 응답에 쉽게 포함될 수 있으며, 이를 통해 보안 및 권한 관리를 용이), 다양한 환경 호환성 등 다양한 요구 사항을 충족시키기 위한 효과적인 방법으로 선택됨

JWT(JSON Web Token)

JWT(Json Web Token)는 말그대로 웹에서 사용되는 JSON 형식의 토큰에 대한 표준 규격
JWT 토큰 웹에서 보통 Authorization HTTP 헤더를 Bearer <토큰>의 형태로 설정하여 클라이언트에서 서버로 전송되며, 서버에서는 토큰에 포함되어 있는 서명(signature) 정보를 통해서 위변조 여부를 빠르게 검증 가능
하나의 JWT 토큰은 헤더(header)와 페이로드(payload), 서명(signature) 이렇게 세 부분으로 이루어지며 각 구역이 . 기호로 구분됨

JWT는 실무에서 OAuth나 OIDC 프로토콜과 함께 API의 인증이나 인가를 위해서 주로 사용이 된다.

JWT
https://www.daleseo.com/jwt/

면접 질문

1. JWT로 사용자의 아이디와 비밀번호를 저장하려고 합니다. 문제가 있을까요?

• JWT(JSON Web Tokens)는 사용자의 아이디와 비밀번호를 저장하는 데 사용해서는 안 되는 방식입니다. 아이디와 비밀번호는 민감한 정보이며, 보안상의 이유로 안전하게 다루어져야 합니다. JWT는 주로 인증 및 권한 부여를 위한 토큰으로 사용되며, 아이디와 비밀번호와 같은 비밀 정보를 저장하기에는 적합하지 않습니다.
• 클라이언트 측에서 저장된 정보는 잠재적으로 노출될 수 있으며, 따라서 아이디와 비밀번호와 같은 민감한 데이터를 저장하는 데에는 부적합
• JWT는 토큰 내에 데이터를 포함하므로, 아이디와 비밀번호를 저장하면 이러한 데이터가 토큰 내에 노출될 수 있다.*
• JWT는 보통 서명(signature)을 통해 무결성을 검증하지만, 민감한 정보를 암호화하지 않습니다. 따라서 데이터를 안전하게 보호하기 위해서는 추가적인 암호화가 필요할 수 있다.
  아이디와 비밀번호는 안전한 방식으로 서버 측에서 처리되어야 하며, 인증 후에는 사용자에게 토큰을 제공하여 클라이언트 측에서 권한 부여 및 세션 관리를 수행할 수 있다.
• 비밀번호는 최대한 안전한 방식으로 저장되어야 하며, 해시와 솔트를 사용하여 사용자 데이터를 보호해야 합니다. 이러한 보안 절차를 따르면 민감한 정보가 무단 액세스로부터 보호된다.
  

2. RefreshToken 설정할 때, 당신이 고려해야할 것은?

• 클라이언트 측에 노출되면 안되기 때문에 암호화를 해서 저장해야 한다.
• 수명을 적절하게 관리해야 한다. 너무 긴 수명인 보안 위험이 있고 너무 짧은 수명은 사용자 경험을 떨어뜨립니다.
• 토큰이 만료되었을 때는 사용자를 다시 인증하고 새로운 토큰을 발급해서 보안을 유지해야 한다. (사용자가 로그인하는 것을 의미)
• 권한을 적절하게 관리해야 한다.
• 토큰 사용을 로깅하여 보안 사고 발생 시, 추적할 수 있도록 해야 한다.
• 토큰을 클라이언트로 전송할 때 HTTPS를 사용하는 것이 좋다.
• 로그아웃하거나 액세스 권한을 취소했을 경우, 관련 RefreshToken을 폐기해야 함
• 토큰 회전을 시키므로 보안을 강화합니다.
  

3. JWT의 장단점을 설명해주세요.
   JWT는 웹 및 애플리케이션 간의 인증 및 정보 교환을 위한 토큰 기반의 인증 방식이다.

• 장점

  JSON 형식으로 데이터를 저장해서 구조가 간단하다.
  토큰의 정보와 유효성 검증을 위한 서명이 포함되어 있어서, 서버 측에서 따로 토큰 상태를 저장할 필요가 없다.
  분산 시스템에서 잘 작동해, 여러 서비스 및 서버 간에 토큰을 교환하기 적합하다.
  인터넷 표준으로 정의되어 있고, 많은 프로그래밍 언어와 플랫폼에서 지원된다.
  서로 다른 도메인에서도 인증 및 권한 부여를 쉽게 수행할 수 있다.

• 단점

  토큰 자체에 정보를 저장하고 있기 때문에 보안에 주의해야 한다. 서버 측에서 안전하게 저장하고 관리해야 한다.
  토큰이 만료되기 전에는 변경이 어렵기 때문에 토큰을 취소하거나 갱신하는 메커니즘을 별도로 구현해야 한다.
  서명에 대한 보안을 제공하지만, 암호화는 제공하지 않아서 토큰 내용이 공격자에게 노출될 수 있다.
  JWT의 서명을 검증하기 위해 키 관리가 필요하고, 이를 올바르게 관리해야 함

4. JWT는 어떤 구조로 되어있는 지 설명해주세요.

• 세 부분으로 구성된 문자열로 되어 있다.
• Header, Payload, Signature(서명)으로 구분됨, 이러한 부분을 마침표로 구분해서 하나의 문자열로 표현됨 eader.Payload.Signature
• Header는 토큰 서명에 사용되는 알고리즘을 지정하고 토큰의 유형을 지정한다.
• Payload는 실제로 전달하려는 정보를 포함하는 부분이다. 사용자 id, name, iat(발급된 시간) 같은 정보들
• Signature(서명)은 헤더와 페이로드를 결합하고, 비밀 키를 사용하여 서명된 문자열 => 토큰을 검증할 때 이 서명을 확인하여 토큰의 무결성을 검증한다.
• 서명을 통해 토큰이 변경되지 않았음을 검증하고, 헤더와 페이로드를 디코딩하여 내용을 확인
  

5. JWT의 정의와 사용하는 이유에 대해서 간단하게 말해주세요.

• JWT(JSON Web Token)는 웹 및 애플리케이션 간의 인증 및 정보 교환을 위한 토큰 기반의 인증 방식입니다. JWT는 Header(헤더), Payload(페이로드), Signature(서명)으로 구성된 토큰입니다.

Header는 토큰 유형과 서명 알고리즘을 정의하며, Payload는 클레임(Claim) 정보(토큰에 대한 속성 및 정보)를 포함하고 있습니다. 서명은 헤더와 페이로드를 결합하고 비밀 키를 사용하여 생성되며, 토큰의 무결성을 검증하는 데 사용됩니다.

• 사용 이유

  사용자를 인증하고 사용자에게 특정 권한을 부여하는 데 사용
  분산 시스템에서 효과적, 여러 서비스 간에 사용자 인증 및 권한 정보를 공유하는 데 사용되어 중앙 집중식 인증 시스템을 구축할 필요가 없다.
  토큰을 클라이언트나 데이터베이스에 저장하지 않고도 유효성을 검증 가능, 서버에서 토큰 상태를 관리하는 부담이 줄어든다.

  토큰이 자체적으로 모든 필요한 정보를 포함하고 있어서, 서버 측에서 추가적인 상태를 유지하거나 저장할 필요가 없다는 의미
  서버의 관리 부담이 줄어든다.

  JWT는 웹 표준으로 정의되어 있어 다양한 플랫폼 및 언어에서 사용

OAuth

나의 서비스, OAuth를 통해 accessToken을 획득
연동 하려는 서비스에 접근 가능

Client, Resource Owner & Authorization Server, Resource Server

Client ID, Client Secret (외부에 노출되면 안됨), Authorized redirect URIs

scope

Resource Server -> Resource Owner에게 authorization code(임시 비밀번호)를 전송
id와 secret 포함해서
redirect

authorization code 지우고 accessToken 발급해서 Client로 보냄, 해당 accessToken을 가진 사람에게 허용

accessToken 발급

Authorization: Bearer 방식이 더 안전하고 선호됨

accessToken은 수명이 있다.
수명이 끝나면 refresh Token을 Authorization Server에 보내서 accessToken 다시 발급

서버 마다 다름

https://www.youtube.com/watch?v=hm2r6LtUbk8&list=PLuHgQVnccGMA4guyznDlykFJh28_R08Q-&index=3

면접 질문

1. OAuth가 무엇인지 말하고, OAuth 1.0과 OAuth 2.0의 차이를 말하세요.

• OAuth(Open Authorization)는 인터넷 사용자나 서비스가 다른 웹 사이트 또는 앱을 대신하여 제한적으로 자원에 접근할 수 있도록 권한을 부여하기 위한 개방형 표준 프로토콜
• OAuth는 주로 인증 및 권한 부여를 위해 사용됨
• OAuth 1.0은 서명된 요청을 통해 보안을 유지, OAuth 2.0은 토큰 기반 접근을 사용하고 토큰을 통해 권한을 부여하고 보안을 유지
• OAuth 2.0은 구현이 더 간단하며, 다양한 인증 방식(인증 코드, 암시적 인증, 패스워드 인증 등)을 지원
• OAuth 1.0에서는 액세스 토큰만 사용하고 OAuth 2.0에서는 인증 토큰(액세스 토큰)과 리프레시 토큰을 사용한다.
• OAuth 2.0은 세션을 유지하지 않고도 토큰을 교환 가능

2. OAuth의 장점을 설명해주세요.

• OAuth를 사용하면 클라이언트 애플리케이션이 사용자의 비밀번호를 저장하거나 전송하지 않고도 서비스에 접근 가능 => 사용자의 비밀번호가 노출되거나 저장되어 보안에 취약해지는 상황을 방지
• 사용자가 소셜 미디어 계정으로 로그인할 때, 해당 계정을 사용해 다른 서비스에도 간편하게 로그인 권한 부여 가능, 사용자 경험을 향상시키고 회원가입 절차를 간소화할 수 있다.
• OAuth를 사용하면 서버 측에서 사용자의 인증 및 권한을 관리하는 데 효율적
• OAuth는 표준화된 프로토콜로서 다양한 플랫폼 및 언어에서 지원
• 다른 도메인에서 서비스에 접근할 때, 크로스 도메인 인증을 쉽게 처리 가능

3. OAuth 인증 과정을 설명해주세요.

• OAuth 2.0를 기준으로 OAuth 인증 과정

  • 클라이언트 등록: 클라이언트 애플리케이션 등록 및 클라이언트 ID, 시크릿(비밀 키) 발급.
  • 사용자 로그인: 사용자가 서비스 제공자에 로그인.
    권한 부여: 사용자가 클라이언트에게 권한을 부여.
  • 인증 코드 발급: 서비스 제공자가 클라이언트에게 인증 코드 발급.
  • 액세스 토큰 요청: 클라이언트가 인증 코드와 시크릿으로 액세스 토큰 요청.
  • 액세스 토큰 발급: 서비스 제공자가 액세스 토큰 발급.
  • 자원 접근: 클라이언트가 액세스 토큰으로 자원에 접근.
  • 액세스 토큰 검증: 자원 서버가 토큰을 검증하여 자원 제공.

OAuth는 클라이언트가 사용자의 인증 정보를 공유하지 않고도 자원에 접근할 수 있도록 하는 인증 방법이다.

4. OAuth 2.0에서 발생할 수 있는 보안 취약점 중 하나를 설명해주세요.

• OAuth 2.0에서의 보안 취약점 중 하나는 "리다이렉션 URI 조작"입니다. 이 취약점은 악의적인 공격자가 인증 후 사용자를 클라이언트 대신 자신의 서버로 리다이렉트할 수 있는 상황을 가리킵니다. 이를 방지하기 위해서는 클라이언트 등록 시 리다이렉션 URI를 검증하고, 안전한 통신 및 인증 코드 교환을 보장해야 합니다.

공격자는 악의적인 URL을 주입하여 사용자를 피싱 사이트나 악성 웹 페이지로 리다이렉트시킬 수 있습니다.
OAuth와 같은 인증 및 권한 부여 프로토콜에서 리다이렉션 URI를 사용할 때 발생할 수 있습니다.
공격자가 리다이렉션 URI를 조작하여 허가받지 않은 액세스 토큰을 획득하거나, 피싱 공격을 수행할 수 있습니다

+) CSRF

5. Resource Owner와 Client, Resource Server, Authorization Server 각각의 역할을 간략히 말해 주세요.

• OAuth 2.0에서의 역할 간략 설명:

  • Resource Owner (리소스 소유자): 리소스에 대한 권한을 가진 사용자.
  • Client (클라이언트): 리소스에 접근하기 위한 애플리케이션 또는 서비스.
  • Resource Server (리소스 서버): 보호된 리소스 관리와 액세스를 제공하는 서버. 코카콜라 본사
  • Authorization Server (인증 서버): 권한 부여와 액세스 토큰 발급을 담당하는 서버. 코카콜라 공장