<aside> ❕ 모아모아 프로젝트에서 accessToken만을 사용한 인증 방식을 사용하고 있는데, 로그인 만료 시간을 설정하기 위해 refreshToken의 도입을 생각하고 있다. 이를 위해 이 두 토큰의 동작 방식을 공부해야 한다!
</aside>
사용자가 어플리케이션의 특정 동작을 수행하기 위해 필요한 정보를 갖고 있는 데이터 조각
여기서 특정 동작이란, 인증과 인가가 필요한 동작을 의미한다.
사용자가 로그인을 하면 서버는 accessToken을 발급하는데, 사용자가 어플리케이션과 상호작용을 할 때 이 accessToken을 이용해서 서버에 사용자 인증을 한다.
accessToken이 만료되었을 때 클라이언트 어플리케이션에서 사용자를 위한 accessToken을 다시 요청할 수도 있고, 대신에 서버가 refreshToken 또한 발급해서 자동으로 만료된 accessToken을 새로운 accessToken으로 대체할 수도 있다.
accessToken이 만료되었을 때 다시 ‘refresh’하는 용도로 사용하는 토큰
refreshToken을 사용하면 사용자가 다시 로그인할 필요 없이 새로운 accessToken을 받아 로그인을 연장할 수 있다.

SPA(Single Page Application), AS(Authorization Server), RS(Resource Server), At(Access Token), RT(Refresh Token) 현재 모아모아 서버는 AS와 RS가 같은 서버에 존재
refreshToken이 유효한 경우, 항상 새로운 accessToken을 받을 수 있기 때문에 보통 refreshToken의 수명은 매우 긴 편 → 탈취되지 않도록 주의해야 한다(refreshToken도 bearer 토큰이다)
수명이 긴 것 때문에 걱정이 된다면 아예 refreshToken을 사용하지 않고 accessToken만 사용하는 것도 방법이라고 한다(accessToken 수명은 일반적으로 짧으므로)
SPA에서 refreshToken을 안전하게 보관하기 어렵다고 한다..! PKCE 방식(Proof Key for Code Exchange; 이게 뭐야)을 사용하면 URI에 노출된 accessToken은 어느 정도 보안된다고 하는데, refreshToken은 아니라고 한다. SPA에서는 쉽게 refreshToken을 보호할 수 있는 방법이 없다..
그러면 SPA에선 refreshToken을 사용하면 안 되는 걸까?ㅠㅠ
<aside> ❗ 아니! 언제나 (쉽진 않아 보이는) 방법이 있다.
</aside>
조금 더 안전하게 refreshToken을 사용할 수 있는 방법이 있다고 한다.
→ 새 accessToken을 발급받기 위해 refreshToken으로 서버에 요청할 때마다 새로운 refreshToken이 반환되도록 하는 방법이다!