이번 글에서는 인가 과정에서 사용되는
Session
과JWT
의 개념 및 각각의 장단점에 대해 알아보려고 합니다.
먼저 인증/인가에 대해 알고 가면 좋을 것 같아 정리해 두었습니다.
인증(Authentication)
사용자가 서비스를 사용할 수 있는지 인증하는 절차입니다.
인증 = 로그인
이라고 생각하면 될 것 같습니다.
인가 (Authorization)
인증된 사용자가 기능을 사용할 수 있는지 확인하는 절차입니다.
보통의 서비스는 로그인을 한 이후에 다양한 기능을 사용할 수 있습니다.
대부분의 웹사이트는 HTTP 프로토콜을 사용하는데 확장성을 위해 무상태, 비연결성을 유지합니다.
그래서 서버에 요청을 보낼 때 마다 본인이 인증된 사용자라는 것을 증명해야 합니다.
하지만 사용자가 매번 기능을 이용할 때 마다 로그인 하는 건 번거롭고, 위험하기 때문에
인증된 사용자인지 서버가 인지할 수 있도록 도와주는 기술이 Session
과 JWT
입니다.
Session은 서버가 클라이언트의 상태 정보를 유지하기 위해 사용되는 기술입니다.
Session id
를 쿠키에 담아 클라이언트에게 반환Session id
전달해서 Session
유효 기간 동안 상태 유지Session id
만 담아서 보내기 때문에 트래픽을 적게 사용JWT는 사용자 정보를 담은 암호화 된 토큰(문자열)으로 인증을 위해 사용되는 기술입니다. 토큰은 Base64Url
로 인코딩 되어있습니다.
JWT는 Header
, Payload
, Signature
형식으로 이루어져 있습니다.
Header
는 토큰 유형(JWT 고정), Signature
를 만들기 위한 암호화 알고리즘으로 구성됩니다.
{
"alg": "HS256",
"typ": "JWT"
}
Payload
는 Claim
(토큰에 저장된 정보)이 존재합니다. 클레임에는 세 가지 유형이 있습니다.
등록된 클레임: 토큰 정보를 표현하는데 기본적으로 정의된 클레임 집합입니다.
공개 클레임: 정보를 공개하기 위한 사용자 정의 클레임입니다.
비공개 클레임: 주로 클라이언트-서버가 정보를 주고 받을 때 사용하는 사용자 정의 클레임입니다.
BASE64Url로 디코딩해서 조작할 수 있기 때문에 Header
와 Signature
가 필요합니다.
Signature
는 인코딩 된 Header, Payload와 서버에 저장된 비밀키, Header에 지정된 알고리즘을 사용해서 만들어 집니다.
HTTP Header
Authorization: Bearer <token>
Session | JWT |
---|---|
보안이 중요한 경우 | 속도 및 확장성이 중요한 경우 |
저는 그동안 프로젝트를 진행하며 인가 과정에서 매번 JWT
를 사용해왔습니다.
개인적으로 Session
보다 JWT
를 많이 사용하는 이유가 궁금하기도 하고, 각각의 차이가 궁금해서 이번 포스팅을 작성하게 되었습니다.
그리고 프로젝트를 진행하면서, 기존에 구현해 본 기능이나 익숙한 기능을 다시 만드는 것보다 익숙하지 않은 것을 시도해 보는 것의 중요성을 느끼고 있습니다.
이를 통해 각 기술의 장단점을 파악하거나 익숙한 기능을 사용 하더라도 구현 방법에 대해 다시 고민하고, 더 발전시키는 것이 중요한 것 같습니다!
https://www.youtube.com/watch?v=1QiOXWEbqYQ&t=352s
https://jwt.io/introduction