프론트엔드 기술면접 - 쿠키, 세션, 토큰 설명

쿠키(Cookie)

쿠키란 브라우저에 저장되는 정보를 말합니다. 브라우저는 사용자의 컴퓨터에 설치된 소프트웨어이므로 쿠키는 사용자가 갖고 있는 정보라고 할 수 있습니다.

다시말해, 쿠키(Cookie)는 웹 브라우저와 웹 서버 간에 정보를 주고받을 때 사용되는 작은 데이터 조각입니다. 이 데이터는 텍스트 형식으로 저장되며, 주로 사용자와 웹 서버 간의 상호 작용을 추적하고 저장하는 데 사용됩니다. 쿠키는 다음과 같은 몇 가지 중요한 특징을 가지고 있습니다:

저장 및 전송: 웹 서버가 클라이언트(브라우저)에 쿠키를 설정하면, 브라우저는 해당 쿠키를 저장하고 나중에 같은 서버로 요청을 보낼 때 해당 쿠키를 함께 전송합니다.

도메인 제한: 쿠키는 특정 도메인 또는 하위 도메인과 관련되며, 한 도메인의 쿠키는 다른 도메인으로 전달되지 않습니다. 예를 들어, 유튜브에서 설정한 쿠키는 유튜브 도메인에서만 사용됩니다.

유효기한: 각 쿠키는 유효기한을 가지며, 기간 동안만 유지됩니다. 유효기한이 만료된 쿠키는 브라우저에서 삭제됩니다.

 

세션(Session)과 토큰(Token)

세션: 세션이란 서버가 나를 알아보는 방법입니다. session은 비밀번호와 같은 인증 정보를 쿠키에 저장하지 않고 대신에 사용자의 식별자인 session id 를 저장합니다. 서버에는 인증 정보와 더불어 이 ID에 해당하는 사용자의 정보를 저장합니다. 그래서 세션은 서버 측에서 사용자의 상태를 추적하는 방법 중 하나입니다. 사용자가 웹 서버에 접속하면 서버는 해당 사용자에 대한 고유한 식별자를 생성하고 관리합니다. 이 식별자는 일반적으로 쿠키를 통해 클라이언트에게 전달됩니다. 세션을 통해 서버는 사용자의 상태 및 데이터를 유지하며, 사용자가 접속을 끝내면 해당 세션 정보는 일반적으로 삭제됩니다. 세션은 사용자의 활동 중간에 정보를 유지하는 데 유용하며, 사용자 인증 및 권한 관리 등에도 사용됩니다.

토큰: 토큰은 인증 및 권한 부여를 위한 특별한 문자열로 사용됩니다. 주로 웹 API 및 웹 서비스에서 사용됩니다. 토큰은 사용자가 인증되었음을 증명하고, 서비스에 접근 권한을 부여하는 데 사용됩니다. 토큰은 일반적으로 JSON Web Token(JWT) 형식을 사용하며, 클라이언트가 서버에 인증 정보를 제공할 때 헤더 또는 요청 매개변수로 전달됩니다. 토큰은 세션과는 달리 서버 측에서 사용자의 상태를 추적하지 않으며, 클라이언트 측에서 보다 자유롭게 관리할 수 있습니다.

세션과 토큰은 각각의 용도와 사용 사례에 따라 선택되며, 웹 응용 프로그램 또는 서비스의 요구 사항과 보안 정책에 따라 다를 수 있습니다.

 

 

 

질문) 쿠키의 장단점을 말해주세요

장점

쿠키가 담긴 HTTP 요청이 도중에 노출되더라도 쿠키 자체(세션 ID) 는 유의미한 값을 갖고 있지 않습니다. 중요한 정보는 서버 세션에 존재합니다.
고유의 ID 값을 발급받습니다.
서버의 저장공간 절약

 

 

단점

