-
Notifications
You must be signed in to change notification settings - Fork 3
IKEYTAX 토큰 인증 전략
저희는 API보안을 강화하기 위하여 토큰 인증 방식을 사용하고 있습니다.
AccessToken은 데이터 요청마다 HTTP 통신을 하기 때문에 탈취 될 위험이 높습니다. 그래서 AccessToken만 사용하는 방식은 토큰이 탈취되어 악용될 위험이 높기 때문에 안전한 방법이 아닙니다.
AccessToken의 유효기간을 짧게 설정한다면, 토큰이 만료됐을 경우에 해당 토큰으로 API요청을 보낼 수 없게 됩니다.
하지만 유효기간이 짧다면 매번 사용자는 로그인을 다시 해야합니다. 이러한 문제를 방지하기 위해 RefreshToken을 사용할 수 있습니다. 요청이 만료됐을 경우 AccessToken 재발급 요청을 보내고 DB에 RefreshToken이 존재하고 RefreshToken이 유효할 경우 AccessToken을 재발급 해준다면 해당 토큰으로 다시 API 요청을 보낼 수 있습니다.
AccessToken과 RefreshToken을 모두 사용하는 것이 AccessToken만을 사용했을 때보다 더 안전합니다.
클라이언트에서 요청을 보낼 때 토큰이 유효하다면 요청 데이터를 보내주기 때문에 문제될 것이 없습니다.
하지만 토큰이 만료된 경우도 존재하기 때문에 만료됐을 경우에 다시 재발급 요청을 보내고 이전에 했던 요청을 다시보내는 과정을 처리 해줘야합니다.
저희는 API요청을 보냈을 때 토큰이 유효하다면 정상적인 데이터를 주고, 만료됐다면 재발급 과정과 이전 요청을 재요청하는 흐름을 자동화할 수 있으면 좋겠다는 생각이 들었습니다.
그래서 우리는 apollo hooks의 useQuery와 useMutation을 커스텀 훅
으로 만들어 토큰 재발급을 자동화할 수 있도록 만들었습니다.
🙆🏻♂️ 커스텀 훅을 이용한 토큰 재발급 과정이 궁금하시다면 여기❗️를 클릭해주세요. (저희의 기술 고민 흔적을 확인할 수 있습니다! 꼭 들어와주세요 😊)
세부정보는 사이드바를 이용해주세요👀 ➡️➡️
Daily Scrum
- 201116-scrum
- 201117-scrum
- 201118-scrum
- 201119-scrum
- 201120-scrum
- 201123-scrum
- 201124-scrum
- 201125-scrum
- 201126-scrum
- 201127-scrum
- 201130-scrum
- 201201-scrum
- 201202-scrum
- 201203-scrum
- 201204-scrum
- 201207-scrum
- 201208-scrum
- 201209-scrum
- 201210-scrum
- 201211-scrum
- 201214-scrum
- 201215-scrum
- 201216-scrum
- 201217-scrum