Cookie, Session, Token 의 차이점

Cookie, Session, Token 의 차이점

• Cookie, Session, Token 의 차이점
  • 계정 정보를 요청 Header 에 넣는 방식
  • Session / Cookie 방식
    • 인증 절차
    • Session 과 Cookie 의 차이점
    • 장단점
  • Token 기반 인증 방식
    • JWT Token
    • 인증절차
    • 장단점

출처 : tanfil.tistory, Dev.to

계정 정보를 요청 Header 에 넣는 방식

절대 이렇게 하면 안됩니다. 보통 앱에서는 서버로 HTTP 요청을 할 때 따로 암호화 되지 않으므로, 해커가 HTTP 요청을 가로채서(intercept) 사용자의 계정정보를 알 수 있습니다.

Session / Cookie 방식

Session/Cookie 방식 인증은 기본적으로 세션 저장소를 필요로 합니다. 세션 저장소는 로그인시 사용자 정보를 저장하고, 열쇠로 사용할 수 있는 세션 ID 를 만듭니다. 그리고 HTTP 헤더에 실어 클라이언트에게 보냅니다. 브라우저는 세션 ID 를 포함하는 쿠키를 저장하고있습니다. 인증이 필요한 요청에 해당 쿠키를 끼워 서버에 request 를 보냅니다.

인증 절차

1. 사용자가 로그인을 합니다.
2. 서버에서는 계정 정보를 읽어 사용자를 확인 후, 사용자의 고유 ID 값을 부여한 후 세션 저장소에 저장하고, 이와 연결되는 세션 ID 를 발행합니다.
3. 클라이언트는 서버에서 해당 세션 ID 를 받아 쿠키에 저장 한 후, 인증이 필요한 요청마다 쿠키를 헤더에 끼워 보냅니다.
4. 서버에서는 쿠키를 받아 세션 저장소에서 확인 한 후, 일치하는 정보를 가져옵니다.
5. 인증이 완료되고 서버는 사용자에 맞는 데이터를 보내줍니다.

Session 과 Cookie 의 차이점

• Session
  • 서버에서 가지고있는 정보
• Cookie
  • 서버에서 발급된 세션을 열기 위한 키 값(세션 ID 라고 칭함)

쿠키만으로 인증을 한다는 것은서버의 자원은 사용하지 않는다는 것 - 클라이언트가 인증 정보를 책임지는 것을 의미합니다.

쿠키만으로 인증을 할 경우, 해커가 HTTP 요청을 중간에서 뺏어갈 때, 모든 정보가 탈취됩니다.
또한 쿠키는 조작된 데이터일 수 있으므로 실제 정보가 존재하는 database 를 사용해서 작업합니다.
따라서 보안과는 관련 없는 장바구니, 자동로그인 설정 같은 경우에 유용하게 사용됩니다.

인증의 책임을 서버가 지게 하기 위해서 세션을 함께 사용합니다. 사용자는 쿠키를 이용하고, 서버에서는 쿠키를 받아 세션의 정보를 접근하는 방식으로 인증을 합니다.

장단점

장점

1. 쿠키가 담긴 HTTP 요청이 도중에 노출되더라도 쿠키 자체(세션 ID) 는 유의미한 값을 갖고 있지 않습니다. 중요한 정보는 서버 세션에 존재합니다.
2. 고유의 ID 값을 발급받습니다.

   쿠키 값을 받았을 때 일일이 회원정보를 확인할 필요 없이 바로 어떤 회원인지를 확인할 수 있어 서버의 자원에 접근하기 용이합니다.

단점

1. 세션 하이재킹 공격이 가능할 수 있다.

   해결책은 HTTPS 를 사용해 요청 자체를 탈취해도 안의 정보를 읽기 힘들게 하거나, 세션에 유효시간을 부여할 수 있습니다.

2. 서버에서 추가적인 저장공간이 필요합니다.

   서버에서 세션 저장소를 사용하므로 부하가 높아집니다.

Token 기반 인증 방식

