티스토리 뷰

항해99 부트캠프의 1주차가 지났다.

 

첫 협업을 거쳐가며 작은 규모의 팀 프로젝트에서는 어떻게 일을 분배할지,

어떻게 협업을 진행할 지에 대한 부분을 배웠다.

 

당연한 얘기지만 코드를 짜는 것도 배워가는 것이 많았다.

그 중에서도 이번주에 배운 것 중에 제일 큰 것은 쿠키와 토큰이었다. 

 

먼저 나는 JWT (JSON Web Token)를 사용했다.

말 그대로 JSON 객체를 사용하는 토큰이라고 볼 수 있었다.

 

그럼 우리는 왜 토큰을 이용할까?

그것은 안전한 API를 이용하기 위해!

 

토큰 기반 인증을 사용하면 내 서버에서만 시크릿 키를 통해 인코딩 / 디코딩을 거칠 수 있으니 보다 안전하게 이용이 가능하다고 이해했다.

 

더불어 여기서 stateless라는 개념도 추가로 알아보았다. 

토큰은 서버에 저장하지 않고, 클라이언트에 저장하는데 이러한 환경에서 사용자 데이터를 주고받는 것을 stateless라고 한다는 것을 알게 되었다.

이렇게 되면 인증 정보에 대한 별도의 저장소가 필요 없으니 서버에 대한 부하를 줄일 수 있게 되는 것이다.

 

물론 토큰의 단점도 있다.

토큰을 찍어보면 알지만 길이가 무척 길다. 이 또한 단점이 되는데, 왜냐하면 요청이 많아질수록 길이때문에 네트워크 부하가 심해지기 때문이다.

 

그리고 토큰 탈취 당하면 그냥 끝이다.

걍 자유이용권을 얻는 셈이니까.

 

그리고 payload 자체는 암호화 되지 않는다! 

코드를 짜면서 알게된 사실이기도 하다. 이건 장점이 되기도 한다.

토큰 자체에 사용자의 권한 정보나 서비스를 위한 정보를 포함시킬 수 있으니까.

다만!!! 여기서 내가 실수록 중요한 정보를 payload에 담아버리면 그냥 그대로 나가게 되는 것이다.

그렇기 때문에 유저의 중요 정보를 담지는 않았는지 꼭 확인해야된다.

 

또 다른 단점 하나 더!

특정 사용자의 접속을 강제로 만료시키기 어렵다는 것.

이미 expire 기간 등을 발급받은 토큰을 지닌 유저는 우리 웹사이트 / app 등의 자유이용권을 발급받은 셈이다.

다만 이 부분은 내가 어떤 사용자의 권한을 바꾸려는 시도를 본격적으로 진행하지 않아 체감하지 못하였다.

 

그러면!! 나는!!! 어떤 보안 전략을 취해야 할까???

 

이런 해결책이 있다고 생각한다.

1. 만료기간을 짧게 두면 되것지!

- 피해는 좀 줄일 수 있다는 거 ㅇㅋ. but 사용자가 귀찮을텐데?

-이것에 대한 대안으로 sliding session!! 
 이게 뭐냐면 서비스를 지속적으로 이용하는 클라이언트에게 자동으로 토큰 만료 기한을 늘려주는 방법이라고 한다.
이러면 위의 사용자가 귀찮은 문제를 해결해 주겠지

 

2.refresh token

access token과 그보다 만료기간이 긴 refresh token을 같이 내려주는 것! 그러면 refresh token을 이용해서 access token의 재발급을 요청하도록 하는 방법이다.

이건 내가 한 번 구현해 보면 좋을 것 같다.

 

 

알아볼 재밌는 거리가 생겼다.

이것저것 시도해 봐야지!

댓글