한강 프로젝트 1. 자동 로그인!!

목차

한강 프로젝트 0. 첫 끗발이 개 끗발이다 (설계)

한강 프로젝트 1. 자동 로그인!! (Auth 페이지 - 로그인, 회원가입, 아이디, 비밀번호 찾기)

한강 프로젝트 2. Canvas API 를 사용한 시간표 만들기 (시간표 페이지)

한강 프로젝트 3. (강의평 페이지)

한강 프로젝트 4. (강의자료 페이지)

한강 프로젝트 5. (강의자료 상세 페이지)

한강 프로젝트 6. (강의평 상세 페이지)

한강 프로젝트 7. (메인 페이지)

한강 프로젝트 8. (배포)

한강 프로젝트 9. (회고)

한강 프로젝트 10. (분석) - Google Analytics를 이용한 웹 로그 분석

---

잘못된 정보를 기술한 부분이 있다면 댓글이나 jong951005@gmail.com 으로 지적해주시면 감사하겠습니다!!

 

 

안녕하세요 :) 한 주마다 한강 프로젝트를 회고하며 글을 쓰고있습니다.

 

이번 주는 인증 관련 페이지 (로그인, 회원가입, 아이디, 비밀번호 찾기)를 구현하며 고민을 많이 했던 자동 로그인에 대해 적어보려고 합니다.

왼쪽 상단부터 시계 방향으로 로그인, 회원가입 전 인증, 회원가입, 비밀번호 변경, 비밀번호 변경 전 인증 페이지입니다.

 

---

 

토큰은 어디에 저장해야 할까?

한강 프로젝트는 인증 방식으로 토큰을 사용합니다. 유저가 id, password로 로그인 요청을 하면 백엔드에서 access, refresh token을 발급해주고 인증을 요하는 모든 요청들에 access token 을 붙여줘야 합니다. 

한강 프로젝트는 자동 로그인을 지원하기 때문에, 발급받은 토큰을 어딘가 보관해야 합니다. 사용자는 추후에 페이지에 다시 방문해도 보관했던 토큰으로 인가가 필요한 모든 요청을 할 수 있습니다.

 

관건은 해당 토큰을 어디에다 보관해야 하느냐에 대한 것입니다.

브라우저에서는 정보를 저장할 수 있는 방법으로 쿠키, 세션, 로컬 스토리지, indexedDB가 있습니다. 세션 스토리지는 브라우저 종료 시 초기화되므로 목록에서 제거하였고, indexedDB는 IE에서 지원이 미흡하므로 배제하였습니다.

 

쿠키와 로컬 스토리지 중, 다음 글을 참고하여 localStorage를 사용하기로 하였습니다.

현 API는 header에 토큰을 붙여서 요청하는 방식으로 설계되어 있는데, 쿠키를 사용하게 되면 이를 위한 설정을 백엔드 팀에게 요구해야 하므로 더 작업 기간이 길어진다고 생각했습니다.

 

---

인증 절차

Auth 프로세스 절차입니다.

 

토큰 인증과 관련된 모든 요청 및 절차를 도식화하였습니다. 케이스는 크게 메인 페이지 접근, 로그인 페이지 접근 두 가지로 나뉩니다.

 

---

 

로그인 성공

자동 로그인에 체크를 한다면 localStorage의 autoLogin 키 값이 true가 됩니다.

 

사용자가 처음 회원가입을 하고 로그인에 성공한다면 두 가지 작업을 합니다.

 

1. localStorage에 response로 받은 token을 저장합니다.

2. redux store에 로그인 여부를 알 수 있는 상태 값인 isLoggedIn을 true로 변경해주고,
사용자가 토큰 체크를 했는지 알 수 있는 상태값인 isCheckedToken을 true로 변경합니다.

3. 메인 페이지로 이동합니다.

 

---

 

메인 페이지 접근

메인 페이지 마운트 시 실행되는 함수

 

메인 페이지에 마운트 되면 token 체크를 했는지 확인합니다.

만약 로그인 한 사용자라면 isCheckedToken이 true이므로 pass하지만, 바로 메인 페이지에 접근하는 경우는 token을 체크합니다.

이후 사용자가 브라우저를 종료할 때, 자동 로그인을 체크하지 않았다면 localStorage에서 token을 제거합니다.

 

 

클라이언트의 localStorage에 이전에 받은 토큰이 있는지 확인합니다. 

만약 토큰이 없다면 succeedTokenCheck 함수를 dispatch 합니다. 해당 액션 함수에서 사용자는 로그인에 실패하였으므로 isLoggedIn 값을 false로 하지만, token 체크는 하였으므로 isCheckToken값은 true로 변경해줍니다.

만약 토큰이 있다면 access token이 유효한지 검사합니다.

 

 

백엔드에게 사용자의 access token이 유효한지 검증 요청을 합니다.

해당 토큰이 유효하다면 로그인에 성공하고, isCheckedToken은 true가 됩니다. 

그렇지 않다면, 에러 코드에 따라 다른 처리를 합니다.

만약 비인가된 토큰으로 요청한 경우라면, 심각한 에러라고 판단하여 슬랙에 알림이 갑니다.

만약 access token이 만료가 된 케이스라면, refresh token으로 access token refresh 시도를 합니다.

 

 

백엔드에게 refresh token 으로 access token refresh 요청을 합니다.

만약 성공한다면, local storage에 있는 토큰을 갱신시켜주고 isLoggedIn, isCheckedToken을 true로 변경합니다.

그렇지 않다면, 토큰 만료 알림과 함께 login 페이지로 라우팅합니다.

 

---

 

마무리

지금까지 자동 로그인 구현을 어떻게 하였는지 주절주절 적어봤습니다. 

cookie, localStorage에 대한 고민은 아직도 갖고 있습니다. 만약 OpenAPI 처럼 백엔드 코드 수정 요청을 할 수 없는 상황이라면 어쩔 수 없이 localStorage를 사용하겠지만 현 프로젝트는 그렇지 않기에 추후에 필수 기능들이 모두 구현 된다면 다른 개발진들과 회의를 해봐야 한다고 생각합니다. XSS 공격은 프론트엔드 개발자라면 무덤까지 가지고 가야 할 문제인 것 같습니다.