이번 해커톤 기간 동안 많은 시도를 해보았고, 그만큼 부족한 부분이 많다는 것을 깨달았다. 코드를 리팩토링 하고 구현하지 못했던 부분을 채워가면서 배웠던 내용을 정리하고자 한다.
로그인 방식에는 크게 두 가지가 있다.
• Session
• JWT
세션을 이용한 방식은 브라우저의 쿠키에 세션 id
를 발급하고, 매 요청마다 브라우저의 쿠키를 검증하여 세션 id
를 통해 사용자를 인증한다.
JWT
를 이용한 방법은 세션 방식과 유사하게 토큰을 활용한다.
이번 미니 해커톤 프로젝트에서는 JWT
방식을 활용하여 유저 계정을 관리해보았다.
JWT
는 Jason Web Token의 약자로, 인증에 필요한 데이터가 암호화 되어 있는 토큰을 말한다.
JWT
토큰은 Header, Payload, 그리고 Signature까지 세 가지 영역으로 나뉘는데, Header
에는 해쉬를 위해 사용되는 함수 정보가, Payload
에는 암호화 하고자 하는 정보가 저장되어 있다. 그리고 Signature
에는 헤더에 정의된 함수를 통해 암호화 된 정보가 들어있다. Signature
에 저장된 비밀 값은 오직 서버만 알고 있다. 그래서 유저 A
가 Payload
에 저장된 id
를 유저 B
의 id
로 바꾼 뒤 인코딩하여 서버로 보낸다 하더라도, Signature
의 정보는 유저 A
의 Payload
를 기반으로 암호화 되었기 때문에 서버는 이를 유효하지 않은 토큰으로 간주할 것이다.
이렇게 JWT
토큰으로 로그인을 하게 되면 사용자는 두 개의 토큰을 발급받는데, 하나는 Refresh Token
이고 다른 하나는 Access Token
이다. 당연하게도 이 둘의 역할은 다르다.
세션을 이용한 방식과 다르게 JWT
는 한번 발급하면 토큰을 다시 회수할 수가 없다. 그래서 역할이 다른 두 개의 토큰을 발급하는 것이다.
실질적으로 인증/인가를 위해 사용되는 것은 Access Token이다. access token
은 일정 시간이 지나면 만료되는데 refresh token
에 비해 수명이 짧다. access token
이 만료되면 refresh token
을 서버로 보내 새로운 access token
을 발급받는다. 결국 Refresh Token은 서명과 관계 없이 access token
의 재발행만을 위해 존재한다.
그렇다면 토큰은 어디에 저장해야 하는 것인가?
해당 블로그에 정리된 내용에 따르면
• refresh token
은 local Storage
에, access token
은 Cookie
에 저장한다.
• 요청 헤더에는 access token
을 넣는다.
• access token
이 만료되면 refresh token
을 가져와 새로운 토큰을 발급받는 요청을 한다.
위와 같다.
아직까지 refresh token
과 access token
을 별도로 제공받지는 못하고 있다. 그래서 백엔드를 담당한 팀원 분께서 코드를 수정하는 중이다.
나중에 토큰을 서버 측에서 refresh
와 access
를 정상적으로 발급할 수 있게 되면 소스 코드도 올려보도록 하겠다.
--
🙇♂️ https://hololo-kumo.tistory.com/236
🙇♂️ https://velog.io/@tsi0521/%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EB%B0%A9%EC%8B%9D%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90