JWT와 AccessToken 그리고 RefreshToken 전략까지

코딩테스트도 공부가 잘 안되어서 지금까지 했던 작업을 정리할 겸

 

 

JWT란?

JWT(Json Web Token)란 Json 포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 Web Toke

 

이라고 말을 해도 알아듣기는 뭐하니 더 현실적으로 쓰면 안에 정보가 저장된 Json인 토큰을 말한다.

 

토큰? MZ세대 혹은 이제 하얀머리걱정하실 나이 있는 분들이라면 이걸 기억하실텐데

 

Q: 개당 얼마일까요?

저걸 정류장 근처 가게에서 사서 요금대신 한개씩 넣었던 기억이 있을거다. JWT도 그러한 역할을한다. 대신 일정시간 동안 무한정 쓸수 있다는게 다를 뿐. 

 

 

JWT는 비밀키(env나 properties로 관리하겠지?)로 풀면 이러한 형태로 되어있다. 헤더에는 사용한 해쉬 알고리즘, 내용은 말그대로 내용, 서명에는 ID와 암호가 담겨있다. 

 

이 JWT를 어떻게 만들어야 하는건가?는 간단하다.

이미 누가만들어놓은 모듈을 쓰면 된다.다그렇게개발하는거아니겠습니까?하하핫

https://mvnrepository.com/artifact/io.jsonwebtoken/jjwt

 

즉 로그인을 할때 서버쪽에 세션을 남기는 형태가 아니라 암호화된 JWT AccessToken을 사용자에게 던져준다.

그리고 나서 다음부터는 이 토큰으로 서버에 접근할때 쓰는데,

그러면 서버는 토큰을 검증해서 사용자가 맞는지, 그리고 이 토큰의 유효기간이 안지났는지 체크를 한다. 

 

지나면? 다시 로그인 하라고 로그인 페이지를 넘겨주면 된다.

 

즉 기존의

1. 세션이 필요없게 되는 장점(이걸 전문용어로 Stateless한 서버라고 한다)

2. 아이디 암호로 로그인을 하지 않아서 생기는 보안강화라는 2가지 장점이 있다.

3. CSRF공격을 방어가능 (토큰이 예측할수 없게 만들어지니까 + 검증도 되고)

4. 부가적인데 MSA 방식으로 구현이 된다. 다른서버인데 로그인하려면 세션을 공유하는건 힘들지만 토큰은 비밀키만 같으면 되니까... 

 

하지만 1차적인 이 방식이 다면 쉬웠겠지만 여기에서

엑세스 토큰 죽으면 다시 로그인하는 과정 밟아야 하잔ㅇ아? jwt방식 노답.

 

그래서 RefreshToken이 등장한다.

 

RefreshToken

기존 로그인 형태는 같지만 RefreshToken의 역할은 간단하다. AccessToken이 만료되었다면 refreshToken으로 이 사용자가 내가 가진 정보와 일치하는지를 비교하고 나서 일치하면 AccessToken를 다시 재발급해준다. 

 

...여기서 이상한걸 발견했을 것이다. [내가 가진 정보와 일치]라는 점에서 

 

그러면 결국 서버에 있어야 한다는 거네? 정보가?

 

그렇다. 다시 원점이다.

하지만 이런 정보가 빈번하게 생성될수도 있기 때문에 등장하는 모듈이 in Memory기반 DB인 Redis이다. 

그렇다. 이것도 배워야 한다책도절판임^^

 

 

RefreshToken와 AccessToken 전략

 

결론부터 말하면 아예 정해진 룰은 없다. 정말로 그래도 정해진 룰이 있겠지.. 하면서 다 찾아봈는데

시간도, 발급도 다 기획 마음대로인것으로 판단된다. 

그정도로 자율성이 높다는건 좀만 잘못 만들었다가는 보안지옥을 볼수 있다는 것이다.

 

이런지옥 말고 

 

그래도 대체적으로 관습적으로 사용할법한 전략을 짜보면...

 

1. 로그인한다 [서버에서는 AT(이하 AT)과 RT(이하RT)을 뱉어낸다. (유효기간 AT: 1시간. RT는 2주)
그리고 RT을 Redis에 저장한다.(키: 이메일, value: RT)두 토큰을쿠키에 저장한다.]
2. 이후 로그인된 사람만 쓸수 있는 곳에 접근하려면 쿠키의 AT,RT를 Header에 넣어서 서버로 보낸다. [서버단에는 검증및 사용자 확인을 한다]
3. 로그인 및 로그인 사용자만 쓰는 곳에 접근했으나 AT의 유효기간이 지나버렸다. 우선 email만 뽑는다.
4. 뽑은 이메일로 redis에서 조회한다. 있으면 저장했던 RT가 나온다.
5. 일치하는지 보고 일치하면 사용자가 맞으니 email의 사용자로 AccessToken을 재발급해준다. 일치안하면 다른 사용자이니 내쫏아 버린다.

- 로그아웃 : Redis에 저장된 RT를 지운다. 쿠키상의 AT와 RT를 지운다.

 

...이런 형태이다. 

 

설명이 장황했지만 결국 핵심은 이거다.

1. 비밀키로 암호화된 JWT는 남이볼수 없다. 그래서 보안이 된다.

2. Stateless로 구현이 된다. 

3. JWT 구현에 정해진 룰은 없다. 관례는 있다.

 

이정도인듯하다.

 

예전에 이걸 수동으로도 구현해보고 자동으로도 구현해보니 여러 생각이든다.