[일반] 실무에서 로그인 상태 유지하기 기능 구현하는데 재밌당

[익명(106.72)]

서비스 자체가 좀 특이해서 주기적으로 폴링으로 요청 날리는 여러 탭을 동시에 몇시간 내내 띄워놔야 하는 케이스가 있는데

액세스 토큰을 세션 스토리지에 저장하기 때문에 여러 탭에서 동시에 토큰 로태이션을 하는 경우에 로그아웃 안되게 하려면 어떻게 해야 하냐든가(broadcast channel api로 하나의 브라우저에선 하나의 갱신 api만 날리게 동기화를 하거나 아니면 localstorage를 이용해서 lock 걸어서 각 탭에서 순차적으로 로테이션 요청을 보내서 성공하게 만들거나)

아니면 일반적인 케이스로 

토큰 로테이션 할 때 경합으로 인해서 생기는 문제는 어떻게 해결할지 

리프레시 토큰 탈취 당할 때 어떻게 쉽게 revoke 당하는 구조를 만들지

등등 CS 지식 활용할 방면이 많아서 되게 재밌네

[익명(106.101)]

븅ㅡ신 ㅋㅋ 시덥지 않는 기능에 싸고 앉아있노;

[익명(106.72)]

나도 첨 기능 구현하라는 소리 들었을 때 시발 개 좆밥이노라고 생각했는데 생각보다 고려할만한 부분이 많아서 재밌긴 함. 되게 보안애 민감한 서비스라서 세세한 부분 신경 써야하는 부분도 있고

[익명(106.101)]

@글쓴 백갤러(106.72) 애초에 로그인 상태 유지하기 기능 <- 이 말 자체 부터가 ㅈㄴ 하찮게 느껴지는 부분인거 모르겠냐 로그인 상태 유지하기 기능 잘 만들어서 어따 써먹을건데 그게 돈이되냐 뭐가되냐 ㅋㅋㅋㅋ

[익명(106.72)]

유저들이 만들어달라는 요청이 많아서 만들게 된 거라 나는 만족함 유저 입장에서 좆도 안쓰는데 영업하려고 만든 기능보단 백배 보람있다고 생각(b2b는 사용자랑 구매자가 다른 경우가 많아서 은근 이런 경우 많음)

[익명(1.238)]

@글쓴 백갤러(106.72) 기업 입장에서 생각해보면 너같은놈 쓰기싫음 돈주기 아깝지 ㅇㅇ

[익명(106.72)]

알빠노 ㅋㅋ

[1일1행(apart1723)]

jwt 쓰는거면 그냥 refresh하면되는거 아님?

[익명(106.72)]

리프레쉬 토큰을 이용해서 짧은 주기로 로테이션을 하고 있는데(리프레쉬, 액세스 토큰 둘 다 갱신) 리프레쉬 토큰이 유효기간이 길다보니까 탈취되면 대참사가 되기 때문에 DB에다가 토큰 해쉬 저장 해두고 로테이션할 때마다 DB에 최신 상태의 토큰 해쉬를 저장해둠.

[익명(106.72)]

토큰 로테이션 때마다 db에 있는 리프레쉬 토큰의 해쉬와 클라이언트에서 보낸 토큰의 해쉬가 같으면 로테이션하고 아니면 db에 있는 리프레쉬 토큰 레코드를 삭제해사 재 로그인을 요구함. 해커가 리프레쉬 토큰을 탈취하고 로테이션을 하면 db에 새로운 저장되는데, 다시 유저가 로테이션을 하려 들면 db에 있는 토큰 해쉬와 일치하지 않게 되기 때문에

[익명(106.72)]

@글쓴 백갤러(106.72) 토큰이 탈취되었다고 판단해서 토큰을 무효화하는 가

[익명(106.72)]

이 탈취 감지 로직이 존나 골 때리는 게 보통 토큰 갱신 api을 따로둬서 프론트엔드에서 날리는데, 타이밍아 안맞아서 여러 탭에서 동시에 리퀘스트를 날릴 때 이 토큰 탈튀 감지 로직이 실행이 되는 경우가 종종 있음 ㅋㅋㅋ

[익명(106.72)]

해결하려면 락을 걸어서 순차적으로 갱신 api를 날리도록 보장하거나, 전체 브라우저 탭에서 하나의 갱신 api를 날리도록 해야되는데 브라우저의 탭은 기본적으로 프로세스이기 때문에 이걸 가능하게 하려면 특수한 방법이 필요함. (Local storage나 broadcadt channel api를 이용해서 락을 걸거나, service worker를 쓰거나)

[백갤러 1(104.28)]

근데 꼭 액세스토큰을 세션스토리지에 저장하는 이유가 있음?

[익명(219.98)]

원래 로그인 구현이 액세스 토큰을 세션 스토리지에 저장되어 있었음 쿠키에다가 httponly samesite 정책 박고 access token 넣은 구현으로 바꿀까 생각도 했는데, 솔직히 액세스 토큰 유효기간을 짧게 설정하면 보안적인 리스크 수준은 둘 다 차이는 별로 없는 거 같아서 세션 스토리지에 두는 걸 유지하기로 함

[백갤러 2(172.226)]

httponly cookie쓰는게 낫지안을까? 세션스토리지는 XSS 면역이 아니자나 글구 httponly cookie 쓰면 너가해결할려던문제도 걍 해결될걸로보이는대

[익명(106.72)]

이게 다른 서비스 프론트엔드를 통해서 우리 서비스 api 요청하는 경우까지 상정하고 있어서 Cookie를 쓰면 보안적인 대책을 새우는 게 상당히 제한적으로 변함 다른 도메인이어도 보낼 수 있어야 돼서 XSS 리스크가 생기는 건 세션 스토리지랑 똑같아짐..

[익명(106.72)]

액세스 토큰은 매 요쳥마다 http의 Au1thorization 헤더에 넣어서 날리는 게 표준인데 Httponly를 박아버리면 프론트엔드에서 액게스 토큰에 접근할 방법이 없어져서 이 방식을 못씀 세션 스토리지는 XSS 때문에 안좋다는 인식이 있긴하지만 탭 간의 공유가 안되고 탭을 지우면 휘발돼서 의외로 탈취될 리스크는 적은듯

[익명(106.72)]

그리고 사파리는 기본 정책으로 서드파티 쿠키를 막고 있어서 아예 외부에서 못쓰게 됨