인증 방식 - 쿠키/세션 방식 & JWT

 

 

저번 프로젝트에서 로그인을 구현할 때 토큰 방식을 사용했고, 이번 프로젝트에서는 쿠키를 사용하게 되었다.

이 두 방식의 특성과 차이점이 궁금해져 찾아보고 정리해보았다.

 

 

인증

 

Authentication(인증)은 웹에서 중요한 절차이다. 어떤 사용자가 서비스를 사용하는지 추적이 을 하는 등 개인정보를 다루는 과정이 포함되어 있어서 타인의 정보를 보호하기 위해 필수적인 파트이다.

브라우저에서는 자신이 누구인지를 증명할  수 있는 정보를 서버에 보내야하며, 서버는 그 단서를 바탕으로 사용자에게 맞는 데이터를 보내주어야 한다.

 

 

 

 

 

HTTP의 비연결성 및 무상태성

 

HTTP는 인터넷 상에서 데이터를 주고 받기 위한 서버/클라이언트 모델을 따르는 프로토콜이다.

클라이언트가 서버에게 요청을 보내면 서버는 응답을 보냄으로써, 데이터를 교환한다.

HTTP는 비연결성 및 무상태성 이라는 특징을 가지고 있다.

HTTP는 요청에 대한 응답을 처리하게 되면 연결을 끊어 버린다. 따라서 클라이언트에 대한 이전의 상태 정보 및 현재 통신의 상태가 남아있지 않는다.

비연결성 및 무상태성의 특징을 가진다면 불필요한 자원 낭비를 줄일 수 있다는 장점이 있지만, 서버는 클라이언트를 식별할 수 없다는 단점이 존재한다.

이러한 HTTP의 비연결성 및 무상태성 특징을 Cookie와 Session이 보완한다.

 

 

 

-Session/Cookie 방식

 

Session/Cookie 방식 인증은 기본적으로 세션 저장소를 필요로 한다. 세션 저장소는 로그인시 사용자 정보를 저장하고, 열쇠로 사용할 수 있는 세션 ID를 만든다. 그리고 HTTP헤더에 실어 클라이언트에게 보낸다.

브라우저는 세션 ID를 포함하는 쿠키를 저장하고 있다. 인증이 필요한 요청에 해당 쿠키를 끼워 서버에 request를 보낸다.

인증의 책임을 서버가 지게 하기 위해서 세션을 함께 사용한다.

사용자는 쿠키를 이용하고, 서버에서는 쿠키를 받아 세션의 정보를 접근하는 방식으로 인증을 한다.

 

Session: 서버에서 가지고 있는 정보

Cookie: 서버에서 발급된 세션을 열기 위한 키 값(세션 ID 라고 칭함)

 

 

인증 절차

 

1. 사용자가 로그인을 함

2. 서버에서는 계정 정보를 읽어 사용자를 확인 후, 사용자의 고유 ID 값을 부여한 후 세션 저장소에 저장하고, 이와 연결되는 세션 ID를 발행

3. 클라이언트는 서버에서 해당 세션 ID를 받아 쿠키에 저장한 후, 인증이 필요한 요청마다 쿠키를 헤더에 끼워 보냄

4. 서버에서는 쿠키를 받아 세션 저장소에서 확인 후, 일치하는 정보를 가져옴

5. 인증이 완료되고 서버는 사용자에 맞는 데이터를 보내줌

 

 

 

 

 

장단점

 

• 각 사용자마다 고유한 세션 ID가 발급되기 때문에, 요청이 들어올 때마다 회원정보를 확인할 필요가 없다.
• 쿠키가 담긴 HTTP 요청이 도중에 노출되더라도 쿠키 자체(세션 ID) 는 유의미한 값을 갖고 있지 않다. 중요한 정보는 서버 세션에 존재한다.
• 그러나 해커가 이를 중간에 탈취하여 클라이언트인척 위장할 수 있다는 한계가 존재한다.
• 서버에서 세션 저장소를 사용하므로 부하가 심해진다.

 

 

