[JWT] 액세스 토큰과 리프레시 토큰
저번 글에서는 세션 기반 인증 VS 토큰 기반 인증에 대해서 알아보았는데
이제 토큰 기반 인증 기술인 JWT 에 대해서 한 발짝 더 다가가보겠습니다.
토큰이 하나만 있는 것이 아닙니다.
서버가 토큰의 유효성을 계속 검사하려면 무슨 요청이 올 때마다 혹은 토큰 만료 시간마다 클라이언트는 계속 로그인을 해야해야 합니다.
그러면 이 사용자는 정말정말정말 귀찮겠죠 뭐 할 때마다 로그인하라고 하면 그 서비스는 분명 언젠가는 죽을 거에용
그것을 보완하기 위한 방법이 리프레시 토큰입니다.
서버측에서 클라이언트가 로그인하면 액세스 토큰과 리프레시 토큰 총 2개 줍니다.
액세스 토큰 만료 시간을 5분이라고 두고 리프레시 토큰 만료 시간이 1년이라고 치면,
액세스 토큰이 만료되어도 리프레시 토큰이 인증을 해주어 서버가 이를 인식하면 액세스 토큰을 다시 발급해줍니다.
* 아래 사진은 스프링 부트 백엔드 개발자 되기 책을 참고하였습니다.
뭐.. 저도 굉장히 이해하기 굉장히 어렵지만 쨋든 사용자 입장에서는 액세스 토큰 만료시간이 5분마다 재로그인을 할 필요없으니
어찌저찌나 좋다!
물론 기일게 만료시간을 설정한 리프레시 토큰 1년이 지나면 쩔수없이 다시 로그인을 해야한다!
쨋든 보안적으로나 사용자입장으로나 정말 좋네요!
이 리프레시토큰은 http Only 를 이용하기 때문에 탈취 가능성은 굉장히 낮은데 이에 대한 대응책도 있다고 해요
JWT 이후에 OAuth 를 배우는데 Refresh Access Token Rotation 이라고 하는데, 이것도 액세스 토큰처럼 리프레시 토큰을 계속 새로 발급해 주는 것이라고 합니다... 역시역시 보안을 적용하기 위해서는 New + Repeat 가 정석인 것 같습니다
* 자세하기 알기 위해서는
🧐 Access Token과 Refresh Token이란 무엇이고 왜 필요할까?
JWT 토큰은 유저의 신원이나 권한을 결정하는 정보를 담고 있는 데이터 조각이다. JWT 토큰은 비밀키로 암호화되어 있기에 비교적 안전하다. 그런데 탈취 당했을 때가 문제다!! 어떻게 위험을 최
velog.io
*JWT 사이트를 통해 디코드, 헤더 정보 보기*
JWT.IO
JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.
jwt.io
위 보시는 사이트가 인코드, 디코드하는 방식입니다!!
alg = 알고리즘은 해시256방식을 사용하고 Type 은 JWT 입니다.
그리고 아주아주 중요한 ... 제가 저것때문에 굳이 가져왔는데요 바로 your-256-bit-secret 입니다.
저게 시크릿키인데 만약 스프링부트를 사용하고 계시다면 아마 application.yml 파일에 jwt 에 seceret-key 를 등록하실 겁니다.
저게 유출되면 안되겠죠?? (오픈소스 nono!! )
그리고 강의 따라서 시크릿키를 단순하게 작성한다면 털릴 가능성도 있습니다.