현재로서 Angular UI 애플리케이션을 보시면
로그인 후
애플리케이션 탭에서 localhost:4200임이 확인되면
두 개의 쿠키를 보실 수 있습니다
첫번째는 JSESSIONID
두번째는 XSRF-TOKEN 입니다
해당 값들을 관찰해보시면 다시 한번 말하지만 해당 쿠키들은
무작위로 생성된 값이고
이러한 값들을 저희는 토큰(Token)이라고 부릅니다
그리고 이런 토큰들만을 이용해서 Spring Security는
놀라운 일들을 해냅니다
JSESSIONID를 보시면
이것은 성공적으로 로그인이 되자마자
생성되는 쿠키 값입니다
그리고 이후의 모든 요청에서
엔드 유저가 자격증명을 입력하지 않아도 됩니다
그리고 개발자로서 여러분도
매번 해당 토큰을 백엔드에 보내지 않아도 됩니다
쿠키로 저장되어 있기 때문입니다
그리고 백엔드에 요청을 할 때마다
해당 쿠키는 브라우저에 의해 자동으로 첨부될 것입니다
dashboard.service.ts 안에서
안정된 API들을 확인할 수 있을 것입니다
이 값을 구성하면 됩니다
withCredentials랑 같이 true라고 하면 되고 해당 구성만으로
제 Angular 코드는 브라우저에 의해
쿠키를 가지고 백엔드로 쿠키에 대한 디테일을 보낼 것입니다
그리고 백엔드에서는 해당 Session ID와
쿠키 값을 이용할 것이고
해당 값에 의해
유저가 로그인이 되었는지 안되었는지 확인할 것입니다
그리고 그에 따라 응답을 해결할 것입니다
이것과 비슷하게
XSRF 토큰이라는 다른 토큰이 있습니다
이 토큰은 처음에 백엔드 서버에서 생성되고
이와 같은 토큰은 Angular 애플리케이션에 의해
header 안으로 보내져야 하는데
CSRF 공격에 의하여
실패하지 않도록 하기 위함입니다
제가 이러한 토큰들에 대해 설명하는 이유는
토큰은 인증 및 승인에서
굉장히 중요한 역할을 수행하기 때문입니다
그리고 현재 우리는 인증 및 승인을 위해
JSESSIONID를 이용하고 있습니다
이러한 토큰은 본질적으로 아주 단순하여
다른 애플리케이션들이 서로와 소통하려는
(특히 마이크로서비스 환경에서)
복잡한 애플리케이션을
생성하려 할 때
도움이 되지는 않습니다
따라서 토큰을 생성하고
여러 애플리케이션들 사이에서 공유할 때
우리가 가지고 있는 다른 선택지들도 탐구해야 합니다
왜냐하면 Spring Security가 JSESSIONID라는 이름으로
생성하는 기본 토큰은
작은 애플리케이션에 한해 효과적이기 때문입니다
하지만 기업 규모의 애플리케이션을 생성하고 싶다면
JSESSIONID만으로는 충분하지 않은데
두가지 이유에 의해서입니다
첫째 해당 토큰은 유저 데이터를 갖고 있지 않습니다
현재로서 해당 토큰은
무작위로 생성된 값임을 볼 수 있는데
이에 의해 토큰 속에 유저 데이터를
저장할 수 없습니다
이는 JSESSIONID에 대한
첫 번째로 불리한 점입니다
두번째는
해당 JSESSIONID는 브라우저 속
쿠키로 저장 되는데
해당 쿠키는 유저 세션과
엮이게 됩니다
그리고 어떤 이유에선지
엔드 유저가 브라우저를 닫지 않아
엔드 유저 세션이 아직 유효하다면
누군가 브라우저에 그저 쿠키로 저장된
이러한 토큰들을 악용할 가능성이 높습니다
이러한 이유로 우리는 더욱 상급의 선택지를 탐구하고
인증 및 인가에 있어 토큰을 이용할 수 있는
더욱 나은 방향이 있을지 살펴봐야합니다
이 섹션에서는
토큰에 대한 내용이
많을 것이고 인증과 인가에서
토큰들이 수행하는 역할에 대해
많은 이야기를 하고자 합니다
동시에 우리는 하나의 상급 주제도 다룰 것인데
이는 JWT 토큰이라는 것입니다
이로써 해당 섹션에 대한 계획이
명확히 전달되었기를 바랍니다
그럼 다음 강의에서 뵙겠습니다
감사합니다