참고 : https://velog.io/@wnsgur9701/%EC%9D%B8%EC%A6%9DAuthentication%EA%B3%BC-%EC%9D%B8%EA%B0%80Authorization
https://doogle.link/jwt-혹은-oauth2-의-refresh-토큰을-어디다-저장해야-할까/
https://www.youtube.com/watch?v=1QiOXWEbqYQ
개요
왜 필요한가?
- 자원을 적절하고 유효한 사용자에게 전달하거나 공개하기 위한 조치로써 , 쉽게 말해 허가된 인원에게만 자원에 대한 접근을 허용하는 것을 의미합니다.
HTTP 프로토콜의 경우, 비연결성 , 무상태성 이라는 특성이 있습니다.
즉, 서버는 클라이언트에 대한 요청에 대한 응답 후 연결을 끊어버리고 기억하지 못합니다.
그러므로 인해 , 같은 클라이언트에서 연속된 요청이 들어오더라도 각각 독립적으로 반응하게 됩니다.
하지만, 로그인 같은 서비스의 경우 , 서버가 정보를 기억하지 못
하니 , 매번 사용자 정보를 서버에 보내 인식시키는 것은 번거로울 뿐만 아니라 보안에도 위험합니다.
이 점을 방지하기 위해 다양한 방식의 인증/인가 방식들이 제공되고 있고 아래에서 살펴보겠습니다.
1.Request
- 사용자의 정보를 Request에 값을 넣어 요청하는 방식입니다.
보통 서버로 HTTP 요청을 할 때 따로 암호화 되는 과정이 없기에, 요청해야 할 때마다 패스워드 같은 중요 정보를 담아 매번 인증하는 작업은 해킹에 위험이 큽니다.
2.Cookie
로그인 시 처음 들어온 정보를 가지고 읽어 사용자를 확인한 후에 사용자의 정보를 쿠키에 담아 브라우저에 응답합니다.
그 후 , 이 쿠키를 가지고 인증 작업을 거칩니다.
장단점을 살펴보자면,
장점
-
클라이언트에 저장하므로 , 서버의 메모리를 절약할 수 있습니다.
단점
-
쿠키 또한 사용자 정보가 담겨있고, 요청마다 request메세지 헤더에 담아 보냅니다. 즉 , 사용자 정보가 노출된다는 점은 마찬가지입니다.
-
쿠키 만료시간이 지나지 않을 경우, 브라우저를 종료해도 남아있습니다.
3.Session
쿠키와 초기 인증 방식은 같습니다.
단, 응답하는 쿠키에 사용자 정보 대신, Session ID를 담아 반환하고, Session ID와 매핑하여 사용자 정보를 서버에 저장합니다.
그리고 , 서버는 쿠키에 담겨 오는 Session ID를 가지고 , 해당 값으로 저장된 사용자 정보가 있을 경우 인증을 허가합니다.
장점
- 사용자 정보 대신, Session ID를 이용하므로 안전하다.
- 서버에서 제어가 가능하여 , 만료 시킬 수 있다.
단점
-
서버에 저장되므로 , 사용자가 많을 수록 , 보관하는 정보가 클수록 부하가 크다.
-
여러 개의 서버가 있을 경우, 사용자 정보가 보관된 서버가 아닌 서버에 요청이 갈 경우 인증이 불가하다.
3.JWT
JWT (Json Web Token)란 Json 포맷을 이용핳여 사용자에 대한 속성을 저장하는 Claim 기반 Web Token입니다.
방식은 비슷합니다.
처음 요청으로 인증 되었다면, 서버 측에서 쿠키 대신 토큰을 발급하는 형태입니다.
단, 서버에 사용자 정보를 저장하지 않습니다.
Claim? 토큰에 담긴 사용자 정보등의 데이터를 의미한다.
구조
-
Header
위 3가지 정보를 암호화할 방식(alg), 타입(type) 등이 들어갑니다.타입은 언제나 JWT라는 값이 들어갑니다.
-
Payload
서버에서 보낼 데이터가 들어갑니다. 일반적으로 유저의 고유 ID값, 유효기간등이 들어갑니다. -
Signature
Base64 방식으로 인코딩한 Header,Payload 그리고 서버에 저장한 Secret Key를 더한 후 암호화 알고리즘으로 암호화 한 값이 서명됩니다.
장점
-
token 자체에 모든 정보가 담겨져 있고 , 서버측에는 별도의 저장소가 필요하지 않습니다.
-
서버의 Secret Key를 알지 못하는 이상 , 위변조 하더라도 안전합니다.
단점
-
서버 측에서 제어가 불가능합니다.
세션의 경우 , 서버에서 제어가 가능하여 , 보관중인 사용자 정보를 지울 경우, Session ID는 무용지물이 됩니다.반면 , JWT는 토큰값을 서버의 Secret key를 이용하여 유효한지만 검증하기 때문에 토큰 그 자체를 탈취 당할 경우, 만료 시간이 되기 전까지는 제어할 방법이 없습니다.
그렇기 때문에, 만료시간을 짧게 줄 수 밖에 없습니다.
지속하기
만료 시간을 짧게 주기 때문에 , 사용자는 매번 로그인을 해야합니다.
하지만 , 이를 최소화 하기 위해 refresh token를 이용합니다.
간단히 말하자면, 토큰이 만료 되었을 경우, refresh token을 이용하여 재발급을 받는 것입니다.
원리
-
사용자가 인증이 되면, Access Token 뿐만 아니라, Refresh Token을 함께 응답합니다.
-
Access Token을 이용하여 접근하다가 , 만료될 경우 서버는 해당 Access Token으로 인한 접근을 거부합니다.
-
사용자는 Refresh Token을 보내어, Access Token을 재발급 받아서 사용합니다.
refresh Token의 경우 JWT와 같은 형태이며, 보통 DB에 저장
문제
- 토큰의 탈취로 인한 보안상 문제를 완전 예방하기는 힘들다.
- Refresh Token 마저 탈취 당할 경우는 더 큰 위험.
- Access Token이 만료될 때마다 , DB에 접근해야 하며 HTTP 요청 횟수의 증가.