보안 취약 : 요청 시 쿠키 값을 그대로 보냄
작은 허용 용량 : 사이트 당 20개, 모두 합쳐 300개가 최대. 각 쿠키는 4Byte를 넘을 수 없음.
웹 브라우저마다 지원 형태가 다름
웹 브라우저를 변경할 경우 다른 웹브라우저에서 저장한 쿠키값을 사용할 수 없음
사용자가 보안상의 문제로 거부할 경우 사용 불가능
네트워크 부하 : 쿠키의 크기가 클 경우 네트워크 부하가 커짐
한번에 하나의 정보만 저장할 수 있음

 

질문) 세션의 장단점을 말해주세요

장점

어느정도 보안 유지 : 최초 접속 때를 제외하고 SessionID만 사용
큰 허용 용량 : 저장 개수나 용량 제한 없음(서버 용량 충분 시)
서버에 저장되므로 클라이언트의 웹브라우저에 의존하지 않아도 됨
데이터를 Hash Table에 저장. 한 번에 많은 정보를 하나의 세션 객체에 저장 가능
SessionID만 보내므로, 세션의 크기가 커도 네트워크 부하가 거의 없음

 

단점

서버에 부하 : 서버에 데이터를 저장하므로 세션 양이 많아질수록 서버에 부하가 커짐

 

 

질문) Persistence Cookie란 무엇인가요?

지속쿠키는 세션쿠키와 다르게 삭제되지 않고 더 길게 유지가 가능하다. 지속쿠키는 디스크에 저장되며, 브라우저를 닫거나 컴퓨터를 재시작해도 남아닜다. 사용자 로그인 항상 유지와 같은 곳에 사용한다.

 

 

질문) Session Cookie란 무엇인가요?

사용자가 사이트 탐색 시에 관련한 설정들과 선호사항을 저장하는 임시 쿠키이다. 브라우저를 닫는 순간 삭제된다.

 

질문) Persistence Cookie와 Session Cookie의 차이점은 무엇인가요?

세션쿠키와 지속쿠키의 차이점은 파기시점이다. Discard라는 파라미터가 설정되어 있거나, 파기까지 남은시간인 Expires또는 Max-Age라는 파라미터가 없으면 세션쿠키이다.

 

 

질문) 세션의 동작 방식에 대해 설명해주세요

 

세션의 동작 방식으로는 다음과 같습니다.

1. 클라이언트가 서버에 접속 시 세션 ID를 발급 받는다.
2. 클라이언트는 세션 ID에 대해 쿠키를 사용해 브라우저에 저장한다.
3. 클라이언트는 서버에 요청할 때, 이 쿠키의 세션 ID를 같이 서버에 전달해서 요청한다.
4. 서버는 세션 ID를 전달받아 세션 ID로 세션에 있는 클라이언트 정보를 가져와서 사용한다.
5. 클라이언트 정보로 서버 요청을 처리하며 클라이언트에 응답한다.

 

토큰의 과정에 대해 설명해주세요.

토큰 기반 인증 시스템을 사용하면 방문자가 자격 증명을 한 번만 확인합니다. 자격 증명이 확인되면 토큰이 할당되어 정해진 시간 동안 액세스가 가능합니다.

프로세스는 다음과 같습니다.

요청: 사용자가 서버 또는 보호되는 리소스에 대한 액세스를 요청합니다. 이때 비밀번호를 이용한 로그인이나 그 밖에 지정된 프로세스가 개입될 수 있습니다.
확인: 서버가 해당 사용자의 액세스 여부를 확인합니다. 이때는 사용자 이름에 대한 비밀번호 확인 또는 그 밖에 지정된 프로세스가 개입됩니다.
토큰: 서버가 링, 키, 휴대전화와 등의 인증 디바이스와 통신합니다. 확인을 마치면 서버가 토큰을 발급하여 사용자에게 전달합니다.
저장: 작업이 지속되는 동안 토큰이 사용자의 브라우저에 저장됩니다.
사용자가 서버에서 다른 곳에 방문하려고 하면 토큰이 서버와 다시 통신합니다. 토큰에 따라 액세스가 허용되기도 하고 거부되기도 합니다.

