[📋] Jwt Token 저장 위치 - http header vs cookie

개요

열심히 jwt token 관련 코드를 구현하고 있는 와중에 문뜩 생각이 들었다.

예전에 공부했을 때는 그냥 http body로 넘겨줘서 header로 넘기고 받았는데, cookie에 담아서 보내줄 수도 있는 것을 알게 되었다.

http header를 통해 주고 받는 게 맞는건가, 아니면 cookie에 넣어서 넘겨주는 게 맞는건가?

구현 전에 정했어야 했는데, 시간이 너무 급박해서 어영부영 시작하고 보는 것도 있는 것 같다ㅎ..

팀 회의에 안건을 꺼내보기 전에 미리 알아보고 생각을 정리할 겸 포스팅한다.

---

토큰 저장 방식

1. Header - Authorization Bearer Jwt Token

장점

• 개발자가 토큰을 추가하고 제거할 수 있어 토큰 관리에 더 많은 제어가 가능함
• 다른 도메인의 클라이언트에서도 API를 호출할 수 있음 = CORS 문제 없음
• Stateless 
• 클라이언트가 저장 공간을 자유롭게 지정할 수 있음(로컬 스토리지, 세션 스토리지, 메모리 등..)

단점

• XSS 취약
• 클라이언트의 토큰 관리 필요

2. Cookie

장점

• 자동 전송 및 편한 관리
• 쿠키 속성을 통해 CSRF 보호 방지 가능
• HTTPOnly | Secure 속성을 설정해 쿠키 보호 가능

단점

• 제대로 설정하지 않으면 CSRF 문제에 노출 가능
• 서버의 상태를 계속 유지해야해 Stateless를 불만족
• 동일한 출처 정책에 따라 관리해야 하므로, CORS 문제 발생 가능

---

발생할 수 있는 문제점

jwt를 쿠키에 담을까요, 헤더에 담을까요?

jwt를 쿠키에 담을까요, 헤더에 담을까요?

위 글에서도 jwt를 쿠키에 담아야할지, 헤더에 담아야할지 고민인 분이 있었다.

답글 내용 중에는 쿠키는 웹 브라우저의 사양이라는 말이 있었고,

더 찾아보니 앱에서도 쿠키를 사용할 수는 있지만, 웹 브라우저 기반과는 다르게 동작하기 때문에 일일히 세션을 다 관리해줘야 한다는 걸 알게 되었다. 

모바일 앱이나 데스크톱 앱에서는 웹 브라우저처럼 자동으로 쿠키를 관리하지 않기 때문에 쿠키 사용이 더 복잡해진다는데, 이러면 쿠키의 장점인 자동화를 전혀 살리지 못하는 게 아닐까?

---

결론

우리 프로젝트에서는 리액트 네이티브로 앱을 만들기로 했고, 추후 웹 브라우저까지 확장을 고려 중이다.

여러 형태의 개발을 앞두고 있는 이상, 인증 관리가 통일화 되지 않으면 유지 보수 측면에서 번거로울 것 같다는 게 내가 느끼기에 가장 큰 단점이었고, (시간도 부족한 상황에서 일일히 쿠키 수동 관리를 하면 프론트 측에서 너무 힘들지 않을까..)

쿠키의 보안성 같은 장점들이 속성을 잘 설정해야 한다는 조건이 있는 이상, 큰 장점으로 다가오지는 않았다.

http의 특징인 stateless를 잘 충족하고, 공식 문서에서도 header의 Authorization에 Bearer <token>을 문서로 제공해주고 있으니 http header에 jwt를 넣어서 관리하는 게 좋을 것 같다. 

---

참고

나는 왜 JWT를 사용했을까?(feat. 쿠키,세션,토큰)

나는 왜 JWT를 사용했을까?(feat. 쿠키,세션,토큰)

쿠키(Cookie) & 세션(Session)

쿠키(Cookie) & 세션(Session)

인증(Authorization)관련 Header, 그리고 쿠키(Cookie)

인증(Authorization)관련 Header, 그리고 쿠키(Cookie)

[Project] 토큰은 Header vs Cookie 어디에 저장하는게 좋을까?

[Project] 토큰은 Header vs Cookie 어디에 저장하는게 좋을까?

모바일 앱에서 세션을 사용하지 않는 이유

모바일 앱에서 세션을 사용하지 않는 이유