세션출신으로썬 JWT굴리기엔 대가리굴리기 빡세네
1. 로그인
accesstoken에 uuid,username , auth 인증상태 담아서 쿠키 전송
refresh uuid:username 저장
2 API 호출
ㄱ. 가드 - accessToken 검증
O 컨티뉴
X 쨜
ㄴ. 가드 - accessToken 이 만료되었는가?
O 만료되었으면 redis에서 accessToken의 username과 uuid 가져와서 refresh 새로 덮어쓴 후 refresh , access 재발급
X. 컨티뉴
ㄷ. 서비스 - 사용자가 인증정보가 바뀌엇는가 ?
O. accessToken 의 auth 변경 후 재발급
X. 컨티뉴
-------------여기까진 프론트에 auth상태 담아서 인증페이지때문에그런데 더 나은방법있음? ------------
ㄴ. 서비스 - 사용자가 인증된 상태인가 ? ( 인증정보 )
O. 컨티뉴
X . 쨜
일단은 IDPW 회원가입 먼저 시키고
로그인 후 본인 인증하는 순서임
이 상태에서 더 좋은방법있을까
redis refresh에 uuid는 중복로그인때문에 달아둔거
그냥 쌩 유저네임으로 키값쓰기엔 중복 덮어쓰기 발생할꺼같아서 넣어둠...
이렇게 쓰는거맞아?
O 만료되었으면 redis에서 accessToken의 username과 uuid 가져와서 refresh 새로 덮어쓴 후 refresh , access 재발급 이부분 어떻게 하려는거임? 이미 만료된 access token에서는 데이터 추출못하는데
accesstoken에 uuid,username , auth 담고 4개 모두 쿠키로 보냄
ignoreExpiration: true, 이거해놔서 만료된것도 봐지긴하네
만료된건 더 이상 작동하지 않게 하는게 좋을거같음 어차피 refresh token에 uuid 있잖음 access token 재발급할때 refresh token 검증은 하고있지?
refresh token이 탈취되는 시나리오도 생각해보셈 지금 구조로는 막을수가 없음
1차로 accessToken위변조 검증하고 2차로 만료된거면 accessToken안에 저장했던거 들고오고 3차로 uuid랑 username redis에 저장된 uuid 비교해서 refreshToken 쓰는건데 <-- -이게 좀 이상하긴한데 생각해보니 굳이 uuid 쓸필요가없구나
아 refreshToken 검증 안하고있엇네..
refresh token의 uuid는 중복로그인 막기 위해 넣었다고했는데 재발급시 refresh token 검증과정에서 체크하고 막으려고 한거임?
ㄴㄴ 착각했음 중복로그인 허용할려고 했는데 생각해보니 refresh Token 다 각자 다르게 생성되니 uuid는 사실상 의미가없긴함
그러면 레디스에 refresh token 관련해서 키 밸류 어떻게 저장할거야?
ㅅㅂ uuid필요하네ㅋㅋㅋㅋㅋㅋㅋㅋㅋ
대충만들고 다만들엇다해. 어차피 안뚫려 해커도 관심없어함
복숭아
포폴수준에서는 refreshtoken 탈취 시나리오는 걍 생각 안하는게 좋을껄 ㅋㅋ 걍이런게 있다하고 넘어가셈
그럴거면 사실 refresh token을 굳이 만들 필요도 없지않음?
refresh token 쓰는이유가 access toekn 만료기간 짧게설정하고 만료될떄마다 refresh token보고 갱신해주기 위함이잖아 그래서 만약 중간에 누가 가로챘을떄 특정시점에서는 access token 만 탈취할 가능성이 크니까 있는 것만으로도 일단 의의가 있긴함
근데 위 시나리오에서는 refreshToken이 탈취 당할 수가없음. refresh Token은 Redis에 보관중이고 처음 로그인했을 uuid 대조해서 꺼내오는거라 accessToken이 만료된걸 탈취당해도 uuid 매칭이 안되면 refreshToken은 어차피 redis에서 못꺼내옴
또 만약 만료된 토큰 재발급해주면 refresh도 같이 재갱신하는거라 문제는없어보임
권한 안넣고 걍 매번 체크하면 안되나
프론트 ui ux 처리를 못하게됨ㅠ