인증과 React에서 구현(feat: Kakao 로그인)
Last updated
Last updated
모던 웹서비스에서 Token방식은 많이 사용되고 있다.
여러가지 이유가 소개되고 있지만 내가 Token방식을 선택한 이유는 아래와 같다.
Stateless 서버(서버에서 상태를 유지하지 않으므로) 서버에 부하를 줄일 수 있다.
OAuth 도입에 맞춰 하며 확장성이 용이하다
Token과 비교되는 방식으로 Session방식이 있다. 서버에서 상태를 저장하고 사용하는 방식을 취합니다.
주로 문제점으로는 세션, 서버 확장성(구조 변경), CORS가 고려되고 있습니다.
여기서 저는 Stateless에 초점을 맞춰 세션, **서버 확장성(구조 변경)**을 해결하고자 했습니다.
기본적으로 로그인 시 토큰을 생성하고 정보를 요청할 때마다 토큰을 검증하는 방식으로 인증이 됩니다.
이를 통해 서버는 로그인 여부를 저장하지 않고 Stateless하게 인증을 제공가능합니다.
토큰의 단점으로는 특정 악성유저를 세션과 다르게 막지 못한다는 것인데 해당 부분은 결국 저장소를 추가하는 설계로 해결해야할 것 같습니다.
장점으로는 Stateless, 확장성, 웹 표준 준수입니다.
accessToken(24시간)과 refreshToken(2주) 두 개의 토큰으로 관리
API 전달 시에는 accessToken는 header의 “Authorization”, refreshToken은 쿠키(httpOnly)
FE 저장 시에는 accessToken는 sessionStorage, refreshToken은 쿠키(secure httpOnly)
서버로 로그인 요청을 하면 서버에서 해당 유저 계정 확인 후 정상 동작하면 accessToken JSON payload, refreshToken을 쿠키에 저장해서 응답해준다.
accessToken 만료되었을 때(API 호출 중, 앱 다시 실행시켰을 때) 서버로 갱신 요청을 하면 refreshToken이 만료되지 않았다면 새로운 accessToken과 refreshToken으로 갱신시켜줍니다.
프론트 코드 예시
refreshToken과 accessToken을 삭제해주면 됩니다.(서버에서의 처리에 따라 서버에 요청)
인가코드를 받아 토큰을 발급받은 후 아래의 로직이 끝난 후 해당 토큰을 우리 서비스의 accessToken과 refreshToken으로 변환해주는 작업이 추가적으로 필요하다.
왜 쿠키에 저장?
상대적으로 XSS과 CSRF 취약점 공격에 안전할 수 있기 때문입니다.
XSS란?
스크립트 주입 공격(React는 jsx로 렌더링하기 전에 이스케이프된다)
CSRF란?
사이트간 위조 공격(Cookie의 경우 origin에서만 동작하므로 막을 수 있다)
쿠키의 secure, httpOnly 옵션이란?
secure는 https에서만 사용하도록 하는 옵션
httpOnly의 경우 javascript로 document.cookie를 조회하지 못하도록 막는 옵션