리프레쉬 토큰이 필요한 이유는 무엇인가요?

Question

보통 &#34;짧은 만료시간을 가지는 엑세스 토큰이 만료될 경우, 새로운 엑세스 토큰을 발급 받기위해 리프레쉬 토큰을 사용한다.&#34;라고 설명하는 것 같습니다.하지만 리프레쉬 토큰 자체가 탈취 당할 수 있는데, 그렇다면 리프레쉬 토큰을 사용하는 의미가 없지 않나요?엑세스 토큰 만료 기한을 아무리 짧게 잡아도, 긴 만료기한을 가진 리프레쉬 토큰 자체가 탈취당하면 의미가 없다고 생각이 드네요..

sitonik · Accepted Answer

ㅇ 엑세스 토큰이 탈취 되었을때 왜 서버에서 방어적인 행동을 할 수 없고, 탈취 사실 조차 알 수 없나요?1. 정상적으로 발행된 token의 경우 서버에서 정상적인 사용자라고 인식하기 때문에 해당 token의 만료 시간이 지나기 전까지는 없앨 수 없습니다. (stateless 특성 때문) ㅇ 리프레쉬 토큰으로 해커에 대응 했던 것 처럼, 엑세스 토큰을 보내온 요청 ip 지역이 매우 상이하거나 신고된 아이디인 경우 탈취 되었음을 알아차리고 대응할 수 있지 않나요? (해당 계정에 대한 로그인 차단과 사용자에게 해당 아이피에서 접속한 것이 맞는지 물어보는 대응)2. 보통의 경우, 정상적인 로그인 시 access token을 발급받게 됩니다. 말씀하신 것처럼 access token을발급 받을 때마다 처리하는 로직이 구현되어 있다면 매번 검증이 가능합니다. 다만 서버에 부하가 갈 수 있습니다. ㅇ 그리고 엑세스 토큰이 만료되기 직전에 요청을 보내면 새로운 엑세스 토큰을 자동으로 발급해주도록 하여, 로그인이 끊기지 않게 할 수 있지 않을까요?3. access token은 정상적인 로그인 시에만 발급해줍니다. 새로운 access token을 발급하기 위해서는 사용자의 ID와 PW가 필요합니다. 즉, 재로그인이 필요하다는 것이며, refresh token 없이는 무조건재로그인을 해야 새로운 access token이 발급됩니다. 이는 사용자의 불편을 야기할 수 있습니다.다시말해 access token은 로그인 과정 없이 발급될 수 없습니다. ㅇ 그냥 엑세스 토큰 만료기한을 길게 줘버리는 것은 어떤가요? 만료시간이 너무 길어서 보안에 취약하다고 하시겠지만, 어차피 리프레쉬 토큰도 오랜시간 동안 클라이언트가 가지고 있으므로, 리프레쉬 토큰을 사용한다 할지라도 보안이 더 좋다고 생각하지 않습니다.4. 이 문제는 항상 나오는 것이며 답은 없습니다. 클라이언트에게 제공되는 refresh token에 대한 안전성은 늘 문제로 제기 될 수 있습니다. 그래서 refresh token을 어디에 저장할 것인지는 보안 정책 상황에 따라 다르다고 할 수 있습니다. (http only)cookie, local storage, session storage에 저장될 수 있으며 각각 보안상 장단점이 있습니다. 또한 refresh token 발행에 PKCE가 사용할 수도 있습니다. 다만, access token의 안전성 확보를 위해 만료 시간을 짧게 잡았고 그것을 보완하기 위해refresh token이 생겼다는 사실은 기억하시기 바랍니다. 추가. 링크에 거신 블로그 분의 마지막 2번에 대한 것은 엡실론님의 답변이 될 수 있습니다. 토큰이 아닌 아이디 및 이메일로 접근 제한시 다른 서버가 인증 서버에게 지속적으로 해당 사용자가 정당한지 물어보는 경우가 발생하기 때문에 인증 서버에 부담이 가며, 이는 추후 서비스 확장시 서버 scale out 작업 때 문제가 생길 여지가 다분합니다.

sitonik · Answer

