"근데 이런 식으로 코드를 짜면 JWT를 쓰는 장점이 잘 없어지고, 옛날 세션방식과 비슷해지는거에요" 6:10 초쯤 내용이 학생 시절에 친구들이랑 나눴던 얘기랑 참 비슷해서 공감되네요. "JWT 쓰면 이런 이런 문제 있을 것 같은데 이거 어떻게 해결할까?" -> "이렇게 이렇게 하면 되지 않을까?" -> "엥 그럼 이거 세션이랑 똑같은 거 아니야?" -> "음.. 그렇네..? ㅋㅋㅋ"
1. access token은 JS private instance 에 보관. 2. refresh token은 http only, same site strict 로 설정된 cookie 에 보관. Jwt 라도 위 2 가지만 되면, xss, csrf 공격에 대해 보안이 가능해집니다. 여기서 cookie secure 를 true 로 설정하면 스니핑 공격까지 막을 수 있습니다. 다만, 구현 난이도가 상당합니다.
@@antiscope2432 AccessToken을 재발급하던 RefreshToken을 재발급하던 그건 서버 구현에 따라 다르겠지만 변수에 저장하면 지속적으로 토큰 재발급을 위한 통신 비용이 들지 않나요? 새로고침 시마다 1회의 통신이 추가적으로 발생하는데 그다지 바람직한 방법이 아닌 것 같습니다. 전 jwt 토큰이 서버 비용을 줄이기 위해 보안성을 일부 희생하는 쪽으로 가닥을 잡고 만들어진 거라고 생각해서, 토큰에 대한 보안성을 너무 높이려고 하면 이도저도 아니라고 봐요.
@@fabianbiduu6127 새로고침이 자주 일어나면 성능면에서 세션과 별 차이가 없는 건 사실이죠. 다만 제가 구현한 서비스에선 로그인 이후 새로고침이 일어날 일이 적다고 판단해 저렇게 구현했습니다. 세션은 매번 request 마다 DB 조회를 해야하지 않나요? 저는 추가적인 통신보다 구현이 어렵다는 점에서 단점이라고 생각했습니다.
@@antiscope2432 refreshToken을 사용하면 거의 인메모리 DB를 이용할텐데 세션도 인메모리 DB를 이용하면 DB조회로 인한 부하로 인한 문제는 완화 가능합니다. 통신 횟수는 늘고 메모리 부하도 비슷하고 로직 구현 난이도만 더 높아진다고 생각해서 별다른 메리트가 없다고 생각했습니다. 왜 통신량이 많은 대형 플랫폼 사이트들에서 해당 방식을 사용하지 않는지 생각해보세요. 통신 부하를 늘리면 토큰을 사용하는 이점이 사라집니다.
JWT가 세션방식 보다 더 좋다는게 확연히 느껴질 때는 물리적으로 다른 서버로 이루어진 마이크로 서비스들을 한번의 인증으로 모두 사용하고자 할때 라고 생각함. WAS가 다르기 때문에 세션방식으로는 세션 클러스터링이 필요하지만 JWT방식은 SECRET KEY만 모든 마이크로 서비스의 서버에서 알고 있다면 사용자 검증이 별도로 필요가 없기 때문. MSA라고 해도 API gateway를 둬서 end point를 하나로 묶여있는 형태의 서비스라면 좀 다르지만..
다 써봤는데 결국은 쿠키 값을 암호화해서 저장, 만료 관리를 하는게 제일 편하고 안전했습니다. 만료시간이 되지 않아도 서버 점검 후 쿠키 파일 지우게 해서 다시 로그인하게 하고 비번도 같이 교체하게끔 하니 관련 이슈가 많이 줄었습니다.. 어려운 부분을 쉽게 잘 설명하시는듯! 잘 보고 있습니다~
@@iwilldowhatiwannado843 가장 안잔한건 비번까지 교체하라고 제시 해 주는겁니다. 비번이 여기만 쓰는게 아니고 다른 사이트랑 공유해서 사용하는 사람이 많아서 주기적으로 교체 하라고 시키면 계정 털렸다고 복구해달라 대응해 달라는 이슈가 훨씬 줄어요..괜히 다른 서비스들이 비번 교체하라고 귀찮게 하는게 아닙니다
jwt 쓰면서 보안이슈 생각했던 거 다 나왔네요. 마지막 문제는 refresh token만 따로 저장해두고 인증 때마다 refresh token 존재하는지 확인해서 없으면 빠꾸시키는 걸로 해결했었는데...생각해보니 세션과 별 차이가 없군요. 그때 쓰면서도 이게 맞나? 싶긴 했는데
refresh token 이 1회용은 아니에요. refresh token 은 access token 을 받는 절차를 간소화하거나 refresh_token 발급받을 때의 scope 보다 더 작음 범위이 scope를 가지는 access_token 을 받을때 사용가능하기 때문에 하나의 refresh token 으로 여러개의 다른 용도의 access_token 을 발급 받을수 있습니다.
@@김준수-d8u4v refresh token rotate등 에서의 1회용으로 사용은 명확하게 정의되어 있습니다. refresh token rotate는 스펙에서 client authenticate 가 불가능할때의 대체 방법으로 명시하고 있습니다. The authorization server MUST verify the binding between the refresh token and client identity whenever the client identity can be authenticated. When client authentication is not possible, theauthorization server SHOULD deploy other means to detect refresh token abuse.. For example, the authorization server could employ refresh token rotation in which a new refresh token is issued with every access token refresh response. 단순히 어디에서 1회용으로 쓴다가 중요한게 아니고 refresh token이 용도와 쓰임세가 잘 사용되고 이해되는게 더 중요하다고 생각합니다.
세션의 매번 session storage에서 인증을 받아야 하지만, refresh token을 redis로 했을 때는 잠깐의 시간이지만 access token이 살아있는동안은 부하가 적게 들어가죠. 물론 잠깐 access token이 살아있는 동안은 그걸 막을 방법이 없는데 단점
1. 로그인 생성시 jwt token (5분), refresh token (1년) 짜리 두개 발급 2. 그 후 인증 API 사용할 땐 jwt token 만 사용 3. 5분 지나서 jwt token 이 실패하면 refresh token 으로 jwt 재발급 실행 4. 3번 jwt 재발급할때 refresh token 도 다시 재발행 (1번의 refresh 토큰은 무효화, refresh token 은 DB 등 저장 필요) 5. 매 5분마다 계속 jwt token 발행, refresh token 재발행 (FE 에선 axios interceptor 같은 것 사용) - chrome devtools 에서 console 에 document.cookie 쳐보면 cookie 목록이 쭉 나옴 이 때, httponly 체크해놓은 애들은 cookie 목록에서 안나옴 그리고, secure 체크 되어 있으면 https 설정시에만 cookie 를 서버에 보냄 - jwt token 은 보통 response data 로 줘서 FE 에서 bearer 토큰으로 보냄 - refresh token 은 보통 response set-cookie 헤더값에 포함되서 자동으로 cookie 에 등록됨 단점은, 해커가 jwt token 탈취하면 5분동안은 맘대로 할 수 있음 그리고 refresh token 은 결국 DB 를 거쳐야 되기 때문에 stateless 를 만족할 정도로 아름답지는 못함
세션방식은 생각보다 디비 서버 부하가 너무 많은게 치명적이죠. 1억명이 아니라 10만명만 넘어가도 웬만한 서버론 감당 하기가 힘들죠. redis 같이 메모리에 로드되는 방식을 생각할수 있는데 추가적인 비용문제도 있고 관리 하기도 빡세며 결국 기존 소스를 마이그레이션 해야겠죠. 그럴바엔 애초부터 jwt가 낫구요. 굳이 초창기부터 인메모리DB를 셋팅하는 럭셔리한 기업이 몇 안되니까요. 게다가 백엔드나 프론트가 여러곳으로 나뉘어져 있을수록 더더욱 jwt는 장점을 발휘해서 결국 확장되게 되면 jwt 나 그와 비슷한 방식으로 갈수밖에 없는듯 합니다... 금융권은 좀 다른얘기이고 좀 커지면 3가지 방식 다 혼용해서 쓰기도 하고요. 그리고 중간에 말씀하신 탈취당한 입장권의 사용정지는 어떻게 보면 가능 하기도 합니다. 검증용 시크릿 키를 서버에서 바꿔주면 되니까요. 해당 아이디 입장권을 유효기간까지 사용 못하게 블랙리스트 블록 알고리즘을 애초에 넣어놔도 됩니다. 유효기간 지나면 당연히 다시 로그인 되겠죠. 잘만짜면 jwt 가 비용적 합리적 기능적 면에서 최고 라고 생각합니다.
그룹웨어와 같이 권한을 부여해 주어야 사용 가능한 서비스에서 권한을 뺏었을때 해당 서비스에 더이상 접근 못하도록 jwt로 권한을 검사해주는 행위는 미친짓입니다. 이러한 서비스는 세션과 같이 접근에 대한 권한이 있는지 매번 검사하는게 맞습니다. 이러한 서비스에 구시대 유물이라는 이유로 세션과 같은 방식이 아닌 jwt로 해결할 방안을 찾고 있다면 진지하게 자신의 직업에 대해서 다시 생각해 봐야한다고 생각합니다.
새로운 기술이라는게 왜 나왔는지에 대한 근거에 대해서 조사해보고 적합한 기술을 사용하면 되는거지 어느게 더 최신기술인지는 중요하지 않습니다. 기술에 잡아먹히지 마시고 기술을 잘 이용하십시오.
진짜 항상 느끼는 건데, 제 기준 거의 모든 강의 중에 여기가 제일 핵심만 짧고 굻게 가장 잘 알려주십니다 ㄹㅇ 볼 때마다 감탄스럽습니다
심지어 개그요소도 툭툭 던져서 재밌음 ㅋㅋ
"근데 이런 식으로 코드를 짜면 JWT를 쓰는 장점이 잘 없어지고, 옛날 세션방식과 비슷해지는거에요"
6:10 초쯤 내용이 학생 시절에 친구들이랑 나눴던 얘기랑 참 비슷해서 공감되네요.
"JWT 쓰면 이런 이런 문제 있을 것 같은데 이거 어떻게 해결할까?" -> "이렇게 이렇게 하면 되지 않을까?" -> "엥 그럼 이거 세션이랑 똑같은 거 아니야?" -> "음.. 그렇네..? ㅋㅋㅋ"
거에요->거예요
인공지능 연구원인데 이 집은 참 맛있어... 프론트는 잘 모르는 분야인데도 직접 국밥을 떠먹여주는 느낌이야...
영상이 지루하지 않고 그냥 개웃김
애니허브 로고는 선생님이 좋아하시는 로고인가 보네요! 강의 잘 듣고 있습니다. Nodejs 강의 내용 복습하면서 영상 잘 보겠습니다.
엄청 설명 잘하십니다
걍 세션 + redis 조합이 꿀인듯
편하고 + 빠르다
ㅋㅋ 정리 끝났지 ㅋㅋ
실무에선 세션 + 레디스 많이 쓰나요? 학생이라 공부중인데 jwt가 젤 좋은 건 줄 알았는데 아닌가보군요..
@@조상현-l3z 다 장단점이 있어서 상황에 따라 선택하시면 됩니다ㅎㅎ 뭐가 더 좋다는건 없어요
@@조상현-l3z세션은 포기하기 힘들어요.
JWT를 써도 세션도 같이 쓰는게 좋아요
아니 OAuth 만드는게 답
1. access token은 JS private instance 에 보관.
2. refresh token은 http only, same site strict 로 설정된 cookie 에 보관.
Jwt 라도 위 2 가지만 되면, xss, csrf 공격에 대해 보안이 가능해집니다. 여기서 cookie secure 를 true 로 설정하면 스니핑 공격까지 막을 수 있습니다. 다만, 구현 난이도가 상당합니다.
앱이라면 몰라도 웹 어플리케이션에서 이 방법대로 하면 수시로 리프레시 토큰을 갱신하게 되는데 세션보다 나은 점이 없겠네요
@@fabianbiduu6127 왜 수시로 refresh token을 갱신해야된다고 생각하신거죠? 만료 기간 전에 사용 됐으면 access token 만 발급해주면 됩니다. 그리고 세션과 뭐가 다를 것이 없다는 거죠?
@@antiscope2432 AccessToken을 재발급하던 RefreshToken을 재발급하던 그건 서버 구현에 따라 다르겠지만 변수에 저장하면 지속적으로 토큰 재발급을 위한 통신 비용이 들지 않나요?
새로고침 시마다 1회의 통신이 추가적으로 발생하는데 그다지 바람직한 방법이 아닌 것 같습니다.
전 jwt 토큰이 서버 비용을 줄이기 위해 보안성을 일부 희생하는 쪽으로 가닥을 잡고 만들어진 거라고 생각해서, 토큰에 대한 보안성을 너무 높이려고 하면 이도저도 아니라고 봐요.
@@fabianbiduu6127 새로고침이 자주 일어나면 성능면에서 세션과 별 차이가 없는 건 사실이죠. 다만 제가 구현한 서비스에선 로그인 이후 새로고침이 일어날 일이 적다고 판단해 저렇게 구현했습니다. 세션은 매번 request 마다 DB 조회를 해야하지 않나요? 저는 추가적인 통신보다 구현이 어렵다는 점에서 단점이라고 생각했습니다.
@@antiscope2432 refreshToken을 사용하면 거의 인메모리 DB를 이용할텐데 세션도 인메모리 DB를 이용하면 DB조회로 인한 부하로 인한 문제는 완화 가능합니다.
통신 횟수는 늘고 메모리 부하도 비슷하고 로직 구현 난이도만 더 높아진다고 생각해서 별다른 메리트가 없다고 생각했습니다.
왜 통신량이 많은 대형 플랫폼 사이트들에서 해당 방식을 사용하지 않는지 생각해보세요. 통신 부하를 늘리면 토큰을 사용하는 이점이 사라집니다.
끝나는건지 끝장이 나버린다는건지 무서웠습니다
JWT가 세션방식 보다 더 좋다는게 확연히 느껴질 때는 물리적으로 다른 서버로 이루어진 마이크로 서비스들을 한번의 인증으로 모두 사용하고자 할때 라고 생각함. WAS가 다르기 때문에 세션방식으로는 세션 클러스터링이 필요하지만 JWT방식은 SECRET KEY만 모든 마이크로 서비스의 서버에서 알고 있다면 사용자 검증이 별도로 필요가 없기 때문. MSA라고 해도 API gateway를 둬서 end point를 하나로 묶여있는 형태의 서비스라면 좀 다르지만..
개발자 양반들 서로 눈 치뜨고 싸우는 게 제일 재밌어. 그리고 유익해
정말 잘 정리된 영상인 듯 합니다.
10년차 이상인 사람에게 이걸 설명해도 "OAuth 쓰면 돼" 라는 멍청한 답을 들은 적이 있습니다.
고여서 새로운걸 공부할생각은 없는데 경력은 쌓여서 아는척은 하고 싶으니까 알고있는지식으로 땜빵하는경우
후배라도 차라리 잘 모른다고 설명해달라고 하는게 낫지 😂
듯 합->듯합
기술을 쓰는 이유를 알아야하는데 요즘 신입들은 그저 jwt만 보면 침 질질 흘리면서 옳다고 하니 참 어이가 없다. jwt는 근본적으로 심각한 보안 취약점을 안고있는데 그저 확장성만 좋아서 쓰는 것을 물고 빨고있으니ㅋㅋㅋ 확장성 빼면 레디스 세션 방식을 따라 갈수가 없음
핵심은 명확히 비유는 정확히 영상은 깔끔히
진짜 바로 이해되네ㅋㅋㅋㅋ잘보고갑니다
6:37 이거 완전 GNU 아닌가요 ㅋㅋㅋㅋㅋㅋ
구게먼가용😊
상남자특:
쌩 JSON 텍스트를
웹브라우저 쿠키에
저장한다.
난 jwt를 세션처럼 쓰고 있었구나... 동시로그인수 제한걸고 기존 로그인 팅기게하고 이런 기능 넣으려니까 db관리가 필요해져서 세션처럼 쓰고있었네.. 심지어 토근 생성도 로그인아이디+접속일자로 해버리고 디비 insert 해버려서 ㅋㅋ 진짜 세션이랑 다를바가 없었네
코딩에 관심 없는데도, 말씀하시는게 잼있어서 즐겨보네요.
최근 프로젝트 진행하면서 jwt 보안성에 대해서 많이 고민을 하고 있았는데, 제 고민에 대해서 대부분 정리해주셨네요. 좋은 영상 재밌고 간결하게 만들어주셔서 감사합니다😊
코딩애플 설명 존나 잘해
욕도 더 찰지게 해줬음 좋겠음 ㅋㅋ
4:27 ㅋㅋㅋㅋㅋㅋㅋ군필 판별 암호인가요?
jwt 제대로 구현하는 강의 좀 만들어주세요 ㅠㅠ 너무 어렵습니다.
ㄷㄷ 설명 개잘한다
장난스러운 듯 하지만
딱 핵심만 간단히 전달하는 채널.
jwt쓰실때 영상에도 언급되었지만 발행된 토큰을 http only cookie이용해야하는데요, 간혹 블로그나 인터넷글 보면 local storage에 담는 참사를 보곤합니다. 단순한 카피닌자 카카시라면 분명 보안이슈로 된통 당할수 있으니 다들 조심하세요
왜 local storage에 담으면 참사죠?
@@migo4405 스토리지는 불특정 웹사이트에서 접근 가능 한걸로 알아요
이를 사용해 불특정사이트에서 토큰 탈취가 되는걸로압니다
어렴풋이 기억하는거라 한번 찾아보시기를 권해요
@@migo4405 딱히 다른 권한 없이, javascript 로 접근이 가능한 저장소입니다. 최근 웹 디스코드에서의 로그인 토큰 탈취 취약점도 이런 방식으로 접근하는 걸로 압니다.
@@proding 도메인별로 구분됩니다
@@migo4405 local storage에 담으면 위험한 이유는 xss같은 방법으로 토큰 탈취가 가능하기 때문이죠
다 써봤는데 결국은 쿠키 값을 암호화해서 저장, 만료 관리를 하는게 제일 편하고 안전했습니다. 만료시간이 되지 않아도 서버 점검 후 쿠키 파일 지우게 해서 다시 로그인하게 하고 비번도 같이 교체하게끔 하니 관련 이슈가 많이 줄었습니다.. 어려운 부분을 쉽게 잘 설명하시는듯! 잘 보고 있습니다~
그게 jwt 예요
비번까지 교체 시키면 사용자 경험이 쓰레기 되지...
@@bosedigit 저기요...쿠키를 쓰던 jwt쓰던 헤더에 담아서 보내는걸로만 보면 같아보여도 암호화 방식은 자체적으로 설계하라는 뜻이에요. 거기다 만료 관리까지 하라는거고요. 플랫폼을 믿지말고 직접하라는게 요지 입니다
@@iwilldowhatiwannado843 가장 안잔한건 비번까지 교체하라고 제시 해 주는겁니다. 비번이 여기만 쓰는게 아니고 다른 사이트랑 공유해서 사용하는 사람이 많아서 주기적으로 교체 하라고 시키면 계정 털렸다고 복구해달라 대응해 달라는 이슈가 훨씬 줄어요..괜히 다른 서비스들이 비번 교체하라고 귀찮게 하는게 아닙니다
이미 잘 설계되어서 전세계에서 사용되고 있는 프로토콜을 믿지 말고, 직접 인증 방식을 설계하라는건가요? 전 그게 더 위험해보입니다..
개념을 모르면 본 영상, 다양한 적용케이스는 댓글을 보면 되겠네요. 댓글 내용이 생각보다 퀄리티 있는 내용이 많아서 추가적으로 많이 알고갑니다(_ _)
0:30 뭐지? 로고에서 풍겨나는 19금 애니메이션이 가득할 것 같은 기시감적 느낌은?😂
오늘도 감사합니다.
선생님 새해 복 많이 받으십시오
언제나 좋은 강의 감사드립니다
여느때처럼 지나가다 봤는데 역시나 최고입니다..
우리 코드몽키들에겐 AWS Cognito, Azure B2C, Google identity가 있습니다. :)
잘 모르면 이런거 돈내고 쓰는게 훨씬 더 안전함. ㅎㅎ
좋은 정보 감사합니다~
3:35 HS256을 알고리즘으로 사용하는데 Decoding이 왜 이렇게 쉽게되는거죠??
저 과정은 Base64 디코딩 과정이고 HS256은 토큰의 변조 확인을 위해 시그니처값(해쉬값)을 생성할 때 사용하는 알고리즘일거에요. jwt를 검증하는쪽에서 토큰 값을 이용해 HS256돌려서 해시값 뽑고 시그니처랑 비교해봐서 변조를 확인하는 거죠.
이 형만큼 강의 잘하는 사람 몇 못봄
재밌게 보고 갑니다 ㅎㅎ
JWT만 체크를 하면 탈퇴한 회원의 토큰도 유효시간 안애는 유효하기에 따로 체크가 필요하죠
진짜 알찬 내용이다..!!
8분이 금방 가버리네요.
좋은 정보 감사합니다
🎉간단하고 대세라서 생각없이 썼을텐데 엄청나게 유용한 정보네요😊
어차피 뱅킹 시스템 만들거 아니기 때문에
그냥 암호화 토큰 발급하고 사용자실수로 토큰이 탈취 당해서 문제 발생시
존나 사용자 잘못이라고 우기면 됩니다. ㅇㅇ
JDD 고수
@@freediveloper 나쁘게 말하면 JDD지만, 스타트업이나 좆소에서 일하면 개발자 인력도 부족하고해서 인력과 시간이 부족해 현실과 타협하는 경우가 많습니다.
@@jongmin0328 저도 회사에서 님처럼 말해서 ㅎㅎ딱히 나쁜 의도로 말한건 아닙니다
@@freediveloper JDD가 뭐예요?
보안쪽은 조금만 신경써서 작업해두면 조금 불편하더라도 많은 문제를 막을 수 있지만, 그러지 않는 사이트가 많은건... 어쩔수없는걸려나요 :/
jwt 쓰면서 보안이슈 생각했던 거 다 나왔네요. 마지막 문제는 refresh token만 따로 저장해두고 인증 때마다 refresh token 존재하는지 확인해서 없으면 빠꾸시키는 걸로 해결했었는데...생각해보니 세션과 별 차이가 없군요. 그때 쓰면서도 이게 맞나? 싶긴 했는데
웹서비스 구현할때 회원가입 로그인 기능 만들때 한창 찾아보던 기능이네요
어차피 학부생 수준 조별과제라서 1회용으로 만들었던건데
맨 처음 할때는 오지게 막혀서 제대로 구현이 정말 힘들었던 기억이남
결국 못했음 ㅠㅠ
refresh token 이 1회용은 아니에요. refresh token 은 access token 을 받는 절차를 간소화하거나 refresh_token 발급받을 때의 scope 보다 더 작음 범위이 scope를 가지는 access_token 을 받을때 사용가능하기 때문에 하나의 refresh token 으로 여러개의 다른 용도의 access_token 을 발급 받을수 있습니다.
형이 왜 여기서 나와 ?
refresh token rotate에서는 1회용으로 사용합니다.
@@김준수-d8u4v refresh token rotate등 에서의 1회용으로 사용은 명확하게 정의되어 있습니다. refresh token rotate는 스펙에서 client authenticate 가 불가능할때의 대체 방법으로 명시하고 있습니다.
The authorization server MUST verify the binding between the refresh token and client identity whenever the client identity can be authenticated.
When client authentication is not possible, theauthorization server SHOULD deploy other means to detect refresh token abuse..
For example, the authorization server could employ refresh token rotation in which a new refresh token is issued with every access token refresh response.
단순히 어디에서 1회용으로 쓴다가 중요한게 아니고 refresh token이 용도와 쓰임세가 잘 사용되고 이해되는게 더 중요하다고 생각합니다.
refresh token이 일회용이라는게 아니라 refresh token rotate 방식에서 refresh token을 일회용처럼 사용한다는겁니다. (refresh시 refresh token 변경)
저는 대체로 잘 하고 있었네요 헤헤 스승님께 칭찬받은 기분
세션을 redis로 session storage로 만들어 관리, jwt의 refresh token을 redis로 관리 이렇게 했을때 jwt가 세션에 비해서 장점이 있는건가요??
세션의 매번 session storage에서 인증을 받아야 하지만, refresh token을 redis로 했을 때는 잠깐의 시간이지만 access token이 살아있는동안은 부하가 적게 들어가죠. 물론 잠깐 access token이 살아있는 동안은 그걸 막을 방법이 없는데 단점
말씀하신 기준으로 JWT 보안 이슈 사항보니 대부분 해결하긴 했네요.
다시 상기 시켜줘서 감사합니다 ㅋㅋ
귀에 쏙쏙 들어오누 ㅋㅋ
뭐든 해보고 경험하고
머가리 깨져봐야
그때서 비로써
깨닫슴니다. ㅠ😊
비로써->비로소
ㄹㅇ 십고수 형
씁...새로 만드신다는 사이트 로고가 매우 친근한데요
최근에 세션과 jwt의 인증방식 차이를 알고있나 라는 질문을 받았는데 담부턴 대답 잘할수있을듯
따흐흑...1q2w3e4r 해병님... 한 아쎄이의 인생을 끝내신게 아니라 해병대로 자진입대시키기위해...
해병보안
JMT존맛탱인 줄 알았는데 JWT였네.. 지나가겠습니다...
그저 아무런 고민도 없이 남들이 jwt 좋다니까 쓰면서 https 개념도 없고 로컬 스토리지에 토큰 넣고 있는 사람들 보면 저게 개발자인가 한숨만 나왔는데 덕분에 그런 사람이 줄어들겠네요
아따 뭔 제목을 또 이렇게 적어놨대 하고 들어왔다가 잘 보고 갑니다
애니허브 로고는 어디서 그리신건가요?? 생소한 로고인데 디자인까지 할줄아시고 대단하세요오오오
해주는 사이트 있음
생소한 로고라면 순수하신겁니다.
보자마자 알았던 저는 어찌된걸까요
@@SHA-xh1dq 마구니가 가득 끼신겁니다.
@@도미노한국인 좋은사이트인데요 ㅎㅎ
항상 어렵풋이 알고 있던 내용이었는데, 상세한 설명 감사드립니다.
렵->렴
그럼 refresh token rotation에서는 첫 재발급 요청 시에 refresh token도 새롭게 변경돼서 발급되는 건가요? 1회용으로 쓴다는걸 제대로 이해한지 모르겠네요
1. 로그인 생성시 jwt token (5분), refresh token (1년) 짜리 두개 발급
2. 그 후 인증 API 사용할 땐 jwt token 만 사용
3. 5분 지나서 jwt token 이 실패하면 refresh token 으로 jwt 재발급 실행
4. 3번 jwt 재발급할때 refresh token 도 다시 재발행 (1번의 refresh 토큰은 무효화, refresh token 은 DB 등 저장 필요)
5. 매 5분마다 계속 jwt token 발행, refresh token 재발행 (FE 에선 axios interceptor 같은 것 사용)
- chrome devtools 에서 console 에 document.cookie 쳐보면 cookie 목록이 쭉 나옴
이 때, httponly 체크해놓은 애들은 cookie 목록에서 안나옴
그리고, secure 체크 되어 있으면 https 설정시에만 cookie 를 서버에 보냄
- jwt token 은 보통 response data 로 줘서 FE 에서 bearer 토큰으로 보냄
- refresh token 은 보통 response set-cookie 헤더값에 포함되서 자동으로 cookie 에 등록됨
단점은, 해커가 jwt token 탈취하면 5분동안은 맘대로 할 수 있음
그리고 refresh token 은 결국 DB 를 거쳐야 되기 때문에 stateless 를 만족할 정도로 아름답지는 못함
@@coding-arthur 크~ 정리가 완벽하네요. 근데 이것도 이해하려면 어느 정도 스스로 학습을 열심히 해야한다는 것!
refresh token은 재발급 안하는게 맞습니다. 말 그대로 refresh token이 만료되면 로그아웃 시키는 거에요. 첫 회원가입시에만 주는거죠. 구글이나 카카오도 로그인 할때 재로그인 하지 않는 이상 refresh token을 주지 않습니다.
@@이상민-s6w그럼 위 예시에서는 jwt token은 5분마다 계속 재발급되고 (재로그인 안할시) 그게 1년간 이어지다 1년이 지나면 재발급이 더이상 이뤄지지 않고 로그아웃 시켜버린다는 말씀인가용..?
멋지다…
거 애니허브라뇨 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
애초에 외부에 API를 공개하는게 아니라 웹 로그인 정도 처리하는데 JWT 사용하는게 좋은 선택 같지 않더라구요. SPA + REST API 구조에서 로그인을 처리하는 방법을 소개하는 컨텐츠들이 거의 JWT로 구현하다 보니 그런 경향이 생긴 것 같습니다.
4:06 ㅋㅋㅋㅋㅋㅋㅋㅋ
세션방식은 생각보다 디비 서버 부하가 너무 많은게 치명적이죠. 1억명이 아니라 10만명만 넘어가도 웬만한 서버론 감당 하기가 힘들죠. redis 같이 메모리에 로드되는 방식을 생각할수 있는데 추가적인 비용문제도 있고 관리 하기도 빡세며 결국 기존 소스를 마이그레이션 해야겠죠. 그럴바엔 애초부터 jwt가 낫구요. 굳이 초창기부터 인메모리DB를 셋팅하는 럭셔리한 기업이 몇 안되니까요. 게다가 백엔드나 프론트가 여러곳으로 나뉘어져 있을수록 더더욱 jwt는 장점을 발휘해서 결국 확장되게 되면 jwt 나 그와 비슷한 방식으로 갈수밖에 없는듯 합니다... 금융권은 좀 다른얘기이고 좀 커지면 3가지 방식 다 혼용해서 쓰기도 하고요. 그리고 중간에 말씀하신 탈취당한 입장권의 사용정지는 어떻게 보면 가능 하기도 합니다. 검증용 시크릿 키를 서버에서 바꿔주면 되니까요. 해당 아이디 입장권을 유효기간까지 사용 못하게 블랙리스트 블록 알고리즘을 애초에 넣어놔도 됩니다. 유효기간 지나면 당연히 다시 로그인 되겠죠. 잘만짜면 jwt 가 비용적 합리적 기능적 면에서 최고 라고 생각합니다.
검증용 시크릿 키를 바꾸면 다른 유저의 JWT를 검증할때에도 영향이 있는거 아닌가요?
유저별로 검증용 시크릿 키를 따로 두는거라면 세션 방식과 큰 차이 없어보이구요
세션 클러스터링 하면 됨
님 말씀이 맞아요. 개인적으로 좀 이 유튜버 영상 퀄리티가 많이 떨어지는데 너무 신봉하는게 아닌가 싶음. 세션 방식은 구시대 유물이 맞죠.
아니 뭔 구시대 유물이래 ㅋㅋㅋㅋ 기술은 필요와 목적에 맞게 쓰면 되는겁니다
그룹웨어와 같이 권한을 부여해 주어야 사용 가능한 서비스에서 권한을 뺏었을때 해당 서비스에 더이상 접근 못하도록 jwt로 권한을 검사해주는 행위는 미친짓입니다.
이러한 서비스는 세션과 같이 접근에 대한 권한이 있는지 매번 검사하는게 맞습니다. 이러한 서비스에 구시대 유물이라는 이유로 세션과 같은 방식이 아닌 jwt로 해결할 방안을 찾고 있다면 진지하게 자신의 직업에 대해서 다시 생각해 봐야한다고 생각합니다.
보통 4베이 나스 많이 사던대 4베이 나스에선 레이드 어떻게 구성하는게 좋을까요?
안녕하세요. 잠시 코딩인생이 멈췄습니다.
재가동하기 힘드네요.
왜 JWT가 -존맛탱- 으로 읽히는거지...?
애니허브...어디서 많이 본듯한 로고네요. ㅋㅋㅋ
많이 보셨군요 ㅎㅎㅎㅎ
저는 잘 모르겠어용😮
Phub
며칠 전부터 jwt강의 보면서 공부하고 있었는데 하지말라고 이게 딱 떠버리네 소름….ㄷㄷ
04:18 대한민국 국군 1급 보안 비밀번호 ㅋㅋㅋ
시크릿키에 특수문자가 들어갈수 있나요?
시크릿키를 강의 그대로 적는애둘은 코드몽키 그 이상 그 이하도 아닌거같네요;
jwt는 api서버 같은거 운용할때 많이 쓰죠
이상하다 분명 들어오기전에는 존맛탱이었는데
그냥 추가 돈내고 cognito 쓰는게 젤 편하긴함
아 분명 존맛탱이였는데 ㅋ..
이였->이었
그니까 인증서 그 자체를 인증용으로 사용하는거임? 안에 저장 하나도 안하고
편하긴하겟네
anihub도 VPN 켜야 접속 되나요?
왜 만료기간을 짧게 하는지 이해했습니다
감사감사
JMT처럼 보이네
존맛탱
잘먹겠습니다
이런 로그인방식을 직접 구현해보고.... 할수있는 강의 있으면 추천좀해주세요 여러분 ㅠㅠ 응애프론트 도와주세요..
아 그래서 교육청사이트 로그인하면 시간제한 있고 시간갱신하는것도 jwt 보안 덕분이겠네요
교육청사이트가 jwt를 사용하는지 세션을 사용하는지는 모르겠지만 세션방식도 세션이 서버에 저장되기 때문에 서버의 메모리에 무한정 쌓일 수 있어서 로그인 유지시간에 제한을 두는걸로 알고있습니다.
그래서 내년에 패스키 Fido를 도입해졸려고 고려중이었어요
헤으응허브 입장권... 이거 귀하군요..😮
나는 왜 JMT x맛탱 으로 보고 들어 온걸까..?
존맛탱
고도로 발달된 JWT는 세션과 같디
확장성 원툴 방식이죠 프로그램을 진짜 보안성있게 제대로 구현하고싶으면 jwt는 절대 쓰면 안됩니다.
뭔 얘긴가 했는데 흠..그냥 JWT 자체를 제대로 이해하고 짜면 된다는 소리
역시 시크릿 키는 1q2w3e4r이 국룰이지!
존맛탱인줄
애니 허브 로고가 이쁘네요.
이번꺼는 좋아요 안박을수가 없넹
캬
jwt는 쿠키가 보이잖아...탈ㅊ취가 너부 쉬움