"복습, 그리고 복습"
Intro
Section 3 의 인증/보안 파트에서 쿠키와 세션, 토큰, 그리고 Oauth 를 배웠습니다. 프로젝트에서는 jwt(jsonwebtoken) 을 통한 토큰 기반의 인증을 진행하기로 했는데요.
토큰 관련해서 분명 블로깅을 했었는데도, 막상 실제로 이를 구현하는 일은 완전히 다른 느낌입니다. 다행인 건 늘 그렇듯 부딪히면서 하나 둘 익혀나갈 수 있다는 점이겠죠.
토큰 기반 인증 흐름도
토큰에 대해서는 예전에 간단히 정리한 적이 있으니 이번에는 토큰 기반 인증의 흐름이 어떻게 구성되는지를 적어보려고 합니다. (따라가는 것만으로도 힘들어서 흐름까지는 적지 않았던 기억이 나네요.)
➜ 클라이언트는 사용자 정보 (ID, PW) 를 서버에 전달합니다.
➜ 서버는 전달받은 사용자 정보를 데이터베이스와 비교해 검증합니다.
➜ 검증이 완료되면 서버는 토큰을 발행합니다.
➜ 서버는 발행된 토큰을 클라이언트로 전달합니다.
➜ 클라이언트는 발급받은 토큰을 서버로 보내 인증을 진행합니다.
➜ 서버는 토큰으로 사용자를 검증합니다.
➜ 검증이 완료되면 서버는 클라이언트의 요구에 응답합니다.
아이디와 패스워드를 보내 바로 원하는 정보를 받는 것과 달리, 토큰 기반의 인증에서는 토큰을 발급받아 인증을 진행하는 과정이 추가됩니다.
과정이 추가되는 만큼 복잡해지지만, 토큰은 암호화되어 있기 때문에 상대적으로 높은 보안을 유지할 수 있습니다. 또한 관련 정보를 서버에 보관하는 세션 방식과 달리 클라이언트에서 토큰을 보관하기 때문에 상대적으로 서버의 부하가 줄어듭니다.
일반적으로 토큰은 Access Token 과 Refresh Token 으로 나뉩니다. Access Token 은 인증 과정에서 메인으로 사용되는 토큰이며 지속 시간이 짧습니다. Refresh Token 은 Access Token 의 유효기간이 만료될 경우 재발행받기 위해 사용되며, 상대적으로 더 긴 지속시간을 갖습니다.
개발을 진행하면서 왜 번거롭게 지속시간이 긴 토큰을 하나 더 발행해서 전달하는지 의문이 들었는데요. 관련해서 검색해보니 Access Token 은 리소스를 담당하는 서버와 데이터를 주고 받는 데 사용되는 것이고, Refresh Token 은 권한 인증 서버와 데이터를 주고 받는 데 사용된다고 합니다. 리소스를 주고 받는 것과 권한을 인증하는 것을 분리함으로써 보안을 강화하는 것이죠. 참고자료
개발 과정
처음에는 Access Token 이 만료된 경우 바로 Refresh Token 을 확인하는 방식으로 코드를 짜고 있었습니다. 코드가 조금 복잡해지긴 하지만 상대적으로 클라이언트와 서버 간의 요청 횟수가 줄어드니 이득이 아닐까 생각했었죠.
불가능한 것은 아니지만 결국 방향성의 문제라는 생각이 들었습니다. 그렇게 해서는 토큰을 쓸 이유가 없겠죠. 그래서 클라이언트와 서버 간의 요청 횟수를 늘리더라도 보안을 강화하는 원래의 목적을 유지하는 편이 낫겠다고 판단해 Access Token 이 만료된 경우 만료되었음을 알리는 방향으로 다시 작성하게 되었습니다.
이제 대망의 소셜 로그인 구현이 남았는데, 어떻게 시작해야 할지 막막하네요. 처음으로 코드스테이츠에서 제공받은 레퍼런스 없이 도전하는 과제가 아닐까 싶은데요. 늘 막막한 마음으로 시작하지만, 하나 둘 풀어가는 재미가 있는 듯 합니다.
SR 과정에서는 막막해보였던 과정들이 하나 둘 해결되는 것을 보니 신기하기만 합니다. 다음에는 더 잘 할 수 있는 부분들이 보이기도 하구요. 이 과정들을 소중히 간직해서 First 를 잘 마치고 Final 까지도 잘 달려볼 수 있었으면 좋겠습니다.
