// 에드센스


1. JWT란?

Json Web Token의 줄임말이다. 

두 개체에서 JSON객체를 사용하여 가볍고 자가수용적인 방식으로 정보를 안정성 있게 전달해 주는 인증 방식이다.

 

 


2. 세션과의 차이점

세션

보통 로그인을 구현할때 세션로그인을 많이 사용했다. 세션로그인이란, 

이런 흐름을 가지고 진행된다.

  1. 클라이언트에서 서버로 로그인 요청을 보낸다.
  2. 서버는 로그인 정보 확인 후 세션아이디를 응답한다. 이 세션아이디는 서버에서도 가지고있는다.
  3. 이후 클라이언트의 요청에는 2번에서 응답받은 세션아이디를 쿠키에 담아서 함께 요청한다.
  4. 서버는 함께 요청된 쿠키 속의 세션아이디를 확인하여 로그인된 사용자인지 확인한다.

 

이러한 세션 로그인 방식은 단점이 있다.

 

단점.

  1. 만약 여러대의 서버가 운영된다면, 서버측에서 저장하고있는 모든 세션을 공유해야한다.
  2. 사용자가 많아질수록 서버측에서 모든 사용자의 세션들을 저장하기 부담스럽다.

 

 

그러면 JWT는 이 문제를 어떻게 해결할까?

JWT

JWT방식은 다음과 같은 흐름을 가진다.

  1. 클라이언트에서 서버로 로그인 요청을 보낸다.
  2. 서버는 로그인 정보 확인 후 토큰을 응답한다. 이 토큰은 서버에서 보관하지 않는다.
  3. 이후 클라이언트의 2번에서 응답받은 토큰을 요청에 함께 보낸다.
  4. 서버는 토큰이 유효한지 검증하고 유효하면 로그인된 사용자라고 생각한다.

 

세션방식과 다른 가장 큰 포인트는, 로그인 후 무언가를 응답으로 보내주긴하는데 JWT는 서버측에서 그걸 기억하지 않는다는 것이다. 

세션방식의 문제점 중 하나가 기억해야할 세션 아이디가 너무 많다는 것이었는데 이 문제점을 해결하는 부분이다.

서버는 자신이 발행한 토큰을 기억하지 않고, 나중에 토큰을 받으면 그 토큰이 유효한지 검증만 하면 되는 것이다.

또한 여러 디바이스나 도메인에서도 토큰에 대한 인증만 하면 되니 여러 서버가 운영될 때에도 문제 없다.

 

 

JWT가 마냥 좋은것만은 아니다.

세션은 시간에 따라 바뀌는 값을 갖는 stateful한 값이므로 어떠한 장점이 있느냐, 세션 값을 가지고있는 대상들을 제어할 수 있다. 예를 들어서 한 기기에서만 로그인이 가능하도록 구현하려 한다고 가정해보자.

1번 기기에 로그인이 돼있는데 2번 기기에서 로그인을 하면, 1번 기기의 세션을 종료하면 된다.

하지만 JWT는 사용자의 상태를 모르기 때문에 (stateless) 이것이 불가능하다. 이미 줘버린 토큰을 다시 회수할 수도 없고, 그 토큰의 발급 내용이나 정보를 서버가 추적하고 있지도 않기 때문이다. 반면 세션은 서버측의 세션저장소에 있기에 가능하다.

 

 

여담으로 지금 말한 단일 기기 로그인을 JWT로 해결하기 위한 기법도 존재한다. 

  • 최초 토큰 발행시 refresh 토큰과 access 토큰, 총 2개의 토큰을 발행한다.
  • refresh토큰은 만료기한(수명)이 꽤 길고 access토큰은 매우 짧다. 
  • refresh토큰의 상응값을 데이터베이스에도 저장한다.
  • 사용자가 요청할때 access토큰을 사용하는데 access토큰의 수명이 끝나면 refresh토큰을 사용해서 요청을 보낸다.
  • 서버는 서버측의 refresh 토큰 상응값과 비교해보고 맞다면 새로운 access토큰을 발행해 준다.
  • 즉, refresh토큰만 안전하게 관리된다면 중간에 access토큰이 탈취당해도 어자피 수명이 짧기 때문에 보안상 위협을 줄일 수 있고, 로그인 유지도 가능하다. 

 

 


3. JWT의 구성

JWT토큰은 3개의 부분으로 구성된다.

실제로는

 

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

 

