jwt는 너무 단순한 스펙이야
오로지 무상태성을 기반으로 한 무의존 말고는 다른 가치가 없음
그걸 기반으로 성능적 확장성과 도구적 확장성을 노려볼 수 있는데, 서비스에서 뭘 필요로 하느냐에 따라 싸는 이유가 다르지
도구적 확장성의 예시는 oauth2.0를 통해 로그인 방식의 다양화를 꾀하는거지, 이건 jwt 자체적인 장점은 아니고 무의존이라는 특성을 응용한거임
로그인 자체는 oauth2.0을 통하지만, 이후 식별은 세션을 통할수도 있음. 이러면 실시간성까지 얻을 수 있지. 대신 성능적 확장성은 잃어버리지만
김대기(waitkim)2024-07-06 12:56
답글
오.. 혹시 그럼 JWT랑 세션 차이점 설명해라 같은건 jwt는 stateless에 따른 성능적, 도구적 확장성이 있고 세션은 실시간성은 있지만 도구작 확장성은 없다
라고 대답하면 되나?
백갤러 1(172.225)2024-07-06 13:00
답글
성능적 확장성은 단순하지. oauth2.0을 쓰든 뭘 쓰든간에 로그인을 통해 토큰을 발급받고, 토큰 유효성 검증을 최소화 해서 부하를 줄이는거야
거기다가 리프레시토큰이니 블랙리스트니 더하더라도 세션방식만큼의 실시간성은 얻어낼 수 없어. 얻어내선 안되기도하고
아래 애들이 말한 GCP의 oauth2.0의 토큰 즉시 만료 기능에도 3분간은 만료되지 않는다는 설명이 있어
김대기(waitkim)2024-07-06 13:00
답글
아 세션은 성능적 확장성이 없다 ㅇㅇ
백갤러 1(172.225)2024-07-06 13:00
답글
두개 차이점을 설명하라면 단순하게 그렇게 말하면 되겠지만, 나라면 더 나아가서 이런 차이점보다 중요한게 뭔지를 설명할듯
김대기(waitkim)2024-07-06 13:01
답글
오 혹시 그 포인트가 뭡니까?? 밑에 글들도 그렇고 블로그갈들고 그렇고 못믿겠습니다
백갤러 1(172.225)2024-07-06 13:02
답글
oauth2.0과 세션의 조합도 한가지 입장에서만 생각하면 안되는게, oauth2.0을 제공하는 서비스와 그걸 사용해서 세션을 쓰는 서비스는 각각 입장이 달라
oauth2.0을 제공하는 서비스는 성능적 확장성까지 생각을 해야하지. 왜냐면 자기네 서비스를 사용하는 다른 고객 서비스는 이론적으로 무한히 늘어날 수 있으니까
이런 고객 서비스들이 토큰 유효성 검사 같은걸 계속 요청한다고 생각해봐, 얼마나 늘어날지 예측할수가 없지
그에 반해 고객 서비스는 주인 서비스의 도구적 확장성만 생각하면 되지, 연동하는 주인 서비스들이 oauth2.0을 제공하는지 말야
그들이 얼마나 많은 고객을 취급할지는 알빠노잖아?
김대기(waitkim)2024-07-06 13:05
답글
포인트는 상황에 따라 다르고 두개가 배타적인 개념이 아니라는거지
김대기(waitkim)2024-07-06 13:05
답글
1. Jwt는 stateless한 특징으로 도구적,성능적 확장성이 뛰어나다.
2. 세션은 실시간성을 보장하지만 성능적 확장이 어렵다.
3. 둘의 관심사가 다르기 때문에 상호 베타적인 관계가 아니다. Oauth2를 예로 들면 주인서비스는 토큰 인증방식에 제공하는 성능적 확장이 중요하지만, 고객서비스는 그러한 특징은 상관이 없다.
백갤러 1(172.225)2024-07-06 13:11
답글
4. 그렇기 때문에 서비사의 상황에 맞게 쓰먄 된다
이말 맞습니까 형님!??
백갤러 1(172.225)2024-07-06 13:12
답글
3번이 좀 이상하긴 한데 대충 알아서 알아들어 ㅋㅋ
김대기(waitkim)2024-07-06 13:18
답글
성능적 확장성 이야기에서 토큰 유효성 검증을 최소화하는 예시를 하나 들어줄 수 있음?
주인 서비스 입장에서 생각해보는데 상황이 상상되지 않아서 그걸 어떻게 가능하게 하는 건지 모르겠음
빡통이라 ㅈㅅ
백갤러 2(211.36)2024-07-06 13:25
답글
검증 최소화는 토큰 유효기간을 길게 설정하는 방법밖에 없지, 그런데 유효기간 긴 토큰이 탈취당하면 개노답이니 타협책들을 적용하는거고
유효기간을 줄인다 -> 로그인 존나귀찮아짐 -> 리프레시 토큰 도입(세션과 유사함, stateful)
근데 이것도 강제 로그아웃 등의 니즈가 있어서 결국 유효기간 내 검증을 해줘야하긴 해줘야하는데, 그걸 해주는게 블랙리스트라는 개념이야
블랙리스트도 리프레시 토큰처럼 세션과 유사하지만, 화이트리스트인 세션과 달리 개수가 매우 적고, 내용이 토큰 식별자 뿐이니까 1개의 크기도 매우 작아
이 블랙리스트도 요청이 많이 들어오면 힘들겠지? 근데 이건 요청 자체를 줄일수가 없어
그래서 캐시를 씌우던지 하는 방식을 씀, 캐시에서 가장 중요한 가치인 "용량"이 작아서 캐시 걸기 적당하지
김대기(waitkim)2024-07-06 13:34
답글
아.. 상세한 설명 정말 ㄱㅅㄱㅅ
백갤러 2(211.36)2024-07-06 13:41
특정 유저만 사용가능한 api의 권한 검증을 위해
request에 있는 jwt 파싱해서 db랑 유저정보 조회하는 방식 사용중인데 이러면 요청할때마다 db요청이 간다는건데 이게 효율적인건가요? 아니면 로그인시 주는 유저정보를 클라이언트에서 전역상태 저장하고 api에 요청 시 매개변수로 유저권한이나 정보 받아서 검증하는 로직을 없애는게 나을까요? 며칠전에도 여기 질문했는데 아직 답을 못내림.. - dc App
익명(nachamp123)2024-07-06 13:06
답글
규모가 작으니까 그런 고민을 하는걸텐데, 이론적인 jwt 사용 방식은 이래
1. 여러 고객 서비스에서 1개 인증 서비스의 jwt를 사용함, 당장은 아니더라도 미래에는 그럴 예정
2. 여러 고객 서비스들은 개별 DB를 가지고 있고, 공통 유저 정보는 토큰에 있는걸 쓰지만 서비스 특화 유저 정보는 자기들 DB에 있는걸 추가로 씀
3. 이런 상황에서는 당연히 매번 DB 조회하게 됨
4. 개별 서비스들이 자기 DB 조회하는거야 인증 서비스 입장에서 고려할 확장성 이슈는 아니므로 구조적 문제 없음
김대기(waitkim)2024-07-06 13:14
답글
그럼 이제 고객 서비스의 입장을 생각해봐야하는데, 매 요청마다 DB 조회는 당연히 효율이 좋지 못해
그럼 인증 서비스에서 발급해준 jwt를 기반으로 확장시킨 jwt를 만들어서 발급을 하든, 세션에 유저 정보를 저장하든 하는거지
이건 정답이 없어. DB 조회해도 성능 괜찮으면 DB 조회하면 되는거야. 그게 편하잖아
김대기(waitkim)2024-07-06 13:18
jwt에서 액세스토큰을 아직도 어디에 저장하는게 좋을지 모르겠어요
브라우저 메모리에 저장할지 아니면 쿠키로 전달할지 아니면 프론트엔트 서버에 세션생성해서 거기에 저장할지를요..
익명(223.38)2024-07-06 13:19
답글
브라우저 메모리에 저장할지 아니면 쿠키로 전달할지 vs 프론트엔드 서버에 세션 생성해서 거기에 저장할지
프론트엔드 서버에 세션 생성해서 거기에 저장하는건 완전히 다른 이야기야
보통은 브라우저 메모리에 저장할지 vs 쿠키로 전달할지를 고민하지, 여기엔 정답이 없어
김대기(waitkim)2024-07-06 13:21
답글
브라우저나 쿠키나 각각의 pros and cons가 있어서 그런거겠죠?
주어진 상황에 따라 다를거같은데 어떤 상황에서 각각의 방법이 정답이 될까요?
익명(223.38)2024-07-06 13:24
답글
보통 맘대로 쓰고싶으면 브라우저가 좋고 안전하게쓰고싶으면 쿠키가 좋지
근데 그거 맘대로 쓸 일이 별로 없어서 난 쿠키를 선호해
김대기(waitkim)2024-07-06 13:26
레디스 같은 글로벌 세션 스토리지 하나 달고 세션쓰는 방밥도 나쁘지 않죠?
백갤러 3(211.241)2024-07-06 13:51
답글
삽과 포크레인을 두고 봤을때, 삽을 쓰는거 자체로 나쁘다고 하지는 않지
상황이 중요해
일반적으로는 세션 쓴다고 나쁠거 없지
김대기(waitkim)2024-07-06 13:53
msa에서 프론트<>게이트웨이에는 세션, 게이트웨이<>내부 서버들 에는 jwt쓰는경우도 있다던데 이렇게 써도 되는건가요?? - dc App
백갤러 4(223.39)2024-07-06 13:54
답글
안될거 없지, 도구는 도구야
칼로 망치질을 하는겅 잘못된거지만 칼에 긴 자루를 덧대서 창으로 만드는건 필요에 따라 그럴 수 있어
도구의 특성과 상황을 명확하게 이해하는게 중요해
김대기(waitkim)2024-07-06 13:56
세션은 웹페이지 한정이고 토큰은 웹 앱 프로그램등 범용성 아니였나 - dc App
백갤러 5(175.223)2024-07-06 16:13
답글
왜 그런지 설명해볼래?
김대기(waitkim)2024-07-06 16:16
JWT는 분산 시스템에 많이쓰고 세션은 확장성이 떨어지는 대신 즉시 세션 철회가 가능하다고 알고 있는데 틀린 건가? stateful stateless는 당연하고 - dc App
익명(awful1887)2024-07-07 12:20
답글
니 말이 틀린건 아닌데, 섞어서 쓸수도 있음
응용하기 나름
김대기(waitkim)2024-07-07 14:23
답글
요즘 msa가 한창 떠올라서 그런지 JWT 쓰는 취준생들이 많은 것 같네유 - dc App
형님 그래서 jwt는 왜 싸는겁니까?
jwt는 너무 단순한 스펙이야 오로지 무상태성을 기반으로 한 무의존 말고는 다른 가치가 없음 그걸 기반으로 성능적 확장성과 도구적 확장성을 노려볼 수 있는데, 서비스에서 뭘 필요로 하느냐에 따라 싸는 이유가 다르지 도구적 확장성의 예시는 oauth2.0를 통해 로그인 방식의 다양화를 꾀하는거지, 이건 jwt 자체적인 장점은 아니고 무의존이라는 특성을 응용한거임 로그인 자체는 oauth2.0을 통하지만, 이후 식별은 세션을 통할수도 있음. 이러면 실시간성까지 얻을 수 있지. 대신 성능적 확장성은 잃어버리지만
오.. 혹시 그럼 JWT랑 세션 차이점 설명해라 같은건 jwt는 stateless에 따른 성능적, 도구적 확장성이 있고 세션은 실시간성은 있지만 도구작 확장성은 없다 라고 대답하면 되나?
성능적 확장성은 단순하지. oauth2.0을 쓰든 뭘 쓰든간에 로그인을 통해 토큰을 발급받고, 토큰 유효성 검증을 최소화 해서 부하를 줄이는거야 거기다가 리프레시토큰이니 블랙리스트니 더하더라도 세션방식만큼의 실시간성은 얻어낼 수 없어. 얻어내선 안되기도하고 아래 애들이 말한 GCP의 oauth2.0의 토큰 즉시 만료 기능에도 3분간은 만료되지 않는다는 설명이 있어
아 세션은 성능적 확장성이 없다 ㅇㅇ
두개 차이점을 설명하라면 단순하게 그렇게 말하면 되겠지만, 나라면 더 나아가서 이런 차이점보다 중요한게 뭔지를 설명할듯
오 혹시 그 포인트가 뭡니까?? 밑에 글들도 그렇고 블로그갈들고 그렇고 못믿겠습니다
oauth2.0과 세션의 조합도 한가지 입장에서만 생각하면 안되는게, oauth2.0을 제공하는 서비스와 그걸 사용해서 세션을 쓰는 서비스는 각각 입장이 달라 oauth2.0을 제공하는 서비스는 성능적 확장성까지 생각을 해야하지. 왜냐면 자기네 서비스를 사용하는 다른 고객 서비스는 이론적으로 무한히 늘어날 수 있으니까 이런 고객 서비스들이 토큰 유효성 검사 같은걸 계속 요청한다고 생각해봐, 얼마나 늘어날지 예측할수가 없지 그에 반해 고객 서비스는 주인 서비스의 도구적 확장성만 생각하면 되지, 연동하는 주인 서비스들이 oauth2.0을 제공하는지 말야 그들이 얼마나 많은 고객을 취급할지는 알빠노잖아?
포인트는 상황에 따라 다르고 두개가 배타적인 개념이 아니라는거지
1. Jwt는 stateless한 특징으로 도구적,성능적 확장성이 뛰어나다. 2. 세션은 실시간성을 보장하지만 성능적 확장이 어렵다. 3. 둘의 관심사가 다르기 때문에 상호 베타적인 관계가 아니다. Oauth2를 예로 들면 주인서비스는 토큰 인증방식에 제공하는 성능적 확장이 중요하지만, 고객서비스는 그러한 특징은 상관이 없다.
4. 그렇기 때문에 서비사의 상황에 맞게 쓰먄 된다 이말 맞습니까 형님!??
3번이 좀 이상하긴 한데 대충 알아서 알아들어 ㅋㅋ
성능적 확장성 이야기에서 토큰 유효성 검증을 최소화하는 예시를 하나 들어줄 수 있음? 주인 서비스 입장에서 생각해보는데 상황이 상상되지 않아서 그걸 어떻게 가능하게 하는 건지 모르겠음 빡통이라 ㅈㅅ
검증 최소화는 토큰 유효기간을 길게 설정하는 방법밖에 없지, 그런데 유효기간 긴 토큰이 탈취당하면 개노답이니 타협책들을 적용하는거고 유효기간을 줄인다 -> 로그인 존나귀찮아짐 -> 리프레시 토큰 도입(세션과 유사함, stateful) 근데 이것도 강제 로그아웃 등의 니즈가 있어서 결국 유효기간 내 검증을 해줘야하긴 해줘야하는데, 그걸 해주는게 블랙리스트라는 개념이야 블랙리스트도 리프레시 토큰처럼 세션과 유사하지만, 화이트리스트인 세션과 달리 개수가 매우 적고, 내용이 토큰 식별자 뿐이니까 1개의 크기도 매우 작아 이 블랙리스트도 요청이 많이 들어오면 힘들겠지? 근데 이건 요청 자체를 줄일수가 없어 그래서 캐시를 씌우던지 하는 방식을 씀, 캐시에서 가장 중요한 가치인 "용량"이 작아서 캐시 걸기 적당하지
아.. 상세한 설명 정말 ㄱㅅㄱㅅ
특정 유저만 사용가능한 api의 권한 검증을 위해 request에 있는 jwt 파싱해서 db랑 유저정보 조회하는 방식 사용중인데 이러면 요청할때마다 db요청이 간다는건데 이게 효율적인건가요? 아니면 로그인시 주는 유저정보를 클라이언트에서 전역상태 저장하고 api에 요청 시 매개변수로 유저권한이나 정보 받아서 검증하는 로직을 없애는게 나을까요? 며칠전에도 여기 질문했는데 아직 답을 못내림.. - dc App
규모가 작으니까 그런 고민을 하는걸텐데, 이론적인 jwt 사용 방식은 이래 1. 여러 고객 서비스에서 1개 인증 서비스의 jwt를 사용함, 당장은 아니더라도 미래에는 그럴 예정 2. 여러 고객 서비스들은 개별 DB를 가지고 있고, 공통 유저 정보는 토큰에 있는걸 쓰지만 서비스 특화 유저 정보는 자기들 DB에 있는걸 추가로 씀 3. 이런 상황에서는 당연히 매번 DB 조회하게 됨 4. 개별 서비스들이 자기 DB 조회하는거야 인증 서비스 입장에서 고려할 확장성 이슈는 아니므로 구조적 문제 없음
그럼 이제 고객 서비스의 입장을 생각해봐야하는데, 매 요청마다 DB 조회는 당연히 효율이 좋지 못해 그럼 인증 서비스에서 발급해준 jwt를 기반으로 확장시킨 jwt를 만들어서 발급을 하든, 세션에 유저 정보를 저장하든 하는거지 이건 정답이 없어. DB 조회해도 성능 괜찮으면 DB 조회하면 되는거야. 그게 편하잖아
jwt에서 액세스토큰을 아직도 어디에 저장하는게 좋을지 모르겠어요 브라우저 메모리에 저장할지 아니면 쿠키로 전달할지 아니면 프론트엔트 서버에 세션생성해서 거기에 저장할지를요..
브라우저 메모리에 저장할지 아니면 쿠키로 전달할지 vs 프론트엔드 서버에 세션 생성해서 거기에 저장할지 프론트엔드 서버에 세션 생성해서 거기에 저장하는건 완전히 다른 이야기야 보통은 브라우저 메모리에 저장할지 vs 쿠키로 전달할지를 고민하지, 여기엔 정답이 없어
브라우저나 쿠키나 각각의 pros and cons가 있어서 그런거겠죠? 주어진 상황에 따라 다를거같은데 어떤 상황에서 각각의 방법이 정답이 될까요?
보통 맘대로 쓰고싶으면 브라우저가 좋고 안전하게쓰고싶으면 쿠키가 좋지 근데 그거 맘대로 쓸 일이 별로 없어서 난 쿠키를 선호해
레디스 같은 글로벌 세션 스토리지 하나 달고 세션쓰는 방밥도 나쁘지 않죠?
삽과 포크레인을 두고 봤을때, 삽을 쓰는거 자체로 나쁘다고 하지는 않지 상황이 중요해 일반적으로는 세션 쓴다고 나쁠거 없지
msa에서 프론트<>게이트웨이에는 세션, 게이트웨이<>내부 서버들 에는 jwt쓰는경우도 있다던데 이렇게 써도 되는건가요?? - dc App
안될거 없지, 도구는 도구야 칼로 망치질을 하는겅 잘못된거지만 칼에 긴 자루를 덧대서 창으로 만드는건 필요에 따라 그럴 수 있어 도구의 특성과 상황을 명확하게 이해하는게 중요해
세션은 웹페이지 한정이고 토큰은 웹 앱 프로그램등 범용성 아니였나 - dc App
왜 그런지 설명해볼래?
JWT는 분산 시스템에 많이쓰고 세션은 확장성이 떨어지는 대신 즉시 세션 철회가 가능하다고 알고 있는데 틀린 건가? stateful stateless는 당연하고 - dc App
니 말이 틀린건 아닌데, 섞어서 쓸수도 있음 응용하기 나름
요즘 msa가 한창 떠올라서 그런지 JWT 쓰는 취준생들이 많은 것 같네유 - dc App