jwt 보안인증의 한계와 대안 정보
jwt 보안인증의 한계와 대안본문
작년 이맘때쯤 jwt 와 한 3개월 정도 씨름한 결과를 거슬러 생각해보면
1. 왜 spa(Single page application) 로 만든 하이브리드 앱 서비스는 서버와 통신도중 로그인이 해제될까?
- 크로스 도메인 문제로 세션저장용 쿠키가 삭제됨.
- 크로스 도메인? 서버는 https://sir.kr 인데 반해, spa 앱은 내 폰의 브라우저에 node.js 서버를 뛰워서 구현된것으로
브라우저의 도메인이 http://localhost 로 비동기로 통신하는 서버와 서로 다른 도메인을 인식하여 통신도중 서버측에서 쿠키를 삭제한다. 그럼 세션은 남아 있잖아? 몰랏구나 세션도 쿠기 이용하는 거잖아. 클라이언트 정보를 어떻게 세션이 구분해 브라우저에 쿠키 저장해서 그러 비교해서 접속자 브라우저 구분하는거야 그래서 쿠기 삭제하면 세션도 끊겨
2. 그럼 대안은?
cordova http 플러그인이 있다. 그런데, 내폰인데 로그인 계속 유지될수는 없나?
그래서 찾은게 jwt 토큰 이었다.
3. jwt 토큰 오~ 암호화 토큰..
그런데, 토큰 털리면 어떻하지?
브라우저에 저장되어서 털릴 위험이 있다.
보안으로 토큰 저장할 곳없나?
쿠키, 로컬스토리지, http only 쿠키 등등
결국 다털릴 수 있단다.
그러면서 알게된 사실
우리가 사용하는 세션도 결국 세션 용 쿠키를 브라우져에 저장해서 사용하는데,
이것도 같은 방식으로 털릴수 있다. 세션방식이 안전하지는 않네,
쿠키나 세션이나 같은거였음. 세션은 나름 암호화를 더 시킨것임, 뭐 쿠키도 암호화 시켜서 저장했는데..
4. refresh token 사용
jwt access token 은 털릴 수 있으니, 유효기간을 짧게 잡고 한 15분정도
jwt access token 을 15분 마다 재발행하는 인증정보를 담은 refresh token 을 발행 한다.
refresh token 은 유효기간은 한 달정도 잡아주고 15일쯤에 접속하면 재발행한다.
이걸 브라우저에 저장한다.
아니 서버에 저장한다.
브라우저에 저장한다.
왔다리 갔다리..? 브라우저? 서버?
브라우저에 저장하면 jwt access token 저장하는 거랑 뭐가 다른가?
같다. 털리면 같이 털리는 것이다.
그럼 서버에 저장한다.
그럼 이브라우저가 인증정보를 담지 못하고 있는데, 어떻게 구분하나?
jwt access token 으로?
그거 털렸데도.
뭐지 어쩌라는거야?
이제서야 알게되었다. 우리는지금까지 세션로그인이 장땡이 아니라는 것을
jwt 가 가진 모순 세션로그인도 같이가지고 있다.
그럼 어떻게해~야하나...
인정할 건 인정한다.
우리 지금까지 세션으로도 잘 버티고 살아왔다.
그래 좋다. 양보한다.
jwt access token 과 refresh token 은 브라우저에 저장한다.
어디에? localstorgy 에 저장한다.
털리면, 몰라 세션도 털려 세션은 되고 jwt 는 안되란 법은 없잖아.
그럼 세션도 쓰지마.
그럼 jwt쓰면 안되는 건가?
앱으로 사용하면 로그인 풀린데도.
아 그렇지
그리고 단순한 구조의 마이크로 서비스도 만들 수 있어
db 만 연결되면, 서버사이드 여러개 물려서 돌려도 쉽게 연결가능해
회원 db 만 하나로 묶고 서비스 db는 여러대로 나누어서 써도
인증정보를 브라우저에 jwt로 구분하니까 가능하게되...
어 이거 좋은데 그런데 토큰 털리면?
참네 세션도 쿠키에 저장되어서 털린다니까!
아 그렇지
그렇다고 보안을 포기할 수는 없잖아?
앞으로 보안은 레벨을 나누어서 2중으로 진행해
보안 수준이 낮은 접근 보안은 일반 로그인으로 jwt로 진행해
그리고 뭔가 행위중 보안 수준이 높은 일을 할때는
그때 그때 마다 인증을 추가해서 2중 또는 3중으로 재인증 요청해
이를테면, 휴대폰 문자인증이라던가, 외부에 저장되지 않는 서버에만 저장되는 암호를 묻는 질문 같은걸로
2중화 해야해
jwt 보안 문제 말하는 사람은 이 스토리 전체를 고민하지 않았을 가능성이 있음.
요약
jwt는 토큰은 털린다. 우리는 이미 쿠키는 털리는지 알고 세션 쓰고 있었는데 세션도 쿠키이용해야해서 결국 털린다.
세션은 서버에 저장 되어서 더 안전하다고 한말은 jwt와 비교시 어느쪽의 손도 들어줄 수없다. 즉 거짓말이다.
jwt 좋은 점이 있으니 보안 2중화해서 민감정보는 한번 더 물어보는 것으로 보안 강화해서 쓴다.
PS.
그럼 Oauth는 뭐지?
그건 외부에서 인증하는 jwt토큰으로 보면되?
내부하고 외부하고 뭐가 다르지?
그건 서버운영장 내부에서 보안접근을 하는 것을 막는데 의미가 있을 수 있어
그러니까 암호를 복호화하는 것을 내부 사람은 알고 있을거 아냐
그런 내부 사람들은 민감정보를 복호화해서 알 수있게되지.
그런데 만약 이 복호화를 외부 의뢰를 줬다면
자격이 있는 사람만 복호화해서 사용할 수 있게되어서
내부에 도사리고 있을 수 있는 내부의 적의 접근을 막을 수 있게되는 거야.
굳이 내부의 적이라기 보다는 서버 전체가 털리게 되더라도 민감정보를 암호화 해 놓은 부분은
외부 암호화를 통해 복호화를 해야해서 정보를 알 수 없게된다는 점이야.
물론 복사해서 주구장창 복호화 돌리면 알수도 있긴하지만
4
댓글 3개
요즘 다른 언어로 개발중인데 https, http only, 쿠키 암호화, oauth정도가 딱 좋은 것 같습니다.
세션도 메모리만 더 잡아먹고...케바케입니다.