[질문] 프론트에서는 세션쓰고 백엔드에서는 jwt 쓰면 되지않음?

[익명(223.38)]

jwt를 쓸때의 단점은 토큰 탈취에 대응하자니 스테이트풀하게 될 수 밖에 없다는 것으로 이해했음(중복 로그인 방지 기능 등)

그러면 그냥 백엔드에서는 jwt로 인증처리하고 프론트엔드 서버에서는 백엔드 인증서버에서 반환해주는 access token이랑 refresh token을 세션에 저장하면 안됨?

이렇게 하면 access token이랑 refresh token을 탈취당할 우려도 줄어들뿐더러 중복 로그인 방지도 구현하기 쉬워지잖음.

백엔드와 프론트엔드 서버간에는 stateless하게 두고
클라이언트와 프론트엔드 서버간에는 stateful하게 두면 어떨까 생각해봤음

물론 그냥 세션만 써도 되는 상황에서는 위처럼 할 필요가 없겠지만 백엔드 서비스가 여러개로 분리되어 있는 상황을 가정했을때 위와 같이 하면 어떨까 해서 글을 써봤는데 의견 주면 감사하겠음

[돌머리(211.206)]

자기가 무슨 소리를 하는진 알고 이야기 하는것이더냐!

[익명(223.38)]

대략적으로는 알고 있다고 생각하지만 아닐수도 있어서 글씀

[익명(hheee)]

이런식으로 하면 굳이 리프레시 토큰 따로 안두고 액세스 토큰 유효기간을 길게 두거나 만료없이 써도 될듯

[익명(223.38)]

액세스토큰을 아예 외부에 노출시키지 않는 가정하에는 그렇게 써도 될 것 같긴함

[백갤러 1(27.35)]

프론트가 세션을 쓰는 순간부터 JWT 는 오버엔지니어링이 아닐까 ?

[익명(223.38)]

이럴거면 그냥 백단에서 레디스로 블랙리스트 관리하는것도 나쁘지 않아보이긴함

[김대기(waitkim)]

그 토큰이 다른 프론트를 통해 외부로 나갈 가능성은 없나?

[김대기(waitkim)]

토큰의 state를 이벤트로 전파하고, 사용처에서 그걸 복제해서 관리하는게 나을수도 있어보임 꼭 사용처마다 관리하지는 않더라도 적정 단위별로 캐시하면 충분히 감당할만함

[익명(223.38)]

토큰이 외부로 노출될 일은 없을거라 가정하고 쓴 글이었지만, api를 외부에 오픈해야할 가능성이 조금이라도 있다면 제가 쓴 방식은 한계점이 있을 것 같네요

[익명(223.38)]

댓글 달아주신건 한번 찾아서 공부해볼께요 이벤트로 전파하는것까진 아직 공부하진 못해서

[김대기(waitkim)]

ㅇㅇ 어차피 토큰의 state는 크기가 크지 않아서, 한 리전의 요청만으로도 초대규모를 이루지 않는 한, 적절히 나누는 것 만으로 충분히 대응이 가능할듯 우리나라 서비스중에 그런 서비스는 없을거고

[김대기(waitkim)]

이벤트 전파는 핵심이 아니고 토큰 state 저장소를 분산하는게 핵심임 이벤트 전파는 파이프라인

[김대기(waitkim)]

그럼에도 불구하고 여전히 가성비 나오는 일은 아님 완전히 오픈된 류의 인증 서비스라면 실시간 블랙리스트 같은걸 지원해줄 수 없어

[익명(223.38)]

그렇군요 도움이 많이 되었습니다 공부 더 해야겠음요