stateless라는 jwt 특성 때문입니다. 만약 access token의 만료 기간을 길게 잡아 이것만 사용하게 한다면access token이 탈취 되었을 때 서버에서 아무런 방어적인 행동을 할 수 없습니다. 더욱이 서버는 해당 token이 탈취 되었다는 사실 조차 모를 수 있습니다. 그래서 클라이언트 측에 2개의 토큰을 주는 것입니다. access token을 서버에게 전송해 인가 작업이 이루어지고, refresh token은 access token을 발급할 때만 서버에 전송합니다. 만약 refresh token이 탈취되어해커가 새로운 access token을 요구해 발급받을 수 있습니다만, 이 발급이 진행되는 과정에서 다른 나라의IP 주소로 요청이 들어왔다던가 또는 계정 도용으로 신고된 아이디이던가 등을 검증할 수 있는 작업을 서버에서 할 수 있는 것입니다. 그러면 서버는 해커가 refresh token으로 요청한 것을 무시(거절)하고 해킹된refresh token을 서버에서 지워버려 access token을 해커에게 발급하지 않을 수 있습니다. 다만, HTTP 하이재킹으로 중간에 만료 시간이 지나지 않은 access token이 탈취될 수 있습니다.이 때문에 HTTPS를 반드시 기본으로 사용하여 클라이언트와 서버 간에 전송되는 데이터를 암호화하는것입니다. 결론. 한 번 발급되면 정보가 변하지 않는 stateless라는 jwt 특성 때문에 refresh token을 사용하여 access token을 발급한다. refresh token이라는 방어 도구라도 있어야 서버가 해킹된 토큰에 대한 방어 행동을 취할 수 있게 된다 입니다. 참고로 관련해서 읽어보시기 바랍니다. https://stackoverflow.com/questions/3487991/why-does-oauth-v2-have-both-access-and-refresh-tokens/12885823#12885823 추가. 만약 access token의 만료 시간을 짧게 해서 계속 발급해주면 어떨까요? 또한 매번 사용자의상태를 점검해서 안전한지 확인하는 것은 어떨까요? > 전자는 refresh token이 없기 때문에 access token이 만료되면 다시 로그인을 해야 합니다. 이는 서비스 이용 도중 로그아웃이 되어 버리는 상황이 되어 사용자의 불편함을 야기할 수 있습니다. 로그인 상태를 계속 유지하기 위해 access token이 만료되는 순간 refresh token을 통해 다시 access token을 받아올 수 있으므로 사용자는 로그인이 계속 되어 있다고 느낄 수 있습니다.후자는 stateful의 특성을 갖는 세션 방식을 사용하는 게 낫습니다.

hihihiih · Answer

sitonik 친절하고 상세한 답변 감사합니다! 엑세스 토큰이 탈취 되었을때 왜 서버에서 방어적인 행동을 할 수 없고, 탈취 사실 조차 알 수 없나요? 리프레쉬 토큰으로 해커에 대응 했던 것 처럼, 엑세스 토큰을 보내온 요청 ip 지역이 매우 상이하거나 신고된 아이디인 경우 탈취 되었음을 알아차리고 대응할 수 있지 않나요? (해당 계정에 대한 로그인 차단과 사용자에게 해당 아이피에서 접속한 것이 맞는지 물어보는 대응) 그리고 엑세스 토큰이 만료되기 직전에 요청을 보내면 새로운 엑세스 토큰을 자동으로 발급해주도록 하여, 로그인이 끊기지 않게 할 수 있지 않을까요?

hihihiih · Answer

그냥 엑세스 토큰 만료기한을 길게 줘버리는 것은 어떤가요? 만료시간이 너무 길어서 보안에 취약하다고 하시겠지만, 어차피 리프레쉬 토큰도 오랜시간 동안 클라이언트가 가지고 있으므로, 리프레쉬 토큰을 사용한다 할지라도 보안이 더 좋다고 생각하지 않습니다. 아래 링크는 제 생각과 비슷한 글 입니다.https://zzossig.io/posts/etc/what_is_the_point_of_refresh_token/

엡실론 · Answer

액세스 토큰/리프레쉬 토큰은 보안성, 성능, 사용편이성 등등을 적절하게 타협한 결과입니다. 보안만 추구한다면 더 좋은 방법들이 많이 있습니다.액세스 토큰을 무효화 처리하는 것도 당연히 가능합니다. 액세스 토큰이나 리프레쉬 토큰이나 본질적으로는 차이가 없으니까요. 하지만 액세스 토큰을 무효화 하는 것은 리프레쉬 토큰 무효화보다 성능에 더 영향을 줍니다. 1. 리소스 서버와 인증 서버가 분리된 경우, 매번 인증서버에 무효화 여부를 물어봐야 하고, 인증서버가 보틀넥이 됩니다. 2. 그렇지 않은 경우 역시, 토큰 무효화는 DB와 같은 서버 스토리지가 필요하고 따라서 latency에 영향을 줍니다.따라서 저런 타협의 결과물로 일반적으로 액세스 토큰은 짧은 유효기간을 가지고 별도의 무효화는 지원하지 않습니다. 대신 리프레쉬 토큰은 긴 유효기간과 무효화를 지원합니다. 리프레쉬 토큰은 탈취되면 큰일이니, 항상 안전한 곳에 보관하고, https와 같은 안전한 전송수단만을 사용해야 하고, 액세스 토큰 발급시에만 전송해야 합니다. 예를 들어 액세스 토큰 유효기간이 1시간이라면 리프레쉬 토큰은 1시간에 한번만 사용되니, 탈취 가능성을 대폭 줄일 수 있습니다.