이렇게 생겼다. 각 부분을 디코딩해보면 JSON형태로 나온다.

 

 

헤더 (header)

헤더는 두가지 정보를 갖는다.

typ: 토큰의 타입을 지정. 여기는 JWT가 고정으로 들어간다. 여기가 JWT여야지만 JWT기 때문에

alg: 어떤 해싱 알고리즘을 사용할지 지정한다. 해싱 알고리즘으로는 보통 HMAC SHA256 혹은 RSA 가 사용되며, 이 알고리즘은, 토큰을 검증 할 때 사용되는 signature 부분에서 사용된다.

 

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

 

 

내용 (payload)

이 부분에는 토큰에 담을 정보가 들어있다. 이 정보의 한 조각을 "클레임(Claim)"이라고 부르고 key : value의 한 쌍으로 이루어져 있다. 클레임의 종류는 3가지로 분류된다.

 

등록된(registered) 클레임

등록된 클레임은 서비스에 필요한 정보가 아니라 토큰에 대한 정보를 담기위해 이름이 이미 정해진 클레임들이다. 등록된 클레임은 Optional하다.

  • iss : 토큰 발급자 (issuer)
  • sub : 토큰 제목 (subject)
  • aud : 토큰 대상자 (audience)
  • exp : 토큰의 만료시간 (expiraton), 시간은 NumericDate 형식으로 되어있어야 하며 (예: 1480849147370) 언제나 현재 시간보다 이후로 설정돼야한다.
  • nbf : Not Before 를 의미하며, 토큰의 활성 날짜와 비슷한 개념. 여기에도 NumericDate 형식으로 날짜를 지정하며, 이 날짜가 지나기 전까지는 토큰이 처리되지 않는다.
  • iat : 토큰이 발급된 시간 (issued at), 이 값을 사용하여 토큰의 age 가 얼마나 되었는지 판단 할 수 있다.
  • jti : JWT의 고유 식별자로서, 주로 중복적인 처리를 방지하기 위하여 사용된다. 일회용 토큰에 사용하면 유용.

 

공개(public) 클레임

공개 클레임들은 충돌이 방지된 (collision-resistant) 이름을 가지고 있어야 한다. 충돌을 방지하기 위해서는, 클레임 이름을 URI 형식으로 짓는다.

 

{
    "https://velopert.com/jwt_claims/is_admin": true
}

 

비공개(private) 클레임

등록된 클레임도아니고, 공개된 클레임들도 아니다. 양 측간에 (보통 클라이언트 <->서버) 협의하에 사용되는 클레임 이름들이다. 공개 클레임과는 달리 이름이 중복되어 충돌이 될 수 있으니 사용할때에 유의.

 

{
    "username": "velopert"
}

 

Payload의 예시

{
    "iss": "llshl.com",
    "exp": "1485270000000",
    "https://llshl.com/jwt_claims/is_admin": true,
    "userId": "11028373727102",
    "username": "llshl"
}

 

 

서명 (signature)

서명은 헤더의 인코딩값과, 정보의 인코딩값을 합친후 주어진 비밀키로 해쉬를 하여 생성한다.

서버에서 요청에서 토큰을 받으면 헤더와 페이로드의 값을 서버의 비밀키와 함께 돌려서 계산된 결과값이 서명값과 일치하는지 확인한다.

 

 


한 줄 요약

"세션은 서버에서 세션아이디 보관,

JWT는 보관 없이 인증만"

 

 

 

 

참고:

'Web' 카테고리의 다른 글

[Web] REST API  (0) 2021.07.03
[Web] 세션과 쿠키  (0) 2021.07.02

이번 포스팅은 네이버 D2 유튜브에 올라온 "그런 REST API로 괜찮은가" 영상을 토대로 작성하였다.

 

 

REST(REpresentational State Transfer) API란

REST API는 REST 아키텍처를 따르는 API이다. 문장을 하나씩 뜯어보자

  • REST → 분산 하이퍼미디어 시스템(ex. 웹)을 위한 아키텍처 스타일
  • 아키텍처 스타일 → 제약 조건의 집합
  • API → API는 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스

 

즉, REST에서 정의한 제약 조건을 모두 지켜야 REST를 따른다고 말할 수 있다는 것이다.

 

 

REST의 장단점

장점

1. Easy to use

