그래서 이러한 문제점을 해결하기 위해 브라우저의 도움을 받는데, 이때 로컬스토리지, 세션스토리지, 쿠키 라는 3가지를 이용할 수 있다.
이를 해결하기 위해 서버를 이용해서 세션이라는 것을 이용한다.
세션은 사용자의 식별자와 랜덤한 문자열로 변환하여 클라이언트(시용자)에게 가지게 하는 것이다.
세션의 경우 한 서버에 저장을 하는데 두번째 인증 요청을 할 경우 로드밸런싱에 의해 기존에 저장된 세션이 있는 서버가 아닌 다른 서버에 요청을 하게 되면 에러가 발생한다.
이 문제가 발생하는 이유는 서버 하나하나에서 세션을 관리하고 있어서 생긴 문제이다.
이 문제를 해결하기 위해 세션 스토리지라는 것을 만들어두어 해결한다.
하지만 이 부분도 서비스가 커지고 이용자가 많아지는 경우에는 세션스토리지에 부담이 많이 가게 되어 서버 과부하가 걸릴 가능성이 있다.
이 셋에게 모두 사용자의 정보(상태)를 한 번씩 관리할 수 있게 했다.
그 이유는 이 셋과 통신할 때는 http 서버 자체에서 지향하는 RestAPI가 무상태성을 기초로 하기 때문이다.
실제로 구현하는 인증과 인가 안에서의 둘 간의 패러다임 충돌이 발생하여
이 문제를 해결하고자 하였다.
요청과 응답안에 사용자의 상태를 담아보자고 생각해서 만들게 되었고,
그 중 JWT를 이야기하면
시크릿 키를 사용해서 인증 과정을 거친다.
JWT 자체는 해독하기가 쉬워 민감한 정보를 담지 않는다.
로그인을 한 후 서버에서 체크를 하고 토큰을 생성한다.
해당 토큰은 클라이언트가 가지고 있으며, 이후에는 토큰을 활용해 요청과 응답을 하게 된다.
토큰을 받은 서버는 시크릿키를 이용해 사용자 정보를 확인한다.
단, 비밀번호와 같은 민감한 정보들을 담지 않는데, 그 이유는 디코딩하기 쉽기 때문에
노출이 쉽다는 단점이 있기 때문이다.
장점은 서버가 여러대가 있더라도 로드밸런싱을 할 때 각자 가진 시크릿 키를 해독하여 인증을 진행하게 된다.
더 나아가서 생각해보면 최근 서버 시스템의 중요한 확장성과도 연관이 있다.
최초 3대였던 서버가 10대가 돼도 확장성이 좋기 때문에 유리한 장점이 있다.
그러나 이 또한 해킹에 대한 우려가 있다.
Access Token을 탈취당하면 사용자와 같은 권한을 가지게 되는 것과 같다.
그래서 이를 방지하기 위해 만료기한 이라는 것을 두어 해킹을 당하더라도 만료기한이 지나버리면 사용할 수 없게 제한한다.
토큰으로 상태관리를 하기에 따로 세션을 둘 필요가 없다는 장점이 있다.
이렇게 되면 효율성이 좋아지고 DB를 거치지 않으니 속도가 빠르다는 장점이 있다.
토큰도 관리를 해야한다. 결국 토큰도 탈취당할 수 있다.
그래서 보안에 꾸준히 신경을 써주어야 한다.