인프런 커뮤니티 질문&답변
작성한 질문수
클라이언트에서 jwt 토큰 핸들링 방식 질문 있습니다.
24.07.20 18:19 작성
·
109
·
수정됨
0
- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요!
- 먼저 유사한 질문이 있었는지 검색해보세요.
- 서로 예의를 지키며 존중하는 문화를 만들어가요.
- 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요.
안녕하세요 늘 감사히 잘 듣고 있습니다.
localStorage에 토큰을 넣는 방식은 좋은 방식인건가요?
저는 XSS (Cross-Site Scripting)와 CSRF (Cross-Site Request Forgery) 같은 해킹 방법에 대비하기 위해, Access Token은 전역 변수로 메모리에 저장하고, Refresh Token은 HttpOnly 및 Secure 속성을 가진 쿠키에 저장하는 것이 좋다고 들었습니다. 저도 프론트엔드 프로젝트를 진행할 때 이와 같은 인증 방식을 채택했습니다.
하지만 가끔 LocalStorage에 Access Token과 Refresh Token을 보관하는 경우를 보곤 했습니다. 이 방식에는 제가 모르는 다른 이점이 있는 것인지 궁금합니다.
현업에서는 클라이언트에서 jwt 토큰을 어떻게 보관하나요?
답변 2
0
2024. 07. 22. 11:42
안녕하세요 eunbae님ㅎㅎ
Access Token은 전역 변수로 메모리에 저장하고, Refresh Token은 HttpOnly 및 Secure 속성을 가진 쿠키에 저장하는 것이 좋다고 들었습니다.
>> 그런 방법을 쓰기도 합니다. XSS 공격을 방지하기 위해, Access Token은 브라우저 메모리에 저장하고 필요할 때마다 재발급받는 방법을 씁니다.
localStorage에 토큰을 넣는 방식은 좋은 방식인건가요?
>> 제가 생각하기에는 쿠키는 HttpOnly 및 Secure 속성을 사용할 수 있기 때문에 쿠키가 더 좋은 것 같습니다.
현업에서는 클라이언트에서 jwt 토큰을 어떻게 보관하나요?
>>
보통 jwt토큰을 사용하면 네이밍을 접두사가 token 또는 bearer로 시작하는데 이걸 기반으로 찾아본 결과는 다음과 같습니다.
라프텔에서는 로컬스토리지에 토큰을 보관합니다.
레딧의 경우 쿠키에서 관리합니다. (token_v2)
이 경우 HTTP only, secure 옵션이 걸려 있는 것을 알 수 있습니다.
velog에서는 쿠키로 관리합니다.
다만, 쿠키 - 세션의 경우 사례는 다음과 같습니다.
네이버의 경우 쿠키 - 세션을 쓰며 NID_AUT와 NID_SES라는 쿠키로 관리합니다.
다음의 경우 쿠키 - 세션을 쓰며 HM_CU, HTS, LSID, PROF, TS라는 쿠키로 관리합니다.
깃헙의 경우 쿠키 - 세션을 쓰며 user_session이라는 쿠키로 관리합니다.
여기서 볼 수 있듯이 로그인에 관한 정보를 쿠키에 담아 관리하는데 이마저도 네이밍을 흔한 session_id, access_token 등을 쓰지 않고 기업내에서 정한 이름을 바탕으로 관리하며 쿠키를 나눠서 관리하는 것을 알 수 있습니다. (github제외..)
또 질문 있으시면 언제든지 질문 부탁드립니다.
좋은 수강평과 별점 5점은 제게 큰 힘이 됩니다. :)
감사합니다.
강사 큰돌 올림.
0
2024. 07. 20. 18:21
안녕하세요, 인프런 AI 인턴입니다. eunbae.0님의 질문에 대하여 관련 답변을 찾았으며, 이에 대한 정보를 안내해 드리겠습니다.
LocalStorage에 토큰을 넣는 방식과 관련하여, 실제로 많은 웹 어플리케이션에서 LocalStorage, SessionStorage, 혹은 쿠키에 JWT 토큰(특히 Access Token)을 저장하는 방식을 채택합니다. 이 방법의 주된 이점 중 하나는 간편함과 접근성입니다. 토큰에 빠르게 접근할 수 있고, 개발이 비교적 간단합니다. 하지만, eunbae.0님께서 언급하신 것처럼 XSS 공격에 취약할 수 있습니다. 이는 LocalStorage에 저장된 토큰이 악성 스크립트에 의해 도용될 가능성이 있기 때문입니다.
현업에서의 JWT 토큰 보관 방식에 대해서는, 사실상 “최선”의 방식이라고 말하기 어렵습니다. 보안과 접근성 사이에 균형을 찾아야 하며, 이는 각 어플리케이션의 특성과 보안 요구사항에 따라 달라집니다. 일반적으로 보안을 우선시하는 경우, Access Token은 메모리에 저장하고, Refresh Token은 HttpOnly 및 Secure 속성을 가진 쿠키에 저장하는 방식을 선호합니다. 이를 통해 CSRF 공격을 방지하고, XSS 공격으로부터 토큰을 보호할 수 있습니다.
유사한 질문에 대한 답변으로, 클라이언트에서 JWT 토큰을 처리하는 방법에 대해 설명하는 글이 있습니다. 여기서는 jwt 토큰 관련 질문입니다!의 답변에서 세부적인 처리 방안 및 보안에 관한 조언이 담겨 있으며, 이는 eunbae.0님의 질문과 밀접하게 연관되어 있습니다.
또한, jwt 토큰과 관련된 자세한 설명도 있으며, 여기서는 특히 클라이언트와 서버 간의 토큰 교환 및 저장 방법에 대해 논의되어 있습니다.
보안을 강화하기 위한 쿠키 secure 질문입니다.에서 다룬 Secure 옵션의 중요성과 그것이 쿠키 보호에 어떻게 기여하는지에 대해서도 찾아볼 수 있습니다.
마지막으로, Access Token과 Refresh Token 문제에 대한 글에서 현업에서 Refresh Token 탈취 문제를 어떻게 해결하는지에 관한 실질적인 예시와 조언을 제공합니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.