[Spring Security] 쿠키 vs 헤더로 JWT 보내기

 

아직도 로그인에서 벗어나지 못한 나

그치만 너무 어려워.......

이거 어려워하는거 나만 그런거 아니겠찌?.. 암튼

 

OAuth2 카카오로 로그인하는 부분 흐름을 공부하던 중에,

인가 코드 받고 -> 엑세스 토큰 받고 -> 사용자 정보 요청하고

-> 그 사용자 정보로 JWT 토큰 만들고

-> 그 토큰을 쿠키에 담아서 브라우저로 보낸다

-> 브라우저는 해당 쿠키를 매 요청시 포함해서 보낸다

 

까지는 알겠는데,

그럼 왜 굳이 쿠키를 쓸까? 하는 의문이 들었음

 

쿠키라는게,

사용자가 누군지 기억해줘서 로그인을 유지시키고..

이런 장점이 있다고 들었는데,

지금까지의 흐름을 보면 이 쿠키의 장점이 활용되는게 어디에도 없어보임.

 

그래서 알아봤는데,

요약하자면  브라우저 환경에서의 보안과, 개발자 편의성 때문이라고 함.

 

Authorization 헤더에 JWT 토큰 담아서 보내는 방식은,

프론트에서 매 요청마다 직접 헤더 설정을 해줘야함.

 

근데 Cookie 방식은

자동으로 쿠키가 요청에 붙음.

다만 CSRF 공격 위험이 있어서 추가 대응이 필요하다고 함.

 

// 헤더 방식
axios.get('/mypage', {
  headers: { Authorization: 'Bearer eyJ...' }
})

// 쿠키 방식
axios.get('/mypage') // 자동으로 access_token 쿠키가 포함됨

 

이런식으로 매번 헤더에 넣지 않아도 된다는 장점이 있따고 함.

프론트엔드에서 토큰을 직접 보관하고 헤더에 넣을 필요가 없음.

 

 

다만 보안은 좀 더 신경써야한다.

 

 

그리고 또 궁금했던게, 쿠키를 쓰게 되면

로그인이 유지되고~ 사용자를 기억한다~~ 이런 말이 항상 붙었떤거 같은데,

이게 뭔소리람? 싶었는데,

 

=

프론트에서 매번 Authorization 헤더를 넣을 필요가 없다는 뜻임.

 

 

---

그리고 쿠키를 쓰면, 프론트에서 토큰을 보관할 필요가 없다고?

토큰은 보관 안하더라도 쿠키는 보관 해야되잖아.

그럼 그게 그거 아님???

 

 

=

헤더 방식의 경우, 프론트는

JWT 를 로컬 스토리지or세션스토리지 에 저장하고

요청 보낼때마다 헤더에 직접 끼워넣어서 보내야함.

 

근데 쿠키 방식의 경우, 프론트는

JWT를 보관 안함!

브라우저가 알아서 쿠키를 첨부함.

근.데!!!

보안 측면에서 엄청난 차이가 발생함.

쿠키 방식은, 스크립트 해킹으로 토큰 탈취 위험이 거의 없지만

로컬 스토리지나 세션 스토리지에 보관하게 되면

걍 getItem.("token")하면 되기때문에 바로 훔쳐가기 가능

 

---

그치만 백엔드 입장에서는 한번 더 JWT 를 얻기위해 파싱해야하는 수고가 느는거 아니냐?

 

=

맞음!

다만, 보안성과 프론트의 편의성에 비해서는

백엔드에서 한번 파싱하는게 훨씬 덜 수고로움

 

 

 

 

브라우저가 쿠키를 알아서 첨부한다는게 뭔뜻이냐?

 

=

쉽게 말해, 브라우저는 다음 조건이 해당되면, 자동으로 쿠키를 요청에 실어서 보냄

 

1. 요청하는 도메인과 경로 = 쿠키의 설정

2. 쿠키가 아직 만료 안됏을 때.

 

예를들어, 서버에서

Set-Cookie: access_token=abc.def.ghi; Path=/; Domain=yourdomain.com;

이런식으로 쿠키를 설정함.

 

그러면, 요청 URL이 https://yourdomai.com/ or 그 하위 경로일 때

or 쿠키 유효기간 안지났을 때

이 쿠키를 자동으로 붙이는거임.

 

 

= 프론트 개발자는 암것도 안해도 됨!

 

 

---

그럼 만약의 쿠키 안의 JWT 토큰이 유효기간이 지났으면 어떡하냐?

 

=

- 브라우저는 토큰이 만료됐는지 모르기때문에

- 쿠키에 있으니까 걍 무조건 무지성 보냄

- 서버가 받고, JWT 파싱한 다음에, 유효기간 보고

- 만료됐으면 401 Unauthorizaed 보냄

- 브라우저는 리프레시 토큰을 이용해서 토큰 재발급 API요청함

- 그러면 서버는, 새 JWT 토큰 만들어서 new 쿠키를 줌!

- 브라우저는 이렇게 받은 new 쿠키로 덮어씀

 

 

그러면 리프레시 토큰은 브라우저가 보관하는거 아니냐?

기껏 토큰 보관하면 위험하다고 해서 쿠키 저장하는구만

리프레시 토큰을 브라우저가 저장하면 무슨 소용?

 

=

마찬가지로 브라우저가 직접 JS로 관리하면 위험함!

따라서 리프레시 토큰도 HttpOnly 쿠키로 저장하는게 일반적임.

 

 

 

 

---

'해당 도메인의 쿠키를 요청에 같이 보냄' 에서 해당 도메인?

도메인별로 쿠키가 나눠져있냐?

한개의 쿠키 안에, 한개의 JWT 토큰. 즉 한사람에 대한 정보만 담기는거 아니야? 그럼 도메인별로 저장될게 아니라 사람별로 저장되어야 하는거 아님?

 

=

쿠키는 도메인 단위로 저장되고 구분됨.

 

한 사용자가, 여러 사이트를 방문하면, 각 도메인에 따라 다른 쿠키들이 따로 저장됨.

하나의 도메인에 대해서, 여러명이 접근하는 경우에도

각자의 브라우저가 관리하는 자신만의 쿠키를 보내기때문에 유저가 구분이 되는거임.

 

예를들어 내가 myapp.com에 접속했음

-> 서버가 쿠키를 줌. 그 쿠키 안에는 JWT 토큰 들어있고

이 쿠키는 도메인 = myapp.com 전용 쿠키임..

 

그 다음에 내가 kakao.com에 접속했음

-> 또 다른 쿠키가 마찬가지로 생김

그건 kakao.com전용 쿠키임!