세션 및 쿠키, JWT, OAuth2?

H·2023년 1월 9일

JWT JWT토큰 장단점 OAuth 인증프로세스 oauth2 세션 쿠키 쿠키와 세션의 차이

Basic

목록 보기

5/5

쿠키는 자동완성이나, 팝업 일주일간 보지 않기 등 사용자의 편의를 위하는 것이지만 지워지고, 조작되도 큰 지장이 없는 수준의 정보들을 저장하는데 사용됩니다.

세션은 사용자나 다른 누군가에게 노출되면 안되는 중요한 정보들은 서버안에서 다뤄집니다.쿠키로 노출시켜서는 안될 정보들이 있고, 세션을 남발하면 서버에 부담이 되어 과부하가 일어나기 때문에 웹을 설계할 때는 이 정보는 쿠키에 저장할 지 세션에 저장할 지 적절히 고려해야 합니다.

JWT는 사용자가 로그인을 하면 서버에서 발행해주는 토큰을 가지고 브라우저의 저장소에 토큰을 유지시키는 방법입니다.

OAuth2는 별도의 회원 가입없이 타 플랫폼의 아이디만 있으면 서비스를 이용 할 수 있어, 인증의 과정을 '타 서비스에게 위임'하는 인증방식입니다.

세션 및 쿠키

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

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

HTTP 프로토콜의 특징

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

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

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

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

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

따라서 서버는 클라이언트가 누구인지 계속 인증을 해줘야 해, 매우 귀찮고 번거로운 일입니다.

그런 번거로움을 해결하는 방법이 바로 쿠키와 세션입니다.

쿠키(Cookie) - 클라이언트 저장

HTTP의 일종으로 사용자가 어떠한 웹 사이트를 방문할 경우, 그 사이트가 사용하고 있는 서버에서 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일입니다.

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만 저장하고 그것으로 구분하여 서버에서 처리하기 때문에 비교적 보안성이 높습니다.
라이프 사이클은 쿠키도 만료기간이 있지만 파일로 저장되기 때문에 브라우저를 종료해도 정보가 유지될 수 있습니다.
또한 만료기간을 따로 지정해 쿠키를 삭제할 때까지 유지할 수도 있습니다.
반면에 세션도 만료기간을 정할 수 있지만, 브라우저가 종료되면 만료기간에 상관없이 삭제됩니다.
속도 면에서 쿠키가 더 우수하며,
쿠키는 쿠키에 정보가 있기 때문에 서버에 요청 시 속도가 빠르고
세션은 정보가 서버에 있기 때문에 처리가 요구되어 비교적 느린 속도를 냅니다.

보통 쿠키와 세션의 차이에 대해서 저장 위치와 보안에 대해서는 잘 알고 있지만, 사실 가장 중요한 것은 라이프사이클입니다.

⇒ 쿠키는 브라우저를 종료해도 파일로 남아 있지만, 세션은 브라우저 종료시 세션을 종료합니다.

Q. 세션을 사용하면 좋은데 왜 쿠키를 사용할까?

A. 세션이 쿠키에 비해 보안이 높은 편이나 쿠키를 사용하는 이유는 세션은 서버에 저장되고, 서버의 자원을 사용하기에 서버 자원에 한계가 있고, 속도가 느려질 수 있기 때문에 자원관리 차원에서 쿠키와 세션을 적절한 요소 및 기능에 병행 사용하여 서버 자원의 낭비를 방지하며 웹사이트의 속도를 높일 수 있습니다.

쿠키와 세션 그리고 캐시(Cache)? 캐시(Cache)는 웹 페이지 요소를 저장하기 위한 임시 저장소이고, 쿠키/세션은 정보를 저장하기 위해 사용됩니다. 캐시는 웹 페이지를 빠르게 렌더링 할 수 있도록 도와주고, 쿠키/세션은 사용자의 인증을 도와줍니다.
- 캐시는 이미지, 비디오, 오디오, css, js파일 등 데이터나 값을 미리 복사해 놓는 리소스 파일들의 임시 저장소
- 저장 공간이 작고 비용이 비싼 대신 빠른 성능을 제공
- 같은 웹 페이지에 접속할 때 사용자의 PC에서 로드하므로 서버를 거치지 않음
- 이전에 사용된 데이터가 다시 사용될 가능성이 많으면 캐시 서버에 있는 데이터를 사용
- 그래서 다시 사용될 확률이 있는 데이터들이 빠르게 접근 가능 (페이지의 로딩 속도 ↑)
- 캐시 히트(hit) : 캐시를 사용할 수 있는 경우 (ex. 이전에 왔던 요청이랑 같은 게 왔을 때)
- 캐시 미스(miss) : 캐시를 사용할 수 없는 경우 (ex. 웹서버로 처음 요청했을 때)
  
  JWT 란?

Json Web Token 약자로 모바일이나 웹의 사용자 인증을 위해 사용하는 암호화된 토큰을 의미합니다.

JWT 정보를 request에 담아 사용자를 정보 열람, 수정 등 개인적인 작업 등을 수행할 수 있게 합니다.

언제 사용하는가

로그인
- 사용자 로그인 -> 서버가 해당 유저의 토큰을 유저에게 전달 (JWT)> 유저가 요청을 할때 토큰을 포함해서 전달> 서버는 해당 토큰일 권한이 있는지 유효하고 인증이 되었는지 확인하고 작업을 진행
- 서버는 유저의 세션을 유지할 필요가 없고 유저가 보낸 토큰만 확인하면 되므로 서버의 자원을 아낄수 있습니다.
정보교류
- JWT는 두 개체 사이에서 안정성있게 정보를 교환하기에 좋은 방법입니다. 그 이유는, 정보가 sign 이 되어있기 때문에 정보를 보낸이가 바뀌진 않았는지 또 정보가 도중에 조작되지는 않았는지 검증할 수 있습니다.

