[D+134] Final Project : 14일차 JWT(JSON Web Token)

 

 

D+134

-  Final Project : 14일차 -

( JWT 토큰 시작하기 )

 

---

 

 

오늘은 인증을 위해서 JWT 토큰을 생성하는 과정을 거쳤으며,

아직 코드를 100% 만족한 상태로 작성한 것은 아니라서 아직 구현하지 못한 코드라 눈앞에서 아른거린다.

 

일단 백엔드에서 가장 고민했던건 리프레시 토큰을 만들어주냐 아니냐에 대한 고민이 많았다.

 

나는 이전에 첫 프로젝트에서 JWT를 사용해 보기는 했지만

액세스 토큰 하나로만 토큰을 사용해보았기 때문에 리프레시를 어떻게 사용해야 하느지에 대해서는 조금 막막한 상태였다.

 

그리고 여러 검색을 해보니 리프레시는 반드시 필요한 것은 아니라는 것을 알게 되었고

아니면 액세스토큰 하나로 토큰을 갱신한다는 내용을 보고 

팀원분께 액세스토큰 하나로 진행해보는게 어떻겠냐라는 의견을 제시했었다.

 

그런데 팀원분께서는 이전 프로젝트때 세션을 활용해서 프로젝트를 진행하셨고,

이번에 처음으로 토큰을 사용을 하게 되었는데 이왕 하는거 정석대로 진행해보고 싶다는 말씀을 해주셨고

사실 나도 약간 리프레시 토큰을 막연히 회피한 것 같기도 한 느낌이 없지않아서

이번을 계기로 제대로 해보자는 결심을 하게 되었다.

 

 

일단 jwt 인증을 위해 미들웨어를 생성하기 전에 jwt를 생성해야 하기 때문에

로그인 API에 jwt를 require을 진행하였다.

 

그 이후에 jwt를 생성해 주는데 이때 액세스토큰과 리프레시 페이로드에 mongoose에서 자동생성되는 _id를 넣어주었다.

 

그리고 리프레시 토큰을 액세스보다 훨씬 길게 설정을 해주었으며,

이곳저곳을 검색해보니 리프레시 토큰 같은 경우에는 보안적으로나 보여주지 않는게 좋다고 해서

body로 넘겨주는 것 보다는 header가 좀 더 괜찮겠다 싶어서 res.set으로 리프레시 토큰을 넘겨주었다.

 

그리고 리프레시토큰을 헤더로 넘겨주기 전에 리프레시토큰을 데이터베이스에 넣어주었는데

이거에 대한건 팀원분이 알려주셨는데 만약에 액세스 토큰이 만료되어 클라이언트가 리프레시 토큰을 가져와서

액세스 토큰을 갱신하려고 할때 리프레시가 같은 것인지 DB에서 정보를 가져와 확인해야

보안적으로 좀 더 나은 방법이라고 하셔서 리프레시 토큰은 따로 DB에 저장을 해주었다.

 

그런 다음 요청을 이용하기 위해 미들웨어로 auth.js를 만들어서 해당 토큰이 서버에서 만든 토큰인지를 확인하는 과정을 거치면 된다.

 

그런데 아직 팀원분과 리프레시 토큰을 통해 갱신하고 어떻게 리프레시를 가져올 것인가에 대해서는

정확하게 결정한 것이 없기 때문에 프론트 분들이 테스트를 확인할 수 있을 정도로만 작성해서

액세스 토큰을 확인하고 넘어가는 정도로만 코드를 작성하였다.

 

일단은 이정도 까지로만 작성을 진행하고 카카오 소셜 로그인을 구현한 다음에

리프레시 토큰을 사용하는것에 대해서 좀 더 구체화 하기로 하였다.

 

 

---