관리자가 토큰에 대한 사용 제한을 설정하기도 합니다. 예를들어, 사용자가 로그아웃하 지정된 시간이 지나면 토큰이 자동으로 파기되도록 설정할 수 있습니다.

 

질문) Access Token과 Refresh Token에 대해 설명해주세요.

Access Token(JWT)를 통한 인증 방식의 문제는 만일 제 3자에게 탈취당할 경우 보안에 취약하다는 점입니다.

유효기간이 짧은 Token의 경우 그만큼 사용자는 로그인을 자주 해서 새롭게 Token을 발급받아야 하므로 불편합니다. 그러나 유효기간을 늘리자면, 토큰을 탈취당했을 때 보안에 더 취약해지게 됩니다.

이때 “그러면 유효기간을 짧게 하면서 좋은 방법이 있지는 않을까?”라는 질문의 답이 바로 “Refresh Token”입니다.

Refresh Token은 Access Token과 똑같은 형태의 JWT입니다. 처음에 로그인을 완료했을 때 Access Token과 동시에 발급되는 Refresh Token은 긴 유효기간을 가지면서, Access Token이 만료됐을 때 새로 발급해주는 열쇠가 됩니다(여기서 만료라는 개념은 그냥 유효기간을 지났다는 의미입니다.)

OAuth란 무엇인가요?

각종 웹, 모바일 어플리케이션에서 타사의 API를 사용하고 싶을 때 권한 획득을 위한 프로토콜입니다.

인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준입니다.

질문) OAuth의 장점을 설명해주세요.
이용하려는 서비스마다 회원가입을 일일이 다 할 필요없이 기존의 사용하던 타사의 정보를 이용(goole, facebook 등)하여 로그인을 진행 할 수 있습니다.
타사의 정보를 통해 특정 사이트를 이용한다는 것은 매우 위험할 수 있으나 직접 타사의 아이디와 비밀번호를 입력하던 예전 방식보다 안전한 사용을 제공합니다.
정보는 회원 정보뿐만 아니라 기타 API에 대한 정보에도 접근이 가능합니다

 

질문) OAuth의 흐름을 설명해주세요.

OAuth 동작에 관여하는 참여자는 크게 세 가지로 구분할 수 있습니다.

Resource Server : Client가 제어하고자 하는 자원을 보유하고 있는 서버입니다. Facebook, Google, Twitter 등이 이에 속합니다.
Resource Owner : 자원의 소유자입니다. Client가 제공하는 서비스를 통해 로그인하는 실제 유저가 이에 속합니다.
Client : Resoure Server에 접속해서 정보를 가져오고자 하는 클라이언트(웹 어플리케이션)입니다.
첫번째로, Client(웹 어플리케이션)가 Resource Server를 이용하기 위해서는 자신의 서비스를 등록함으로써 사전 승인을 받아야 합니다.
등록 절차를 통해 세 가지 정보를 부여받습니다.

Client ID : 클라이언트 웹 어플리케이션을 구별할 수 있는 식별자이며, 노출이 무방합니다.
Client Secret : Client ID에 대한 비밀키로서, 절대 노출해서는 안 됩니다.
Authorized redirect URL : Authorization Code를 전달받을 리다이렉트 주소입니다.
두번째로 Resource Owner의 승인을 받습니다.
Resource Owner는 Resource Server에 접속하여 로그인을 수행합니다. 로그인이 완료되면 Resource Server는 Query String으로 넘어온 파라미터들을 통해 Client를 검사합니다.

파라미터로 전달된 Client ID와 동일한 ID 값이 존재하는지 확인합니다.
해당 Client ID에 해당하는 Redirect URL이 파라미터로 전달된 Redirect URL과 같은지 확인합니다.
검증이 마무리 되면 Resource Server는 Resource Owner에게 다음과 같은 질의를 보냅니다.

명시한 scope에 해당하는 권한을 Client에게 정말로 부여할 것인가?
허용한다면 최종적으로 Resource Owner가 Resource Server에게 Client의 접근을 승인하게 됩니다.

