session 방식
Session은 일정 시간 동안 같은 사용자로부터 들어오는 요구를 하나의 상태로 보고 그 상태를 일정하게 유지시키는 기술이다.
여기서 일정 시간이란 방문자가 웹 브라우저를 통해 웹 서버에 접속한 시점부터 웹 브라우저를 종료함으로써 연결을 끝내는 시점을 말한다
💡 즉, 유저가 웹 서버에 접속해 있는 상태를 하나의 단위로 보고 세션이라고 말한다.세션과 쿠키를 이용한 인증 방식
기존에 주로 사용하는 서버 기반의 인증 방식으로 서버 측에서 사용자들의 정보를 기억하고 있어야 한다.
사용자들의 정보를 기억하기 위해서는 세션을 유지해야 하는데 메모리나 디스크 또는 데이터베이스 등을 통해 관리한다.
서버 기반의 인증 시스템은 client로 부터 요청을 받으면 client의 상태를 계속해서 유지하고 이 정보를 서비스에 이용하는데 이러한 서버를 stateful한 서버라고 한다.
예를 들어, 사용자가 로그인을 하면 세션에 정보를 저장해두고 서비스를 제공할 때 사용하게 된다.
인증 절차
- 사용자가 로그인을 한다.
- 서버에서 계정 정보를 통해 사용자를 확인한다. 그리고 고유한 ID값을 부여하여 세션 저장소에서 저장한 뒤 세션 ID를 발행한다
- 사용자는 서버에서 해당 세션ID를 받아 쿠키에 저장한 후, 인증이 필요한 요청마다 쿠키를 header에 담아서 보낸다
- 서버에서는 쿠키를 받아 세션 저장소에서 대조를 한 후 대응되는 정보를 가져온다.
- 인증이 완료되면 서버는 사용자에 맞는 데이터를 보내준다.
장점
-
사용자의 정보는 세션 저장소에 저장되고 , 쿠키는 그 저장소를 통과할 수 있는 츨입증 역할을 한다. 따라서 쿠키가 담긴 HTTP요청이 도중에 노출되더라도 쿠키 자체에는 유의미한 값을 갖고 있지 않아서 쿠키에 사용자 정보를 담아 인증을 거치는 것 보다 안전하다.
-
각각의 사용자는 고유의 세션 ID를 발급받기 때문에 일일이 회원 정보를 확인할 필요가 없어서 서버 자원에 접근하기 용이하다.
→ 하지만, 만약 해커가 사용자 A의 HTTP 요청을 훔처서 그 쿠키를 이용해 HTTP요청을 하게 된다면 서버의 세션 저장소에서 사용자 A로 오인해서 정보를 잘못 가져올 수 있다. 이를 세션 하이재킹 공격이라고 한다.
단점
1 .별도의 저장소의 관리가 필요하고 세션이 연결되어 있기 때문에 stateless한 서버를 만들 수 없다.
- 사용자가 늘어나가 되면 더 많은 트래픽을 처리하기 위해 여러 프로세스를 돌리거나 컴퓨터를 추가하는 등 서버를 확장해야 한다. 세션을 사용한다면 세션을 분산시키는 시스템을 설계해야 하지만 이러한 과정은 매우 어렵고 복잡하며 자연스럽게 서버의 부하가 높아지게 된다.
- CROS방식을 사용할 때 여러 도메인에서의 쿠키 및 세션 관리가 어렵다.
- 멀티 디바이스 환경에서 로그인시 중복 로그인 처리가 되지 않는 등의 신경 써주어야 할 부분들이 생긴다.
JWT 방식
회원이 서버에 보내는 정보가 더 많다.
이름 / 발급일 / 이메일 / 유효기간 등등…
서버는 받은 정보만 가지고 판단을 한다. → 받은 정보에 이상이 없으면 회원을 통과 시킨다.
jwt 방식은 보내는 정보를 기본 세팅 값 / 보내는 정보 / 시크릿키등등을 합쳐서 base64형식으로 인코딩해서 보낸다.
JWT
JWT는 JSON Web Token의 약자로 인증에 필요한 정보들을 암호화 시킨 토큰을 말하며 Access Token으로 사용된다.
JWT를 생성하기 위해서는 Header, Payload, Verify Signature 객체를 필요로 한다.
Header
Header는 토큰의 타입을 나타내는 typ과 암호화 할 방식을 정하는 alg 로 구성되어 있다.
Payload
Payload는 토큰에 담을 정보를 포함한다. 여기서 하나의 정보 조각을 클레임으로 부른다.
클레임의 종류로는 Registered, Public, Private 로 3가지가 존재한다. 보통 만료일시, 발급일시, 발급자, 권한 정보등을 포함한다.
Verify Signature
Verify Signature는 Payload가 위변조되지 않았다는 사실을 증명하는 문자열이다. base64방식으로 인코딩한 Header, payload 그리고 secret key를 더한후 서명된다.
이 정보들은 base64 방식으로 인코딩 될 뿐, 따로 암호화 되지 않는다.
따라서 Header, payload는 누구나 디코딩하여 확인 할 수 있기에 정보가 쉽게 노출될 수 있다.
하지만 Verufy Signature는 Secret key를 알지 못하면 복호화 할 수 없다.
JWT 인증 동작 과정
- 사용자 로그인
- 서버에서 사용자 확인 후 Payload에 고유한 ID값을 넣는다
- JWT 토큰의 유효기간을 설정한다
- secret key를 통해 암호화된 Access Token을 Http응답 헤더에 실어 보낸다
- 사용자는 Access Token을 받아 저장한 후, 인증이 필요한 요청마다 토큰을 Http요청 헤더에 실어 보낸다
- 서버에서는 해당 토큰의 Verify Signature를 secret key로 복호화한 후, 조작 여부, 유효기간을 확인한다.
- 검증이 완료된다면 payload를 디코딩하여 사용자 ID에 맞는 데이터를 가져온다
장점
-
Stateless
받는 정보만 처리하면 되기 때문에 처리 속도가 빠르다.
-
jwt의 인코딩 방식은 기존의 정보가 변경되거나 시크릿키 등이 바뀌면 base64의 정보도 바뀌기 때문에 다른 상대가 위조를 시도하면 빠르게 알 수 있다.
-
확장성이 뛰어나다. 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능하다.
단점
- alg(알고리즘)부분을 none으로 설정하면 보안상의 문제가 생길 수 있다.
- 변환이 쉽다.
- 민감한 정보를 넣게되면 유출되기 쉽다
- 시크릿키를 대충 적게 되면 보안상의 문제가 생기기 쉽다.
- 키를 길게 적는다
- 생성용키 / 검증용키 2개를 사용한다
- jwt를 탈취당하게 되면 회원의 정보가 유출되기 쉽다
-
탈취당했을때 사용 정지를하거나 제제를 하기 어렵다
→ HttpOnly cookie
→ 블랙리스트를 관리하는 장치를 따로 만든다(session과 별 차이없음)
→ 유효기간을 짧게 설정한다
: refresh토큰을 새로 만들어 주어야한다
-
결론
대부분의 어플리케이션은 session방식으로 일일이 검증하는 것이 더 안전하다.
하지만, 회원수가 너무 많은 서비스의 경우 데이터를 전부 검증해야 하기 때문에 속도가 느릴수 있다. →이때 jwt를 고려하거나 OAuth같은 다른 인증방식을 고려할 수 있다.