REST API의 가장 큰 장점이라고 할 수 있다. 단순히 REST API 메시지를 읽는 것 만으로도 메시지가 의도하는 바를 명확하게 파악할 수 있다. 굳이 해당 메시지의 기능이 무엇인지 알기 위해 메뉴얼을 하나씩 읽어 볼 필요가 없게 만들어 준다.

 

HTTP 인프라를 그대로 사용하기 때문에, REST API 사용을 위한 별도의 인프라 구축을 요구하지 않는다. 그리고 Stateless한 특징 때문에 수행 문맥(Execution Context)가 독립적으로 진행됨으로써 이전에 서버(호스트)에서 진행된 내용들에 대해 클라이언트가 알 필요가 없으며, 이제까지 진행된 히스토리에 대해서도 알 필요가 없게 된다. 즉 해당 URI와 원하는 메소드 자체만 독립적으로 이해하면 된다.


2. Complete Seperation between Client and Server

클라이언트는 REST API를 이용하여 서버와 정보를 주고 받는다. 위에서 언급한 Stateless 한 특징에 따라, 서버는 클라이언트의 문맥을 유지할 필요가 없게 된다. 결국 클라이언트와 서버는 서로 신경쓰지 않으며 동작하게 된다. 서로에게 무관심한 이기적인 상황인 것이다. 하지만 실제로는 각자의 역할이 명확하게 분리되어 있다는 의미로 보는게 더 맞다. 

 

이러한 장점으로 인해 플랫폼의 독립성 확장이라는 효과를 가져오고 HTTP 프로토콜만 지켜진다면 다양한 플랫폼에서 원하는 서비스를 쉽고 빠르게 개발/배포할 수 있게 된다.

 

3. Detail expression for specific data type

REST API는 헤더 부분에 URI 처리 메소드를 명시함으로써, 필요한 실제 데이터를 페이로드(바디)에 표현할 수 있도록 구성할 수 있는 기능을 제공한다. 이는 특정 메소드의 세부적인 표현 문구를 JSON, XML 등 다양한 언어를 이용하여 작성할 수 있다는 장점 뿐만 아니라, 간결한 헤더 표현을 통한 가독성 향상이라는 두마리 토끼를 잡는 효과를 가져다 주게 된다.

 

 

단점

1. Restriction of HTTP MethodREST

API는 HTTP 메소드를 사용하여 URI를 표현한다. 이러한 표현 방법은 다양한 인프라에서도 편리하게 사용할 수 있다는 장점을 주지만, 또 한편으로는 메소드 형태가 제한적 이라는 문제점을 가져오기도 한다.


2. Absence of Standard (표준의 부재)

REST API의 가장 큰 단점이라고 할 수 있는데, 바로 표준이 존재하지 않는다는 것이다.

이는 관리의 어려움과 좋은(공식화 된) API 디자인 가이드가 존재하지 않음을 의미하는데, 결국 REST API는 많은 사람들이 하나씩 쌓아올리는 ‘정당화 된 약속들’ 로 구성되고 움직이게 된다.

 

 

REST를 구성하는 스타일

  1. Client-Server
  2. Stateless
  3. Cache
  4. Uniform Interface
  5. Layered System
  6. Code-on-Demand (optional)

대체로 REST라고 부르는 것들은 위의 조건을 대부분 지키고 있다. 왜냐하면 HTTP만 잘 따라도 Client-Server, Stateless, Cache, Layered System은 다 지킬 수 있기 때문이다. Code-on-Demand는 서버에서 코드를 클라이언트로 보내서 실행할 수 있어야 한다는 것을 의미, 즉 자바스크립트를 의미한다. 이는 필수는 아니다.

 

단, 4번의 Uniform Interface는 잘 지켜지지 않는다고 한다. 

 

 

Uniform Interface 제약 조건

  • Identification of resources
  • Manipulation of resources through representations
  • Self-descriptive messages
  • Hypermedia as the engine of application state(HATEOAS)

Identification of resources은 URI로 리소스가 식별되면 된다는 것이고, Manipulation of resources through representations는 representation 전송을 통해서 리소스를 조작해야된댜는 것이다. 즉, 리소스를 만들거나 삭제, 수정할 때 http 메시지에 그 표현을 전송해야된다는 것이다. 위 2가지 조건은 대부분 잘 지켜지고 있다. 하지만 문제는 아래 2개이다. 이 2가지는 사실 우리가 REST API라고 부르는 거의 모든 것들은 지키지 못하고 있다.

 