세번째로 Resource Server의 승인입니다.
Resource Owner의 승인이 마무리 되면 명시된 Redirect URL로 클라이언트를 리다이렉트 시킵니다. 이 때 Resource Server는 Client가 자신의 자원을 사용할 수 있는 Access Token을 발급하기 전에, 임시 암호인 Authorization Code를 함께 발급합니다.

Client는 해당 토큰을 서버에 저장해두고, Resource Server의 자원을 사용하기 위한 API 호출시 해당 토큰을 헤더에 담아 보냅니다.

이후 Access Token을 헤더에 담아 API를 호출하면, 해당 계정과 연동된 Resource Server의 풍부한 자원 및 기능들을 내가 만든 웹 어플리케이션에서 사용할 수 있습니다.

 

JWT에 대해 설명해주세요

JWT(Json Web Token)은 위와 같은 일련의 과정속에서 나타난 하나의 인터넷 표준 인증 방식입니다. 말그대로 인증에 필요한 정보들을 Token에 담아 암호화시켜 사용하는 토큰입니다.

따라서 사실 기본적인 인증을 진행하는 구조는 Cookie때와 크게 다르지는 않습니다. 다만, 강조되는 점은 JWT는 서명된 토큰이라는 점입니다. 공개/개인 키를 쌍으로 사용하여 토큰에 서명할 경우 서명된 토큰은 개인 키를 보유한 서버가 이 서명된 토큰이 정상적인 토큰인지 인증할 수 있다는 이야기이죠.

이러한 JWT의 구조 때문에 인증 정보를 담아 안전하게 인증을 시도하게끔 전달할 수 있는 것입니다.

 

질문) JWT는 어떤 구조로 되어있나요?

Header : header에는 보통 토큰의 타입이나, 서명 생성에 어떤 알고리즘이 사용되었는지 저장합니다.
Payload : payload에는 보통 Claim이라는 사용자에 대한, 혹은 토큰에 대한 property를 key-value의 형태로 저장합니다. Claim이라는 말 그대로 토큰에서 사용할 정보의 조각입니다. 가장 중요한 것은 payload에 민감한 정보를 담지않는 것입니다. 위에 header와 payload는 json이 디코딩되어있을 뿐이지 특별한 암호화가 걸려있는 것이 아니기 때문에 누구나 jwt를 가지고 디코딩을 한다면 header나 payload에 담긴 값을 알 수 있기 때문입니다. 그래서 JWT는 단순히 “식별을 하기위한” 정보만을 담아두어야하는 것입니다.
Signature : 가장 중요한 서명입니다. header를 디코딩한 값, payload를 디코딩한 값을 위처럼 합치고 이를 서버가 가지고 있는 개인키를 가지고 암호화되어있는 상태입니다.

 

질문) JWT의 장점은 무엇인가요?

이미 토큰 자체가 인증된 정보이기 때문에 세션 저장소와 같은 별도의 인증 저장소가 “필수적”으로 필요하지 않습니다.
세션과는 다르게 클라이언트의 상태를 서버가 저장해두지 않아도 됩니다.
signature를 공통키 개인키 암호화를 통해 막아두었기 때문에 데이터에 대한 보안성이 늘어납니다.
다른 서비스에 이용할 수 있는 공통적인 스펙으로써 사용할 수 있습니다.

 

질문) JWT의 한계점은 무엇인가요?

쿠키, 세션때와는 다르게 base64인코딩을 통한 정보를 전달하므로 전달량이 많다. 따라서 네트워크 전달 시 많은 데이터량으로 부하가 생길 수 있다.
Payload에는 암호화가 되어있지 않기 때문에 민감 정보를 저장할 수 없다.
토큰이 탈취당하면 만료될 때까지 대처가 불가능하다.
한계점을 보안하는 가장 많이 사용하는 방법으로 JWT를 처음 발급할 때 Access Token과 함께 Refresh Token이라는 토큰을 발급하여 짧은 만료시간을 해결하는 방법입니다.