jwt에서 refresh token deprecated 시킵니다

[헬마스터(supersaver)]

프로그래밍 갤러리 위원장의 권한으로 deprecated 시켰습니다.

- 국민의 명령이다.

[멍청한유라ㅋ(repair25)]

@deprecated를 넣으면 어떻게되나요? - dc App

[헬마스터(supersaver)]

호출하거나 사용할때 경고메시지가 계속 떠서 귀찮아질겁니다

[멍청한유라ㅋ(repair25)]

오모시로이네 - dc App

[명탐정유명한(211.234)]

deprecated=계속 사용가능

[헬마스터(supersaver)]

[노럐(adbanner)]

그럼 지금 로그인 한 놈 중에 하나가 해킹 의심되는데 배포 없이 쫓아내고 싶을 때 어떡하나요

[헬마스터(supersaver)]

해당 리프래시 토큰을 블랙리스트에 넣고 인증통과해주지 맙시다

[노럐(adbanner)]

블랙리스트를 메모리에 유지하려면 배포가 필요하고 디비나 레디스 같은 별도의 저장소에 보관하려면 req 마다 req에 있는 토큰이 블록된 놈인지 아닌지 알기 위해 해당 보관소쪽에 콜을 해야 해서 stateless 하다는 jwt의 장점이 사라짐

[헬마스터(supersaver)]

그것은 access token이 탈취당했을 경우에도 마찬가지일것 같아요 성능저하가 발생한다면 그것은 jwt의 일반적인 매커니즘과 동일한 수준으로 보이는군요

[노럐(adbanner)]

리프래시 토큰 자체가 stateless 성에 위반되는 것은 사실임. 하지만 인증이 필요한 req 마다 디비(혹은 레디스)콜을 하는 것과 액세스 토큰의 만료시간 마다 한번씩 하는 것에는 큰 차이가 있음. 액세스 토큰의 유효시간 내에는 방법이 없다는 점이 있긴 하지만. 머 사실 애초에 이렇게 복잡하게 쓰느니 그냥 세션 방식으로 하는 게 낫다는 것 자체는 나도 동의함. 애초에 그렇게 까지 stateless 성에 목메달 정도로 콜이 많은 서비스 자체가 드물기도 하고

[프갤러 1(172.226)]

넌 니가 말한 req가 필요한 call에 대해 깊게 생각 해 본적이 있냐?

[프갤러 1(172.226)]

니가 말한 인증이 필요한 req은 그냥 시간이 지나서 만료되었다는것과 차이가 없는 말이고, 심지어 refresh token black list를 운용한다면 어차피 db나 redis는 매번 가야함

[프갤러 1(172.226)]

뭔 생각으로 req마다 콜하는것과 access token의 만료시간마다 call 하는게 큰 차이가 있다고 말하는지 모르겠네

[헬마스터(supersaver)]

아무튼 좋은의견 감사합니다. 많은 도움이 되었어요

[노럐(adbanner)]

jwt 이야기하면 꼭 이런 친구들이 달라붙네. 그냥 말을 말아야지

[프갤러 1(172.226)]

그리고 '액세스 토큰의 유효시간 내에는 방법이 없다는 점이 있긴 하지만.' 이 부분은 정말 웹 땔깜들이 보안을 얼마나 개 병신같이 생각하는지 알 수 있는 대목이다. 이거 하나만으로도 매 요청마다 db를 들러야 하는 충분한 이유가 되는데

[프갤러 1(172.226)]

결국 니가 말하고자 하는 jwt 운용 방법은 뭔데 그럼?

[노럐(adbanner)]

stateless 성을 잃지 않고서는, 그리고 그걸 희생한다면 jwt를 쓰는 의미가 전혀 없어지니까는,,...이라는 말이다... 진짜 jwt 이야기하면 저능아들 달라붙는 거 소름돋네 진짜로....진짜 개장애인인가 ....

[프갤러 1(172.226)]

아니 그래서 니가 말한 '그럼 지금 로그인 한 놈 중에 하나가 해킹 의심되는데 배포 없이 쫓아내고 싶을 때 어떡하나요' 이 상황에서는 어떻게 운용할거냐고 ㅋㅋ 말이 어렵냐? 하긴 'stateless 성을 잃지 않고서는, 그리고 그걸 희생한다면 jwt를 쓰는 의미가 전혀 없어지니까는,,...이라는 말이다...' 이렇게 글 쓰는 꼬라지부터 한국말 못하는 어디 웹 땔깜 같긴한데

[프갤러 1(172.226)]

애초에 요즘 시대에 왜 was의 stateless성을 추구하는지나 알고 하는 말이냐? 진짜 아오 ㅋㅋ