Uniform Interface의 세번째, 네번째 조건에 대해 알아보자

 

 

세번째 조건. Self-descriptive messages

Self-descriptive message라는 것은 메시지를 봤을 때 메시지의 내용으로 온전히 해석이 다 가능해야된다는 것이다.

예를 들어 아래와 같은 메시지가 있다고 해보자

GET / HTTP/1.1

 

 

단순히 루트를 얻어오는 GET 요청이다. HTTP 요청 메시지는 목적지가 빠져있어서 Self-descriptive하지 못하다. 다음과 같이 수정할 수 있겠다.

GET / HTTp/1.1
Host: www.example.org

 

 

또 이런 것도 생각해볼 수 있다. 200 응답 메시지이며, JSON 본문이 있다.

HTTP/1.1 200 OK
[ { "op": "remove", "path": "/a/b/c" } ]

 

 

이것도 Self-descriptive 하지 않는데, 그 이유는 이걸 클라이언트가 해석하려고 하면, 어떤 문법으로 작성된 것인지 모르기 때문에 해석에 실패한다. 그렇기 때문에 Content-Type 헤더가 반드시 들어가야한다.

HTTP/1.1 200 OK
Content-Type: application/json
[ { "op": "remove", "path": "/a/b/c" } ]

 

 

 

Content-Type 헤더에서 대괄호, 중괄호, 큰따옴표의 의미가 뭔지 알게 되어, 파싱이 가능하여 문법을 해석할 수 있게 된다. 하지만 여전히 문제가 있다. op 값은 무슨 뜻이고, path가 무엇을 의미하는지는 알 수 없다. 

HTTP/1.1 200 OK
Content-Type: application/json-patch+json
[ { "op": "remove", "path": "/a/b/c" } ]

이렇게 명시를 하면 완전해진다. 이 응답은 json-patch+json이라는 미디어 타입으로 정의된 메시지이기 때문에 json-patch라는 명세를 찾아가서 이해한 다음, 이 메시지를 해석을 하면 그제서야 올바르게 메시지의 의미를 이해할 수 있게 된다.

 

 

 

 

네번째 조건. HATEOAS

REST API의 완성도를 나타내는 RMM지표를 보면 3단계의 조건으로 HATEOAS를 확인할 수 있다.

 

"애플리케이션의 상태는 Hyperlink를 이용해 전이되어야 한다."

 

HateoasREST Api를 사용하는 클라이언트가 전적으로 서버와 동적인 상호작용이 가능하도록 하는 것을 의미한다. 이러한 방법은 클라이언트가 서버로부터 어떠한 요청을 할 때, 요청에 필요한 URI를 응답에 포함시켜 반환하는 것으로 구현 가능하다.

 

 

이런 웹사이트가 있다고 해보자.

루트 홈페이지 → 글 목록 보기 GET → 글 쓰기 GET → 글 저장 POST → 생성된 글 보기 GET → 목록 보기 GET → 반복

이렇게 상태를 전이하는 것을 애플리케이션 상태 전이라고 하고, 이 상태 전이마다 항상 해당 페이지에 있던 링크를 따라가면서 전이했기 때문에 HATEOAS라고 할 수 있다. 말 그대로, 하이퍼 링크를 통한 전이가 되는 것이다.

 

HTTP/1.1 200 OK
Content-Type: text/html

<html>
<head> </head>
<body> <a href="/test"> test </a> </body>
</html>

이처럼 html은 하이퍼링크로 다음 상태로의 전이가 가능하기때문에 HATEOAS하다고 할 수 있다.

JSON의 경우에도 HATEOAS로 표현 가능하다.

 

 

{
    "account_id" : 12345,
    "balance" : "350,000"
}

이러한 JSON 표현이 있다고 했을때 이를 HATEOAS로 바꾸면

 

 

{
    "account_id" : 12345,
    "balance" : "350,000"
    "links" : {
    	{
            "rel" : "self",
            "href" : "http://localhost:8080/accounts/12345"
        },{
            "rel" : "withdraw",
            "href" : "http://localhost:8080/accounts/12345/withdraw"
        },{
            "rel" : "transfer",
            "href" : "http://localhost:8080/accounts/12345/transfer"
        }
    }
}

이렇게 표현될 수 있다.

 

 

HATEOAS를 사용함으로써 생기는 이점을 예를 들어 설명해보자면,