-Token 기반 인증 방식

 

JWT (JSON Web Token) 는 인증에 필요한 정보들을 암호화시킨 토큰을 의미한다. 위의 세션/쿠키 방식과 유사하게 사용자는 Access Token (JWT Token) 을 HTTP 헤더에 실어 서버에 전송한다.

토큰은 임의로 생성된 비밀번호 같이 동작한다. 제한된 수명을 가지고, 새로운 토큰은 한번 만료되면 새로 생성되어야한다.(Refresh Token)

일반적으로 JWT 뿐 아니라 openID Connect 프로토콜도 사용할 수도 있다.

 

 

JWT 구조

 

 

Encoded Header + "." + Encoded Payload + "." + Verify Signature

JWT는 .을 구분자로 나누어지는 세 가지 문자열의 조합이다. 실제 디코딩된 JWT는 다음과 같은 구조를 지닌다.

 

 

Header 

 

Header, Payload, Verify Signature 를 암호화할 방식(alg), 타입(Type) 등을 포함

 

Payload 

 

 서버에서 보낼 데이터 - 일반적으로 user의 id, 유효기간 포함

 

 

Verify Signature

 

인코딩된 Header와 Payload를 더한 뒤 비밀키로 해싱하여 생성. Header와 Payload는 단순히 인코딩된 값이기 때문에 제 3자가 복호화 및 조작할 수 있지만, Signature는 서버 측에서 관리하는 비밀키가 유출되지 않는 이상 복호화할 수 없다. 따라서 Signature는 토큰의 위변조 여부를 확인하는데 사용된다.

 

 

 

인증 절차

 

1. 사용자가 로그인을 한다.

2. 서버에서는 계정 정보를 읽어 사용자를 확인 후, 사용자의 고유 ID 값을 부여한 후 기타 정보와 함께 Payload에 집어넣는다.

3. JWT 토큰의 유효기간을 설정한다.

4. 암호화할 Secret key를 이용해 Access Token을 발급한다.

5. 서버에서는 해당 토큰의 Verify Signature를 Secret key로 복호화한 후, 조작 여부, 유효기간을 확인한다.

6. 검증이 완료되었을 경우, Payload를 디코딩하여 사용자의 ID에 맞는 데이터를 가져온다. 

 

 

 

장단점

 

• JWT 는 발급한 후 검증만 하기 때문에 추가 저장소가 필요하지 않다. (StateLess - 상태/정보 저장하지 않음) 이는 서버를 확장하거나 유지, 보수하는데 유리하다.
• 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능해 확장성이 뛰어나다.(Facebook, Google, Microsoft 토큰기반 인증)
• 이미 발급된 JWT 에 대해서는 유효기간이 완료될 때 까지는 계속 사용이 가능하다.
  -> 해결책으로 Access Token 유효기간을 짧게 하고 Refresh Token이라는 새로운 토큰을 발급한다.
• Payload는 따로 암호화되지 않기 때문에 디코딩하면 누구나 정보를 확인할 수 있다. 따라서 중요한 정보들은 넣을 수 없어 Payload 정보가 제한적이다.
• JWT는 토큰의 길이가 길어, 인증 요청이 많아질수록 네트워크 부하가 심해진다.

 

 

 

정리

 

 

 

=>두 방법의 차이점은 세션 / 쿠키는 세션 저장소에 유저 정보를 넣는 반면, JWT 는 토큰 안에 유저의 정보들이 넣어진다는 점이다.

클라이언트 입장에서는 HTTP 헤더에 세션 ID 나 토큰을 실어서 보내준다는 점에선 동일하지만, 서버 측에서는 인증을 위해 암호화를 한다 vs 별도의 저장소를 이용한다 의 차이가 발생한다.

 

 

 

https://doing7.tistory.com/87

https://tofusand-dev.tistory.com/89

https://tecoble.techcourse.co.kr/post/2021-05-22-cookie-session-jwt/

https://velog.io/@denmark-choco/Web-Authentication%EC%9D%B8%EC%A6%9D