ISA · Answer

윗분들 친절한 설명 좋아요. 추가적으로 깃허브 인증 같은 경우 리프레쉬 토큰을 사용하지 않습니다.대신 토큰 발행에 관해서 알아보시면 깃허브의 경우 토큰 발행 자체를 유저가 직접 컨트롤 할 수 있습니다. 모든 권한 및 업데이트 와 삭제까지요.리프레쉬 토큰은 옵션이지만 사실 거의 필수 입니다. 인증 간편화라는 측면에서는요.

hihihiih · Answer

엡실론 sitonik ISA답변 너무 감사드립니다. 항상 어려워 했던 부분인데, 정말 좋은 답변들 주셔서 다시 한 번 공부하고 정리해볼 수 있어서 너무 좋았습니다. 아래는 제가 답변과 추가 학습을 토대로 나름대로 이해한것을 정리해본 것인데, 틀린점은 없는지 좀 더 생각해볼 부분은 없는지 한 번 봐주시면 정말 감사하겠습니다. &#x1f647;&#x1f3fb;‍♂️ 만료 기한이 짧은 엑세스 토큰만 사용할 때의 단점사용자가 매번 재로그인 해야하는 번거로움이 있다. 만료 기한이 긴 엑세스 토큰만 사용할 때의 단점엑세스 토큰은 탈취 당하거나, 사용자 로그아웃, 사용자 계정이 신고 되었음 등의 이유로 토큰 무효화 기능을 제공하는 상황엑세스 토큰을 포함하는 모든 요청마다 엑세스 토큰 검증을 하고, 엑세스 토큰이 무효화 되었는지 검증하는 과정도 추가되어 부하가 커질 수 있음(해당 단점은 무효화 기능을 인메모리 DB 레디스로 구현하면 해결될지 궁금합니다. 물론 인증 서버와 여러대의 리소스 서버로 구성된 경우 인증 서버 보틀넥 문제는 여전할 것 같습니다!) 위와 같은 단점으로 엑세스 토큰은 무효화 기능을 제공 하지 않는 대신 짧은 만료기한으로 발급하고, 리프레쉬 토큰은 무효화 기능 제공과 긴 만료 기간으로 발급한다. 이와 같이 리프레시 토큰을 사용하면, 사용자 재로그인 번거로움을 없애고, 토큰 무효화 기능 관련 부하 문제를 막을 수 있다. 하지만 리프레시 토큰을 사용한다고, 보안이 더 강화되는 것은 아니다. 사용자 편의, 성능, 보안 등을 적절하게 타협한 방법이다.

ISA · Answer

하지만 리프레시 토큰을 사용한다고, 보안이 더 강화되는 것은 아니다. 사용자 편의, 성능, 보안 등을 적절하게 타협한 방법이다 엑세스 토큰 단독 사용 보다는 당연히 보안이 강화 됩니다.엑세스는 결국 요청 header auth에 실어야하기에 프론트 단에서의 접근이 필수가 됩니다. 리프레쉬의 경우 그럴 이유가 없어서 http only 쿠키로 넘겨줄 경우 js를 통한 접근이 불가능한 측면이 있습니다.

hihihiih · Answer

ISA js를 통해서 httpOnly 세팅이된 쿠키에 담긴 리프레쉬 토큰을 직접 접근하는 것은 불가능하겠지만, csrf 공격은 여전히 가능하므로 보안적인면에서 더 나아지는 것은 없지 않나요? 그리고 엑세스 토큰 또한 헤더에 담아 보내는 방식이 아닌 http only 쿠키에 넣어서 보내는게 더 나은데 보통 왜그렇게 하지 않는지 궁금하네요..

ISA · Answer

xss는 막히니까요.ㅎㅎAuth에서 엑세스토큰이 위치하는 곳은 요청의 header의 authorization 입니다. 이건 공식 규격이에요.(추후 어떻게 변경될 수 있지만 기본적인 규약입니다.) 당연한말이지만 이건 결국 프론트 측에서 엑세스 토큰을 조작할 수 있어야 요청에 엑세스 토큰을 실어 줄 수 있다는 의미에요.그래서 엑세스 토큰도 로컬스토리지 &#61;> cookie &#61;> redux 같은 스토어(클로저로 감싸진 지역 변수)방향으로 꾸준히 탈취하기 어렵게 변경 되어 왔습니다. 본인 주장을 고수하고 싶은 느낌이 있으신거 같긴한데... 좀 더 자세히 알아보실려면 rfc를 살펴보시길 바랍니다. Jwt 뿐 아니라 jwe나 다른 것들도..

