https://github.com/do0ori/login-with-OAuth에 소셜 로그인 boilerplate를 작성 중이다.
이전 글에서 잠깐 이야기했듯 OAuth는 인증 및 초기 데이터 가져오기 용도로만 사용하고, 이후의 관리(로그아웃, 토큰 재발급, 회원탈퇴 등)는 내 서버에서 처리하도록 했다.
그래서 댕댕워크 프로젝트에서 OAuth 로그인을 구현한 방법과는 일부 다르다.
로그인 과정을 mermaid를 사용해 sequence diagram으로 그려보았다. README에서도 볼 수 있다.
확실히 backend에서 모든 OAuth 관련 환경 변수를 한번에 관리할 수 있어 redirect를 사용하는 이 방법이 깔끔한 것 같다. 하지만 redirect를 사용하기 때문에 발급한 jwt access 및 refresh token은 cookie에 담아 반환해야 한다.
backend/
└── src/
├── auth-google/
├── auth-kakao/
├── auth-naver/
├── auth/
│ ├── guards/
│ │ ├── auth.guard.ts
│ │ └── refresh.guard.ts
│ ├── interaces/
│ │ ├── auth-data.interface.ts
│ │ └── social-data.interface.ts
│ ├── strategies/
│ │ ├── auth.strategy.ts
│ │ └── refresh.strategy.ts
│ ├── types/
│ │ ├── auth-providers.type.ts
│ │ └── social-config.type.ts
│ ├── auth.controller.ts
│ ├── auth.module.ts
│ └── auth.service.ts
├── config/
├── helpers/
│ ├── cookie-setting.helper.ts
│ └── token-validation.helper.ts
├── token/
├── userToken/
├── users/
└── utils/
├── cookie-extractor.util.ts
├── ms.util.ts
└── validate-config.util.ts
주요 기능은 helper나 util, 또는 token과 같은 별도의 폴더로 분리해서 깔끔하게 코드를 작성하고자 했다.
Access token의 수명이 짧아 token 재발급 요청이 잦을 것이다. 그래서 Refresh token의 정보는 users에 같이 저장하지 않고 userToken에 따로 저장하도록 했다.
이렇게 하면 향후에 Redis와 같은 별도의 DB로 migration하기가 더 쉬워질 것이다.
참고로 token 재발급은 RTR(Refresh Token Rotation) 방식을 사용했다.
현재 provider 별 REST API 문서대로 소셜 로그인을 구현해둔 상태이다. passport-google-oauth20, passport-kakao, passport-naver와 같은 provider 별 passport는 이를 passport strategy 및 guard를 사용해 좀 더 쉽고 편하게 사용할 수 있도록 만들어 놓은 모듈이다. passport strategy도 이해했으니 다음에는 provider 별 passport를 사용해 볼 생각이다.