⚙️인증 vs 인가
인증이란?
유저가 누구인지 확인하는 절차. 회원가입하고 로그인하는 절차를 의미한다.
인가란?
인증 이후, 유저에 대한 권한을 허락하는 절차. 인증된 사용자가 특정 페이지, 특정 api 정보를 호출할 때 보내줘도 되는지 확인하는 과정을 의미한다.
💣접근 제한
접근 제한 은 server에서 하는 인가 와는 다르게 사용자가 누구인지 식별할 수는 없기 때문에 사용자마다 페이지를 구별해서 띄워줄 수는 없다. 하지만 JWT 토큰 인증 방식의 경우, refreshToken의 유무, accessToken의 유무, userId의 유무를 통해 사용자의 로그인 여부 확인할 수 있고 로그인 여부에 따라 페이지 접근 제한을 둘 수 있다.
예를들어 사용자가 로그인을 해야만 들어갈 수 있는 페이지를 요청한다면, 사용자의 로그인 여부를 확인하고, 만약 비로그인 사용자라면 해당 페이지를 보여주지 않고 로그인 페이지를 보여주는 식의 처리를 할 수 있다.
server에서 사용자에게 정보를 제공해도 되는지 확인 하는
인가과정이 있다면, client에서는 사용자에게 페이지접근 제한을 걸어줄 수 있다. 라우터 제한을 하기 위해 어떠한 요소를 사용하는 것이 이상적일까?
💡접근 제한 요소로 무엇을 사용할까?
userId(store)
사용자를 식별할 수 있는 userId를 store에 저장했다. userId의 유무에 따라 접근 제한을 걸 수 있지만, userId가 현재도 유효한 userId인지 확인이 불가능하다.
refreshToken(cookie)
refreshToken은 브라우저 저장소인 Cookie에 저장했다. refreshToken은 accessToken 만료 기간이 지난 직후 또는 새로고침 시 토큰을 재발급해줄 때 유효한 사용자인지 식별해주는 역할로 사용된다. 따라서 userId를 접근 제한 요소로 둘 때보다는 조금 더 보증된 사용자라고 할 수 있을 것이다. 하지만 Cookie는 새로고침 시 유지되기 때문에, 토큰 만료 기간을 정하지 않으면, api 요청을 보낼 때까지 유효한 토큰인지 알 수가 없다.
accessToken(API header)
accessToken은 보안적 이슈를 대비하기 위해 API header에 집어넣는데, API header는 store와 cookie와는 다르게 새로고침 시 지워진다. 따라서 token 재발급을 요청하는 주기가 store와 cookie보다 빠르다. 재발급을 요청하는 주기가 빠를수록 토큰이 유효한 토큰인지 서버에서 확인하는 주기가 빠르다는 것이므로 사용자가 더욱 보증되었다고 생각할 수 있을 것이다.
접근 제한의 요소에 대해 고민하면서 느낀 부분은 api 요청을 하고 server에서 유효한 토큰인지 확인하지 않으면 위에서 다룬 세 가지 모두 존재 유무로 인증된 사용자라고 확신하기에는 부족하다는 것이다. 그럼에도 api 요청 시 사용자 식별에 accessToken이 주로 쓰이고, 토큰 재발급 주기가 나머지 둘보다 빠르기 때문에 client에서도 accessToken을 접근 제한 요소로 두는 것이 이상적이다 생각한다.
참조
인증(Authentication)과 인가(Authorization)
[React.js] 라우터를 이용한 접근 제한 구현 (Access Control & Authentication)
🍪 프론트에서 안전하게 로그인 처리하기 (ft. React)
