로그인
모든 로그인 과정을 간단하게 보면, 이렇다고 생각한다.
여기서 살펴볼 jwt나 cookies&session은 모두 체크과정에 해당된다.
얼마나 효율적으로 로그인 하는지 살펴보자!
Cookies & Session과 Jwt
http
저 과정에서 볼 수 있는 "저 아시죠?"와 "알지 or 몰라"처럼 대화할 수 있게 해주는 것이 http이다.
대화의 장이 http라고 생각하면 될 것 같다.
Cookies & Session
세션과 쿠키를 따로따로 설명하려 했지만 이 둘은 같이 설명하는 게 좋을 것 같다.
session 로그인 방식이 사용되게 된 이유를 살펴보면,
HTTP Header를 통해 데이터를 전송할 때에 일어나는 취약점과 Cookie와 Session을 사용하지 않고 로그인할 때에 비효율 때문에 나오게 되었다.
전체적인 session login의 흐름을 보자.
(여기에 그림 추가)
1. client가 로그인을 했을 때, 회원정보를 session이라는 형태로 저장한다. 2. client에게 session의 id를 전송해준다. 3. client는 받은 session id를 접근할 때마다 제공함으로써 로그인을 유지한다. 4. Cookie가 없어지면 이 과정을 처음부터 시작한다.
cookie는 확인증이다.
-> 로그인했다는 사실을 증명하기 위하여 client가 제공해야하는 것이다.
session은 확인증에 대한 발급 정보이다.
-> 다시 로그인할 필요가 없게 해주는 역할을 한다.
따라서 session 로그인을 구현하기 위해서는
로그인한 client의 회원정보를 저장하는 session과
로그인했다는 사실을 확인시켜주는 cookie 모두가 필요하다.
Tip. 여기서 cookie는 session_id라는 사실을 인지해야한다.
jwt
jwt는 session과 로그인을 처리하는 방식은 비슷하다.
하지만, token을 사용한다는 것에서 조금의 차이가 생긴다.
일단, token이 어떻게 생겼는지 살펴보면,
(예시는 jwt.io에 자료를 사용했다.)
token은 .을 기준으로 3부분인 Header, Payload, Signature로 나뉘게 된다.
Header
token에 대한 정보를 알려준다.
header에는 암호화를 하는 해싱 알고리즘과 token의 타입을 지정한다.
Payload
보내고 싶은 데이터를 암호화한 부분이다.
대부분 client를 식별할 수 있는 정보를 key-value 형식으로 담는다.
Signature
token의 위조, 변조를 확인하는데 사용되는 부분이다.(SecretKey를 통한 확인)
인코딩된 Header와 Payload를 더하고, SecretKey로 해싱하여 생성한다.
인코딩된 Header와 Payload는 변질의 위험이 있지만,
서버에서 관리하는 SecretKey만 노출되지 않는다면 복호화가 불가능하다고 한다.
흐름
1. client가 로그인 했을 때, 필요한 회원정보를 바탕으로 token을 발급한다. 2. client는 발급받은 token을 통신할 때 서버에 제공한다. 3. 서버는 제공받은token이 유효한지 확인한다. 4. token이 만료되거나 없어지면 다시 1번부터 시작한다.
여기서 token은 session 방식에서 session_id와 유사하다.
하지만 큰 차이점은 서버에서 어떠한 데이터를 저장할 필요가 없다는 점이다.
-> 저장소 마련할 필요가 없으므로 서버 부담 감소.
각 테크닉이 가진 장점과 단점
session방식과 jwt 방식을 비교하면, 서로의 장단점이 명확하다.
따라서 자신의 프로젝트에 맞는 로그인 방식을 채택하는 게 좋아보인다.
Session Login
장점
- client의 유의미한 정보를 통신하는 것이 아니기 때문에, 만약 정보가 노출되더라도 그나마 안전하다.
- client마다 session_id가 부여되기 때문에 서버에서 연산하는 정도가 적어진다.
단점
- 중앙 session 관리 시스템이 없다면, 시스템 확장에 확장이 어렵다.
- 서버에서 session 저장소를 사용하기 때문에, 로그인 요청이 많아지면 서버에 부하가 걸린다.
Jwt token Login
장점
- 인증을 위해 서버에서 필요한 별도의 저장소가 없어도 된다!
-> Stateless한 서버! - token안에 모든 정보가 들어있기 때문에 서버에서는 인증만하면 된다.
- header와 payload를 가지고 signature를 생성하기 때문에 데이터 위변조를 막을 수 있다.
- 확장성이 뛰어나다.
단점
- 토큰이 탈취당하면, 대처하기가 어렵다.
-> 한번 발급하면 유효기간 전까지는 토큰이 유효하기 때문에. Payload 자체가 암호화되지는 않기때문에이건 확인 후 작성.- client가 사용하다가도 token이 만료되면 재 로그인을 요청해야한다.
-> 수명이 짧으면, 재로그인을 여러번해야함.
-> 하지만 수명이 길면, 보안 상의 문제가 발생한다.
보완
jwt의 단점을 보완하기위해서 가장 중요한 것은
"token의 수명을 어느정도로 결정하는 것인가" 인 것 같다.
짧게 설정할수록 안전하지만, 사용자 입장에서는 번거로울 것이다.
그래서 나온 개념이 Refresh Token 이다.
Refresh Token
Client가 login을 요청할 때,
Access Token과 Access Token보다 수명이 긴 Refresh Token을 생성해준다.
Access Token은 Client에게 발급하여 사용하게하고,
Refresh Token은 만약 Access Token이 만료되었을 때, 재발급을 요청한다.
또한, 서버가 강제로 Refresh Token을 만료시킬 수 있으므로
2개의 단점을 보완할 수 있다.
하지만, 이는 trade-off이다.
jwt의 강점이었던 stateless 서버가 더이상 유지될 수 없기 때문이다.
Refresh Token을 저장해야하는 필요성이 생겼기 때문에, 저장소가 필요하다.