클라이언트가 GET 메소드로 URI 주소 '/member/1'를 호출한다면 사용자 ID1'사용자 정보'를 갖고온다고 가정해보자. 이때 동일한 URIDELETE 메소드를 호출 할 경우 사용자 삭제가 가능하고, PUT 메소드를 호출할 경우 업데이트라고 한다면 일일히 클라이언트 쪽에 알려줘야 한다는 번거로움이 발생한다. 이것을 줄이고자 호출한 URI로부터 연관된 REST API 주소 정보들을 함께 보내주는 역할을 하는 것이 HATEOAS 이다. 그럼으로써 클라이언트는 서버와 상호 작용하는 방법에 대한 사전 지식이 거의 또는 전혀 필요없이 사용 할 수 있게 되는 것이다.

 

 

 

 

 

 

참고:

더보기

'Web' 카테고리의 다른 글

[Web] JWT란?  (0) 2021.07.31
[Web] 세션과 쿠키  (0) 2021.07.02

세션과 쿠키를 사용하는 이유

HTTP(Hypertext Transfer Protocol)는 인터넷상에서 데이터를 주고 받기 위해 서버/클라이언트 모델을 따르는 통신규약이다. 이 HTTP 프로토콜에는 비연결성(Connectionless)과 비상태성(Stateless)이라는 특징이 있다.

 

 

  • Connectionless 프로토콜 (비연결지향) 
    • 클라이언트가 서버에 요청(Request)을 했을 때, 그 요청에 맞는 응답(Response)을 보낸 후 연결을 끊는 처리방식이다.
    • HTTP 1.1 버전에서 연결을 유지하고, 재활용 하는 기능이 Default 로 추가되었다.
      (keep-alive 값으로 변경 가능)
  • Stateless 프로토콜 (상태정보 유지 안함) 
    • 클라이언트와 첫번째 통신에서 데이터를 주고 받았다 해도, 두번째 통신에서 이전 데이터를 유지하지 않는다.
    • 클라이언트의 상태 정보를 가지지 않는 서버 처리 방식이다.

 

하지만 이로 인해 사용자를 식별할 수 없어서 같은 사용자가 요청을 여러번 하더라도 매번 새로운 사용자로 인식하는 단점이 있다. 이를 해결하기 위해 세션과 쿠키를 사용한다.

 

즉, 클라이언트와 정보 유지를 하기 위해 사용하는 것이 쿠키와 세션이다.

 

 

쿠키(Cookie)

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

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

쿠키의 발급/사용 절차

 

  • 쿠키 특징
    1. 이름, , 만료일(저장 기간 설정), 경로 정보로 구성되어 있다.
    2. 클라이언트에 총 300개의 쿠키를 저장할 수 있다.
    3. 하나의 도메인 당 20개의 쿠키를 가질 수 있다
    4. 하나의 쿠키는 4KB까지 저장 가능하다.

  • 쿠키의 동작 순서
    1. 브라우저에서 웹페이지에 접속한다.
    2. 클라이언트가 요청한 웹페이지를 응답으로 받으면서 HTTP 헤더를 통해 해당 서버에서 제공하는 쿠키 값을 응답으로 준다. (이러면 클라이언트는 해당 쿠키를 저장한다.)
    3. 클라이언트가 웹페이지를 요청한 서버에 재 요청시 받았던 쿠키 정보도 같이 HTTP 헤더에 담아서 요청한다.
    4. 서버는 클라이언트의 요청(Request)에서 쿠키 값을 참고하여 비즈니스 로직을 수행한다. (ex 로그인 상태 유지)

즉, HTTP요청시 서버로부터 쿠키를 발급받고 이후 요청들에 쿠키를 함께 동봉하여 요청한다.

 

  • 사용 예시
    1. 방문했던 사이트에 다시 방문 하였을 때 아이디와 비밀번호 자동 입력
    2. 팝업창을 통해 "오늘 이 창을 다시 보지 않기" 체크

 

쿠키는 사용자가 별도로 요청하지 않아도 브라우저(Client)에서 서버에 요청(Request) 시에 Request Header에 쿠키 값을 넣어 요청한다. (=자동이다.)

 

그렇다고 그 많은 쿠키 값을 굳이 모든 요청에 넣어서 비효율적으로 동작하지는 않는다. 도메인 설정을 통해서 지정한 도메인으로 요청할 때만 쿠키 값이 제공되도록 할 수도 있다.

 

 

 

 

세션(Session)