JWT (JSON Web Token) 는 인증에 필요한 정보들을 암호화시킨 토큰을 의미합니다. 위의 세션/쿠키 방식과 유사하게 사용자는 Access Token (JWT Token) 을 HTTP 헤더에 실어 서버에 전송합니다. 토큰은 임의로 생성된 비밀번호 같이 동작합니다. 제한된 수명을 가지고, 새로운 토큰은 한번 만료되면 새로 생성되어야합니다.(Refresh Token)

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

JWT Token

1. Header :: Header, Payload, Verify Signature 를 암호화할 방식(alg), 타입(Type) 등을 포함합니다.
2. Payload :: 서버에서 보낼 데이터 - 일반적으로 user의 id, 유효기간 포함
3. Verify Signature :: Base64 방식으로 인코딩한 Header, Payload, Secret key 를 더한 후 서명됩니다.

결과 :: Encoded Header + "." + Encoded Payload + "." + Verify Signature

Header, Payload 는 암호화 되지 않으므로, 디코딩하여 확인할 수 있습니다. 그러므로 Payload 에 유저의 중요한 정보(비밀번호 등) 가 들어가면 쉽게 노출될 수 있습니다.

인증절차

1. 사용자가 로그인을 합니다.
2. 서버에서는 계정 정보를 읽어 사용자를 확인 후, 사용자의 고유 ID 값을 부여한 후 기타 정보와 함께 Payload 에 집어넣습니다.
3. JWT 토큰의 유효기간을 설정합니다.
4. 암호화할 Secret key 를 이용해 Access Token 을 발급합니다.
5. 사용자는 Access Token 을 받아 저장 후, 인증이 필요한 요청마다 토큰을 헤더에 실어 보냅니다.
6. 서버에서는 해당 토큰의 Verify Signature 를 Secret key 로 복호화한 후, 조작 여부, 유효기간을 확인합니다.
7. 검증이 완료되었을 경우, Payload 를 디코딩 하여 사용자의 ID 에 맞는 데이터를 가져옵니다.

세션 / 쿠키 방식과 가장 큰 차이점은 세션 / 쿠키는 세션 저장소에 유저 정보를 넣는 반면, JWT 는 토큰 안에 유저의 정보들이 넣어진다는 점 입니다. 클라이언트 입장에서는 HTTP 헤더에 세션 ID 나 토큰을 실어서 보내준다는 점에선 동일하지만, 서버 측에서는 인증을 위해 암호화를 한다 vs 별도의 저장소를 이용한다 의 차이가 발생합니다.

장단점

장점

1. 간편합니다.

   세션/쿠키 인증은 별도의 저장소 관리가 필요합니다.
   JWT 는 발급한 후 검증만 하기 때문에 추가 저장소가 필요하지 않습니다. (StateLess - 상태/정보 저장하지 않음) 이는 서버를 확장하거나 유지, 보수하는데 유리합니다.

2. 확장성이 뛰어납니다.

   토큰 기반으로 하는 다른 인증 시스템에 접근이 가능합니다.
   Facebook, Google, Microsoft 로그인 등은 모두 토큰 기반으로 인증을 하는데, 권한을 받을 수도, 프로필을 써드파티 웹사이트에 제공하도록 허가 할 수도 있습니다.

단점

1. 이미 발급된 JWT 에 대해서는 유효기간이 완료될 때 까지는 계속 사용이 가능합니다.

   세션/쿠키 인증 방식은 쿠키가 악의적으로 이용될 경우 쿠키를 삭제하면 됩니다.
   그러나 JWT 는 유효기간이 지나기 전까지 정보들을 이용할 수 있습니다.
   이에 대한 해결책은, Access Token 유효기간을 짧게 하고 Refresh Token 이라는 새로운 토큰을 발급합니다. 그렇게 되면 Access Token 을 탈취당해도 상대적으로 피해를 줄일 수 있습니다.

2. Payload 정보가 제한적입니다.

   Payload 는 따로 암호화되지 않기 때문에 디코딩하면 누구나 정보를 확인할 수 있습니다. 따라서 유저의 중요한 정보들은 Payload 에 넣을 수 없습니다.

3. JWT 의 길이

   JWT 의 길이는 길기 때문에 인증이 필요한 요청이 많아질수록 서버의 자원낭비가 발생합니다.