JWT 구조

Header, Payload, Signature의 3부분으로 이루어져 있습니다.
Json 형태인 각 부분은 Base64로 인코딩 되어 표현됩니다. 각 부분을 이어주기 위해 .구분자를 반환합니다.
Base64는 암호화된 문자열이 아니고, 같은 문자열에 대해 항상 같은 문자열을 반환합니다.

Header/ Payload/ Signature

토큰의 타입과 해시 암호화 알고리즘으로 구성되어 있습니다.

{ "typ": "JWT", "alg": "HS256" }

payload

토큰에 담을 정보가 들어있습니다. 여기에 담은 정보의 한’조각’을 클레임(claim)이라고 부르고, 이는 name/value 의 한쌍으로 이뤄져있습니다. 클레임의 종류는 등록된(registered)클레임, 공개(public)클레임, 비공개(private)클레임 이 존재합니다.

{ "sub": "1234567890", **//** 등록된 플레임 "name": "John Doe", **//** 비공개 플레임 "iat": 1516239022 **//** 등록된 플레임 }

signature

서명은 [헤더 base64 + 페이로드 base64 + SECRET_KEY ] 를 사용하여 JWT 백엔드에서 발행되며, 각 요청시 서명이 확인됩니다. 헤더 또는 페이로드의 정보가 클라이언트에 의해 변경된 경우 서명이 무효화됩니다.

JWT토큰 장단점

JWT의 장점

JWT 의 주요한 이점은 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 별도의 인증 저장소가 필요 없습니다.
쿠키를 전달하지 않아도 되므로 쿠키를 사용함으로써 발생하는 취약점이 사라집니다.
URL 파라미터와 헤더로 사용
트래픽 대한 부담이 낮음
REST 서비스로 제공 가능
내장된 만료
독립적인 JWT

JWT의 단점

Self-contained: 토큰 자체에 정보를 담고 있으므로 양날의 검이 될 수 있습니다.
토큰 길이: 토큰의 페이로드(Payload)에 3종류의 클레임을 저장하기 때문에, 정보가 많아질수록 토큰의 길이가 늘어나 네트워크에 부하를 줄 수 있습니다.
Payload 인코딩: 페이로드(Payload) 자체는 암호화 된 것이 아니라, BASE64로 인코딩 된 것입니다. 중간에 Payload를 탈취하여 디코딩하면 데이터를 볼 수 있으므로, JWE로 암호화하거나 Payload에 중요 데이터를 넣지 않아야 합니다.
Stateless: JWT는 상태를 저장하지 않기 때문에 한번 만들어지면 제어가 불가능합니다. 즉, 토큰을 임의로 삭제하는 것이 불가능하므로 토큰 만료 시간을 꼭 넣어주어야 합니다.
Tore Token: 토큰은 클라이언트 측에서 관리해야 하기 때문에, 토큰을 저장해야 합니다.

JWT 를 통한 인증 절차

사용자가 id와 password를 입력하고 서버로 로그인 요청을 보냅니다.
서버는 비밀 키(secret key) 를 통해서 서명을 하고 공개 키(public key)로 암호화 시킨 Access Token을 발급합니다.
Access Token을 사용자(클라이언트)에게 보냅니다. 여기까지하면 사용자는 로그인이 된 것입니다.
로그인 정보가 필요한 API Call마다 토큰을 실어서 보냅니다.

사용자(클라이언트)는 API를 요청할 때 Authorization Header (권한)에 Access Token을 담아서 보냅니다.

서버에서는 사용자가 보낸 토큰을 공개 키(public key)로 서명을 체크하고, 안에 담긴 정보를 확인합니다.

서버는 secret key로 사용자가 보낸 토큰의 서명을 복호화하여서 유효한 토큰인지 확인합니다.

서버가 요청에 대한 응답을 사용자(클라이언트)에게 전달합니다.

OAuh2

OAuth를 사용하는 이유

보안의 수준을 알 수 없는 애플리케이션에서 일일히 계정을 만들어 사용하면 ID/PW 관리가 어렵고 개인정보가 유출되면 연쇄적으로 피해가 심각하기에, 보안 수준이 어느정도 검증된 사이트(ex, google, facebook)의 API를 이용해서 인증을 받는 방법이 보안상 좋기 때문입니다.

OAuth2 동작 방식

OAuth 인증 방식은 인증의 과정을 '타 서비스에게 위임'하는 인증방식.
예를 들어 내 사이트에 구글 로그인 인증을 넣었다고 해서 사용자가 구글 웹사이트에 직접 로그인하는 것이 아니라, 사용자의 정보는 내 사이트에서 관리하고, 구글 로그인 기능을 통해 구글에게 전송한 구글 계정 정보가 유효한지 확인한 후, 유효하다면 해당하는 구글 유저 정보 중 일부를 내 사이트에 제공해 주는 '인증' 과정만 처리합니다.

OAuth2.0 구성

Resource owner: 사용자.
Client: Resource Server 에서 제공하는 자원을 사용하는 애플리케이션 (예, 페이스북의 뉴스를 모아서 보여주는 앱)
Resource server(API server): 자원을 호스팅하는 서버, (예, 페이스북 사진 비디오 등)
Authorization Server: 사용자의 동의를 받아서 권한을 부여하는 서버, 일반적으로 Resource Server 와 같은 URL 하위에 있는 경우가 많음.