JWT vs Session

🔐 인증 vs 인가

두 단어에 차이가 있을까? 싶었지만 얄코 강의를 들으며 차이가 있다는 걸 알았다. jwt와 세션에 대해 정리해보기 전, 이 단어들 부터 정리해보겠다.

- 인증(Authentication)

: 쉽게 말해서 로그인이라고 생각하면 된다.
내가 이 사이트에 가입된 회원임을(= 즉 특정 서비스에 일정 권한이 주어진 사용자임을) 아이디랑 패스워드 등으로 인증하는 것

- 인가(Authorization)

: 한번 인증을 받은 사용자가 이후 서비스의 여러 기능들을 사용할 때 (= 로그인이 유지되는 상태에서 일어나는 일)
예를들어, 내가 페이스북에 로그인으로 인증을하고 나서 '내' 친구들의 목록을 보거나 '내 계정으로' 좋아요를 누르는 행위를 할 때 페이스북이 내가 로그인 되어있음을 알아보고 허가를 해주는 것.

이제 인증을 처리하는 방식들에 대해 정리해보겠다.

---

🔐 서버 기반 인증 시스템(Session / Cookie)

서버 기반 인증 시스템은 로그인 시 세션 ID 절반을 클라이언트에게 발급해주고 나머지 절반은 자신이 갖고 있는다. 그러면 클라이언트는 요청 시마다 세션 ID가 담긴 쿠키를 헤더에 담아 보내면 서버에선 값을 비교하여 인증을 처리한다. 상태를 유지해야 하므로 Stateful 한 구조를 가지고 있다.

- 인증 방식

1. 사용자가 로그인 시 올바른 사용자임을 확인하고, 고유한 세션 ID 값을 부여하여 세션 저장소에 저장하고 클라이언트에게 발급해준다.
2. 클라이언트는 세션 ID를 받아 쿠키에 저장하고, 인증이 필요한 요청마다 쿠키에 세션 ID를 담아 헤더에 실어 보낸다.
3. 서버에서는 쿠키를 받아 세션 저장소와 비교해 올바른 요청인지 확인한다.
4. 인증이 완료되고 서버는 요청에 응답한다.

- 장점

1. 서버에서 클라이언트의 상태를 유지하고 있으므로, 사용자의 로그인 여부 확인이 용이하고, 경우에 따라 강제 로그아웃 등 상태 변경이 가능하다.
2. 클라이언트가 임의로 정보를 변경시키더라도 서버에서 클라이언트의 상태 정보를 가지고 있으므로 상대적으로 안전하다.

- 단점

1. 서버에서 클라이언트의 상태를 모두 유지하고 있어야 하므로, 클라이언트 수에 따른 메모리나 DB에 부하가 심하다.
2. 사용자가 많아지는 경우 로드 밸런싱을 사용한 서버 확장을 이용해야 하는 데 이 때 세션의 관리가 어려워진다.

---

🔐 토큰 기반 인증 시스템(JWT)

토큰 기반 인증 시스템은 로그인 시 토큰을 발급해주고, 서버에 요청을 할 때 HTTP 헤더에 토큰을 함께 보내도록 하여 유효성 검사를 하는 방식이다.
사용자의 인증 정보를 더 이상 서버에 저장하지 않고 클라이언트의 요청으로만 인가를 처리할 수 있으므로 Stateless 한 구조를 가진다.

JWT는 Json Web Token의 약자로 인증에 필요한 정보를 암호화시킨 토큰을 뜻한다.

- jwt 토큰 형태

jwt.io에서 가져온 예시)

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

• 인코딩 또는 암호화된 3가지 데이터를 이어붙인 것
• xxxxxx.yyyyyy.zzzzzz 형태
• 마침표로 끊어져서 세 부분으로 나뉨
• 각각 header, payload, verify signature로 구분됨

위 단어들을 하나씩 살펴보겠다 🧐

✏️ payload

Base64로 디코딩해보면 JSON형식으로 여러 정보들이 들어있다.
이 토큰을 누가 누구에게 발급했는지, 이 토큰이 언제까지 유효한지, 그리고 서비스가 사용자에게 이 토큰을 통해 공개하기 원하는 내용이 담겨 있다.
ex) 사용자의 닉네임, 서비스상의 레벨, 관리자 여부 등
➡️ 이렇게 토큰에 담긴 사용자 정보 등의 데이터를 Claim이라고 함

✏️ header

디코딩해보면 두가지 정보가 담겨있음.
1) type: 토큰의 타입인데 언제나 JWT가 들어감
2) alg: 알고리즘의 약자, verify signature(서명)값을 만드는데 사용될 알고리즘이 지정됨. HS256 등 여러 암호화 방식 중 하나를 지정.

헤더 + 페이로드 + 서버에 감춰놓은 비밀 값 이 셋을 위 암호화 알고리즘에 넣고 돌리면 verify signature 값이 나오는 것이다.

- 인증 방식

1. 사용자가 로그인 시 올바른 사용자임을 확인하고, 클라이언트에게 Access Token(JWT)을 발급해준다
2. 클라이언트는 전달받은 토큰을 저장해두고, 인증이 필요한 요청마다 토큰을 HTTP 헤더에 담아 보낸다.
3. 서버에서는 암호화된 토큰을 복호화 해 올바른 요청인지 확인한다.
4. 인증이 완료되고 서버는 요청에 응답한다.

- 장점

1. Header와 Payload를 가지고 Signature를 생성하므로 데이터 위변조를 막을 수 있다.
2. 인증 정보에 대한 별도의 저장소가 필요없다.
3. JWT는 토큰에 대한 기본 정보와 전달할 정보 및 토큰이 검증되었음을 증명하는 서명 등 필요한 모든 정보를 자체적으로 지니고 있다.
4. 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능하다.
5. OAuth의 경우 Facebook, Google 등 소셜 계정을 이용하여 다른 웹서비스에서도 로그인을 할 수 있다.

- 단점

1. 쿠키/세션과 다르게 JWT는 토큰의 길이가 길어, 인증 요청이 많아질수록 네트워크 부하가 심해진다.
2. Payload 자체는 암호화되지 않기 때문에 유저의 중요한 정보는 담을 수 없다.
3. 특정 사용자의 접속을 강제로 만료하기 어렵다.

- 보완

1. 짧은 만료 기한 설정

2. Sliding Session
   : Sliding Session은 서비스를 지속적으로 이용하는 클라이언트에게 자동으로 토큰 만료 기한을 늘려주는 방법이다. 글 작성 혹은 결제 등을 시작할 때 새로운 토큰을 발급해줄 수 있다. 이를 통해 사용자는 로그인을 자주 할 필요가 없어진다.

3. Refresh Token
   refresh token에 대해선 다른 블로그 포스팅에서 자세히 정리해두었다.
   https://velog.io/@yulhee741/Refresh-Token-%EC%A0%95%EB%A6%AC

---

참고)

• 얄팍한 코딩사전
• https://millo-l.github.io/Session-%EA%B8%B0%EB%B0%98-%EC%9D%B8%EC%A6%9D%EB%B0%A9%EC%8B%9D/
• https://node-js.tistory.com/entry/JWT-%EC%84%9C%EB%B2%84-%EC%9D%B8%EC%A6%9D-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-JWT%EB%9E%80-%EC%84%9C%EB%B2%84-%EC%9D%B8%EC%A6%9D-%ED%86%A0%ED%81%B0-%EC%9D%B8%EC%A6%9D
• https://tecoble.techcourse.co.kr/post/2021-05-22-cookie-session-jwt/