서버(Server)에 클라이언트의 상태 정보를 저장하는 기술로 논리적인 연결을 세션이라고 한다.

웹 서버에 클라이언트에 대한 정보를 저장하고 클라이언트에게는 클라이언트를 구분할 수 있는 ID를 부여하는데 이것을 세션아이디라 한다.

  • 세션 특징
    1. 세션은 쿠키를 기반하고 있지만, 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 세션은 서버 측에서 관리한다.
    2. 서버에서는 클라이언트를 구분하기 위해 Session ID를 부여하며 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지한다.
    3. 물론 접속 시간에 제한을 두어 일정 시간 응답이 없다면 정보가 유지되지 않게 설정이 가능하다.
    4. 사용자에 대한 정보를 서버에 두기 때문에 쿠키보다 보안에 좋지만, 사용자가 많아질수록 서버 메모리를 많이 차지하게 된다.
    5. 즉 동접자 수가 많은 웹 사이트인 경우 서버에 과부하를 주게 되므로 성능 저하의 요인이 된다.
    6. 클라이언트가 Request를 보내면, 해당 서버의 엔진이 클라이언트에게 유일한 ID를 부여하는 데 이것이 Session ID다.

  • 세션의 동작 순서
    1. 클라이언트가 서버에 접속 시 Session ID를 발급받는다.
    2. 클라이언트는 Session ID에 대해 쿠키를 사용해서 저장하고 가지고 있다.
    3. 클라리언트는 서버에 요청할 때, 이 쿠키의 Session ID를 서버에 전달해서 사용한다.
    4. 서버는 Session ID를 전달 받아서 별다른 작업없이 Session ID로 Session있는 클라이언트 정보를 가져온다.
    5. 클라이언트 정보를 가지고 서버 요청을 처리하여 클라이언트에게 응답한다.

 

즉. 클라이언트가 가진 쿠키에 존재하는 세션ID와 서버가 가진 세션ID를 비교하여 식별.

 

  • 사용 예시
    1. 방문했던 사이트에 다시 방문 하였을 때 아이디와 비밀번호 자동 입력
    2. 팝업창을 통해 "오늘 이 창을 다시 보지 않기" 체크

세션과 쿠키 활용

 

 

 

쿠키와 세션의 차이

  • 저장 위치
    • 쿠키는 클라이언트(브라우저)에 메모리 또는 파일에 저장하고, 세션은 서버 메모리에 저장된다.
  • 보안
    • 쿠키는 클라이언트 로컬(local)에 저장되기도 하고 특히 파일로 저장되는 경우 탈취, 변조될 위험이 있고, Request/Response에서 스나이핑 당할 위험이 있어 보안이 비교적 취약하다. 반대로 Session은 클라이언트 정보 자체는 서버에 저장되어 있으므로 비교적 안전하다.
  • 라이프 사이클
    • 쿠키는 앞서 설명한 지속 쿠키의 경우에 브라우저를 종료하더라도 저장되어 있을 수 있는 반면에 세션은 서버에서 만료시간/날짜를 정해서 지워버릴 수 있기도 하고 세션 쿠키에 세션 아이디를 정한 경우, 브라우저 종료시 세션아이디가 날아갈 수 있다.
  • 속도
    • 쿠키에 정보가 있기 때문에 쿠키에 정보가 있기 때문에 서버에 요청시 헤더를 바로 참조하면 되므로 속도에서 유리하지만, 세션은 제공받은 세션아이디(Key)를 이용해서 서버에서 다시 데이터를 참조해야하므로 속도가 비교적 느릴 수 있다.

 

 

 

세션을 주로 사용하면 좋은데 왜 굳이 쿠키를 사용할까?

→ 세션은 서버에 데이터를 저장 즉, 서버의 자원을 사용하기 때문에 서버 자원에 한계가 있고 메모리를 사용하다보면 속도 저하도 올 수 있기 때문이다.


세션은 사용자의 수 만큼 서버 메모리를 차지하기 때문에
최근에는 이런 문제들을 보완한 토큰 기반의 인증방식을 사용하는 추세다. 그 중 JWT( JSON Web Token)라는 것이 있다. JWT는 다음에 포스팅해보도록 하겠다.

 

 

 

 

참고:

더보기

 

'Web' 카테고리의 다른 글

[Web] JWT란?  (0) 2021.07.31
[Web] REST API  (0) 2021.07.03

+ Recent posts