hihihiih · Answer

ISA 그럼 csrf 공격에 대해서 리프레쉬 토큰 방식은 보안적으로 더 이득이 없다라고 정리 해도 무방할까요?엑세스 토큰을 http only 쿠키에 넣어서 전달하지 않은 이유가 공식 규격 때문이라면, 공감이 잘 가지 않네요.. 이러한 규격이 왜 있는지 규격을 왜 맞춰야 하는지 고민을 해봐야겠습니다.제가 백 엔드쪽이라 리덕스 스토어는 처음들어보네요. 키워드 감사합니다. 한 번 공부해볼께요.아직 공부하는 입장에서 프로젝트를 진행간, 토큰 인증을 구현하는 과정에서 어떤 방법을 선택할지 정하는게 많이 어렵네요.. 아무튼 답변 감사드립니다. &#34;본인 주장을 고수하고 싶은 느낌이 있으신거 같긴한데... 좀 더 자세히 알아보실려면 rfc를 살펴보시길 바랍니다. Jwt 뿐 아니라 jwe나 다른 것들도..&#34; -> 절대 아닙니다.. ㅠㅠ 고집스럽게 느껴지셨나요 혹시.. 확실하게 제 생각을 정리해보고 싶어서 궁금한거 이것 저것 질문드렸습니다..

ISA · Answer

https://stackoverflow.com/questions/37582444/jwt-vs-cookies-for-token-based-authentication# 비슷한 고민에 대한 5년전 글입니다.쓰신 문장 자체가 스크립트 삽입 공격(xss)는 막히지만 csrf랑 관련없어서 보안상 더 나은게 없다고 하셔서 주장을 고수한다는 느낌을 받았어요.Csrf는 보안에 조금만 신경써도 쉽게 차단가능하거든요.프론트에서 자주쓰는 axios ajax 라이브러리 경우 자체적으로 지원해주는 기능이기도하고 ㅎㅎ..어떻게 이해하기 쉽게 설명해드릴까 하다가 아래 페이지를 찾았는데 확인해보시길https://backend-intro.vlpt.us/4/ 모든 아키텍쳐에 결점이 없을 순 없어요... ㅎㅎAuth 인증 규약 자체가 그러니까 header에 전송한다고 보는게 맞습니다.

ISA · Answer

사실 질문이 자세히 이해가 안가기도 하고요.리프레쉬 토큰에 대한 csrf는 보안이 신경써서 차단하고At의 경우 csrf이슈와 xss이슈가 header에 실어서 해결이 되거든요... 리프레쉬 토큰에 대한 csrf?를 걱정하면서 왜 엑세스토큰을 쿠키에 저장안하시냐고 묻는거 맞죠?

joniel · Answer

질문과 상관이 없을 수 있지만... 토큰에 대한 이야기들이 많이 나와서 제가 생각하던 궁금함과 처리방법에 대해서 약간 남겨봅니다. 혹여 리프레쉬토큰이 유출되었을 때 새로 재로그인한다고 해도 그 유효한 리프레쉬토큰을 탈취한 자는 계속 액세스토큰을 만들어 낼 수 있습니다. 따라서 리프레쉬토큰을 무효화하기 위해 서버측에서 verify시에 푸는 열쇠인 암호화 키를 고정하는 것이 아니라 (그렇다고 문제생길 때마다 암호화키를 바꿔버리면 수십만명 되는 사이트의 경우 모든 회원의 로그인이 풀려 재로그인해야하는 사태가 벌어질 수도...) 새롭게 발급할 때 키/로직을 개별적용하면 이전에 발급된 리프레쉬토큰 (2주정도 남은 쓸만한 것이라하여도) 서버의 verify 함수에서 인증할 키의 변경으로 인해서 거절당하니... 개인적인 보안 강화를 위해서는 개인적으로 풀 키의 기능(로직)으로 재발급을 해주는 것이 - 공용 키를 저장하거나, 개별 키를 지정해주는 것보다(이건 고객중요데이터증가로 부담상승) 특별 로직으로 verify할 수 있도록 하는 것이 부담을 덜 수 있지 않나 하는 생각을 요 며칠간 하게 되네요... 별 중요하지도 않을 수 있는 이야기를 드렸다면 죄송합니다. 최근 인증을 심각히 고민하고 있어서 어떤 블로그도 센터키로 인증을 하는 것을 이야기하지, 또는 개별 키로... 이전 발급된 키의 무효화를 위해 로직으로 키의 역할을 해서 푸는 것에 대해서는 발견을 못해서 말입니다. 여튼 아직 연구단계라 뭐라고 결과를 보여드릴 수 없어 죄송합니다.

리프레쉬 토큰이 필요한 이유는 무엇인가요?

14개의 답변

Q&A 목록