쿠키/세션 방식
1. 인증 방식 순서
-
사용자가 로그인한다.
-
서버에서는 계정 정보를 읽어 사용자를 확인한 후, 사용자의 고유한 ID 값을 부여하여 세션 저장소에 저장하고, 이와 연결되는 세션 ID를 발행한다.
-
사용자는 서버에서 해당 ID를 받아 쿠키에 저장을 한 후, 인증이 필요한 요청마다 쿠키를 헤더에 실어 보낸다.
-
서버에서는 쿠키를 받아 세션 저장소에서 대조를 한 후 대응되는 정보를 가져온다.
-
인증이 완료되고 서버는 사용자에 맞는 데이터를 보내준다.
2. 장점
- 쿠키/세션 방식은 기본적으로
쿠키를 매개로 인증을 거친다.쿠키는 HTTP 요청 중 노출이 되더라도 쿠키 자체는 유의미한 값을 가지고 있지 않기 때문에 안전하다.
3. 단점
-
만약 HTTP 요청을 해커가 가로챈다면 그 안에 있는 쿠키를 가로채서 HTTP 요청을 보낼 수 있다. -> 세션 하이재킹 공격
-
세션 저장소로 인해 서버에 추가적인 저장 공간을 필요로 하게된다. -> 서버 부하 상승
JWT 방식
인증에 필요한 정보들을 암호화시킨 토큰이다. Access Token을 HTTP 헤더에 실어 서버로 보내게 된다.
1. JWT 구성요소
- Header : Signature를 해싱하기 위한 알고리즘 정보들이 담겨있다.
- Payload : 서버와 클라이언트가 주고받는, 시스템에서 실제로 사용될 정보에 대한 내용들을 담고 있다.
- Signature : 토큰의 유효성 검증을 위한 문자열 -> 이 문자열을 통해 서버에서는 이 토큰이 유효한 토큰인지를 검증할 수 있다.
2. 장점
-
간편하다. 쿠키/세션 방식은 별도의 저장소의 관리가 필요하다. 하지만 JWT는 발급한 후 검증만 하면 되기 때문에 추가 저장소가 필요없다.
-
확장성이 뛰어나다. 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능하다. 예를 들어 Facebook 로그인, Google 로그인 등은 모두 토큰을 기반으로 인증을 한다.
3. 단점
-
이미 발급된 JWT에 대해서는 돌이킬 수 없다. 쿠키/세션의 경우 쿠키가 악의적으로 사용될 경우, 해당되는 세션을 지워버리면 된다. 하지만 JWT는 한 번 발급되면 유효기간이 완료될 때까지 게속 사용이 가능하다. -> 기존의 Access Token의 유효기간을 짧게하고 Refresh Token이라는 새로운 토큰을 발급한다. 그렇게 되면 Access Token을 탈취당해도 상대적으로 피해를 줄일 수 있다.
-
payload 정보가 제한적이다. payload는 따로 암호화되지 않기 때문에 유저의 중요한 정보들을 payload에 넣을 수 없다.
-
JWT의 길이가 길다. 따라서 인증이 필요한 요청이 많아질수록 서버의 자원낭비가 발생하게 된다.
