리프레시 토큰이 필요한가?

그냥은 심심하니까 귀여운 피카츄와 데덴네

 로그인이 필요한가?

오쿠 프로젝트를 시작할 때, 로그인을 도입하느냐 마느냐에 대한 이야기가 나왔다.

로그인 기능이 없다면, 클라이언트에서 보내는 요청에 대해 유저를 식별할 수 없다. 

(HTTP는 한번 요청과 응답을 받고나면 그 연결이 지속되지않고 끊기기 때문에)

만약 유저를 식별할 수 없다면, 오쿠 내에서 누가 입찰하였는지 정보를 식별할 수 없고,

그로인해 구매자와 판매자를 이어주려는 서비스 자체가 불가능 할 것이라고 생각했다.

---

JWT, 쿠키-세션 로그인

JWT 로그인 방식을 채택했다. 다 장단점이 있지만 쿠키세션로그인은 쿠키 허용안하면 못쓰는거아닌가..

---

리프레시 토큰이 필요한가?

리프레시토큰

리프레시 토큰은, JWT로그인 방식에 사용되는 JWT의 보안상의 단점을 보완하기 위해 구현한다.

사용자가 로그인하여 리소스에 접근할 수 있는 토큰을 액세스 토큰이라 한다.

액세스 토큰을 어떻게하던지 탈취하면( 클라이언트 상에 노출되어있으므로 비교적 탈취가 쉽다고한다. ) 

해커는 로그인 한 유저처럼 리소스에 접근할 수 있다. 

그래서 로그인으로 발급한 액세스 토큰의 유효기간을 짧게하여 공격받을 면적을 줄이는것으로 보안성을 높인다.

 

이러한 단점을 보완하고자 고안된 것이 리프레시 토큰이다. 

리프레시 토큰이 사용되는 방식은,

1. 액세스 토큰과 리프레시 토큰의 발급

2. 액세스 토큰에 짧은 만료 주기 설정 (30분~ 등의 짧은 시간)

3. 리프레시 토큰으로 액세스 토큰을 재발급

4. 기존의 액세스 토큰은 폐기

---

그래서 필요한건가?

결론적으로는 나의 보안 지식 한에서는 필요하다.

한계가 명확하지만 내가 할 수 있는 선에서, 유저의 불편함을 최소화하면서 피해를 줄일 수 있는 방법인 것 같다.

그렇지만 한계가 명확한 만큼 이미 어떤 대안이 나왔을거라고 생각한다. 다만 내가 모를뿐 ㅠㅠ

---

리프레시 토큰도 토큰이고, 기존 액세스 토큰과 함께 발급이 된다면,

리프레시 토큰이 탈취당했을 때는 더 큰 문제이다.

액세스토큰이 아무리 재발급된다 한들, 리프레시토큰을 탈취해서 사용자인 척 액세스토큰을 재발급 받을 수 있기 때문이다.

 

그러면 리프레시 토큰의 의의가 어디에 있는거지? 라는 고민이 계속돼서,

글을 좀 읽어봤다.

 

https://stackoverflow.com/questions/3487991/why-does-oauth-v2-have-both-access-and-refresh-tokens

Why Does OAuth v2 Have Both Access and Refresh Tokens?

https://mailarchive.ietf.org/arch/msg/oauth/vSmJ0zjQzZFjeFbRz_qpvjfpAeU/

Archive

---

위의 글에서 설명하는 리프레시 토큰의 의의는

 

1. 액세스토큰에 대한 공격의 범위를 줄여준다.

2. 리프레시토큰은 서버에 저장되기 때문에 조금 더 안전하다?

 

1번은 납득이 되어버렸다. 시간 상 10분동안 터는것과 하루종일 털 수 있는건 다를 것 같다. 서비스의 규모적인 면에서 같을수도있겠지만.

 

2번은 리프레시토큰도 결국은 클라이언트에게 넘겨줘야하는 값이기 때문에

서버에 저장한다고해서 엄청나게 더 안전해지는 것 같지는 않고.

해킹은 보통 네트워크단에서 이루어지기 때문에 충분히 의의가 있다..!

서버에서 발급한 리프레시토큰을 임의적으로 삭제해서 재발급시켜줄 수는 있을 것 같다.

 

추가적인내용

 

오늘 모의면접에서 마침..!! 좋은 이야기를 들을 수 있었다. 감사합니다... 돈과명예길만 걸으세요..

JWT토큰의 탈취는 보통 클라이언트측에서 이루어지는것이 아니라고한다.

클라이언트의 PC가 해킹되었다면 서버에서 더이상 할 수 있는 일은 없으며,

보통은 공유기 등의 네트워크쪽에서 탈취되기 때문에 리프레시토큰이 의의있다고 하셨다.

---

JWT로그인의 한계

그래서 내린 결론은, JWT로그인에도 분명한 한계점이 존재한다는것이다.

 

리프레시토큰을 도입해서 액세스토큰의 공격범위를 줄인다고해도, 리프레시토큰마저 탈취당하면 도로묵이고.

그래서 JWT로그인을 도입할 때는 이 한계점이 명확하다는것을 유의해서 작업해야 할 것 같다.

 

또다른 큰 단점은, 

임의적으로 생성된 JWT를 서버에서 임의적으로 삭제할 수 없다는 점이다. 

사실 이 점이 더 큰 단점이라고한다.

 

만약 리프레시토큰이 탈취당한다면 어떤 액션을 취해야할지? 같은것들.

아니면 클라이언트측이 갖고있는 토큰을 아예 탈취도 못하도록 보안에 더 신경쓰거나.

아니면 탈취당했더라도 금새 리프레시토큰을 재발급할 수 있게 한다거나?

아무리 생각해봐도 뭐라도 하나 털린순간 피해를 당하긴 하는데,

얼마나 줄이냐의 문제같다.