앞의 내용에 이어서 Cookie🍪 는 보안에 취약하여 쿠키가 유출되거나 조작될 위험이 있다.
그에 따른 대응 방식들에 대해 정리해보고자 한다.
👉 Cookie & Session 방식
- 세션은 비밀번호나 개인정보 등 클라이언트의 인증 정보를 쿠키가 아닌 서버 측에 저장하고 관리
Set-Cookie: JSESSIONID= ~~~~- 서버는 클라이언트의 로그인 요청에 대한 응답을 작성할 때 , 인증 정보는 서버에 저장하고 클라이언트 식별자인 JSESSIONID를 쿠키에 담음
- 클라이언트는 이후에 요청을 보낼 때마다 JSESSIONID 쿠키를 함께 보낸다
- 서버는 JSESSIONID 유효성을 판별해 클라이언트 식별한다
🤢 세션 단점
- 쿠키를 포함한 요청이 외부에 노출되어도 세션 ID자체는 유의미한 개인정보를 담고 있지 않음 그러나 해커가 이를 중간에 탈취하여 클라이언트인척 위장할 수 있음
- 서버 세션 저장소를 사용하므로 서버 부하가 심해진다
👉 JWT 방식
- JWT(JSON Web Token)란 인증에 필요한 정보들을 암호화시킨 토큰을 의미
- JWT기반 인증은 쿠키/세션 방식과 유사하게 JWT토큰을 HTTP헤더에 실어 서버가 클라이언트 식별
- JWT는 .을 구분자로 나누는데 Header, Payload, Signature로 구성됨
- Header : alg, typ 각각 정보를 암호화할 해싱 알고리즘 및 토큰의 타입을 지정
- Payload : 토큰에 담을 정보, key-value 형식의 정보
- Signature : 인코딩된 Header와 Payload를 더한 뒤 비밀키로 해싱하여 생성 , Signature은 서버측에서 관리하는 비밀키가 유출되지 않는 이상 복호화(검증)할 수 없음, 즉, Signature은 토큰의 위변조 여부를 확인하는데 사용 - 클라이언트 로그인 요청이 들어오면 서버는 검증 후 클라이언트 고유 ID 등의 정보를 payload에 담은 후 암호화할 비밀키를 사용하여
access-token(JWT)를 발급
🤭장점
- Header와 Payload를 가지고 Signature를 생성하므로 데이터 위변조를 막을 수 있다.
- 인증 정보에 대한 별도의 저장소가 필요없다.
- OAuth의 경우 Facebook, Google 등 소셜 계정을 이용하여 다른 웹서비스에서도 로그인을 할 수 있다.
- 모바일 어플리케이션 환경에서도 잘 동작한다. (모바일은 세션 사용 불가능)
🤢단점
- 쿠키/세션과 다르게 JWT는 토큰의 길이가 길어, 인증 요청이 많아질수록 네트워크 부하가 심해진다.
- Payload 자체는 암호화되지 않기 때문에 유저의 중요한 정보는 담을 수 없다.
- 토큰을 탈취당하면 대처하기 어렵다.
😼대응방안
- JWT 토큰 만료시간을 짧게 설정하여 피해 최소화( 사용자가 자주 로그인해야하는 불편함)
- Refresh-token 을 발급하는 전략
- 클라이언트는access-token이 만료되었을 때refresh-token을 사용하여access-token의 재발급을 요청
- 서버는 DB에 저장된refresh-token과 비교하여 유효한 경우 새로운access-token을 발급하고 만료되면 사용자에게 로그인 요구- 관련된 코드를 참조하고 싶다면 https://hou27.tistory.com/entry/Refresh-Token
출처: https://tecoble.techcourse.co.kr/post/2021-05-22-cookie-session-jwt/
https://inpa.tistory.com/entry/WEB-📚-JWTjson-web-token-란-💯-정리 [👨💻 Dev Scroll:티스토리]
더 자세한 설명! : https://jay-ji.tistory.com/101
winwin