이번 강의에서는
토큰이 무엇이고 인증과 인가에서
토큰의 역할에 대해 배워보겠습니다
이러한 토큰이 생소하게 느껴질 수 있으니
우선 토큰에 대한 충분한 설명과
인증 및 인가 과정에서 토큰을 사용해야 하는
이유에 대해 다뤄보려고 합니다
이전에 논의한 바와 같이
토큰은 범용 고유 식별자 (UUID)
형식의 일반 문자열
또는 JWT 토큰의 한 종류일 수 있습니다
JWT는 JSON Web Token을 의미합니다
그리고 해당 토큰들은 일반적으로 엔드 유저의
인증이 완료 되자마자
로그인 작업 중 처음으로 생성됩니다
JWT 토큰에 대해서는
다음 강의에서 진행할 예정입니다
우선은 토큰 중 한 종류로 생각하시면 되겠습니다
그리고 로그인 중 토큰이 생성된 후로는
해당 토큰이 클라이언트 애플리케이션에 의해
보호된 자료를 접근할 때마다 백엔드 시스템으로
보낼 수 있도록 사용될 수 있습니다
그리고 클라이언트 애플리케이션으로 보내진 해당 토큰이
유효하다면 백엔드 서버는
올바른 반응으로 대응할 것입니다
이러한 과정을 시각화 해보면
우선 클라이언트가 있고
토큰 생성을 담당하는
백엔드 애플리케이션 또는
승인 서버가 있습니다
첫번째 단계로
엔드 유저가 백엔드 애플리케이션에 본인의 ID와 비밀번호를 이용하여
로그인을 시도합니다
해당 자격증명이 유효하다면
백엔드 애플리케이션 또는 승인 서버가
토큰을 생선할 것인데 이는 본질적으로 무작위로 생성되며
이와 같은 토큰은 클라이언트에게 다시 전달 됩니다
다음 단계로는 클라이언트가 /user/myAccount과 같이
보안된 API 중 하나를 접속할 때는
클라이언트 애플리케이션은 반드시 같은 토큰을
백엔드 서버로 보내야 합니다
이번에는 백엔드 서버가
"이 친구가 토큰을 보내왔네 해당토큰을 사용하네"라고 이해하며
유효하게 할 것이고
해당 토큰이 유효하면
올바른 반응을 보내야 합니다
따라서 유효한토큰을 받을 때마다
백엔드 서버는 이와 같은 일을 담당합니다
토큰이 유효하기 때문에 엔드 유저의 계정에 대한 정보로
대답할 것입니다
따라서 이는 앞서 논의한 4개의 단계에서 나타나는
일들에 대한 이야기입니다
여기 보시면 인증과 인가 속
토큰을 활용하고 있습니다
여기서 왜 굳이 토큰을 쓰는가
유저의 자격증명을 활용하여
요청이 있을 때마다
같은 자격증명을 반복해서
보내면 되지 않을까
라는 질문이 생길 수 있습니다
물론 이는 타당한 질문입니다
하지만 이는 수십년 전에나 유효했던 접근 법이었습니다
현재는 세상이 더욱 복잡해지며
보안과 관련된 취약점들이
매일같이 드러나는 세상이 되었습니다
따라서 이는 우리가 토큰을 활용해야 하는 이유입니다
이제 왜 토큰을 사용해야 하며
토큰을 사용하면 어떠한 장점들이 따르는지
논의해 봅시다
보시다시피 첫 장점은
토큰을 이용할 때마다
로그인 중에만 실제 자격증명을
백엔드 애플리케이션에 보내야 된다는 점입니다
그리고 그전에는 클라이언트 애플리케이션을 이용하여
수백개의 다양한 REST API들을
30분 ~ 1시간 안에 적용할 수 있습니다
그리고 뒤에 모든 요청에서는
실제 자격증명을 공유하지 않아도 되며
단순히 토큰을 공유하는 것 만으로도
백엔드 서버와 작업할 수 있습니다
따라서 이는 주요한 장점 중 하나이며
자격증명이 불필요하게 네트워크에
노출되는 것을 막을 수 있습니다
그리고 백엔드 애플리케이션 또한
인증을 반복해서 하지 않아도 됩니다
유효한 접근 토큰이 있다면
토큰이 유효한지 확인할 수 있으며
이에 따른 대답을 제공할 수 있습니다
두번째 장점에 대해 이야기해 보려고 합니다
해커가 있다고 가정해 봅시다
그는 현재 웹 애플리케이션 속 존재하는
토큰에 대해 알고 있습니다
누군가 모든 토큰을 해킹한 사실을 할게 된다면
해당 토큰들을 단순히 무효화 시키면 됩니다
반대로 같은 상황 속 토큰이 없다고 생각해보면
백엔드 서버와 계속해서 자격증명을 공유하고 있다면
해커가 모든 자격증명 또는 네트워크를 훔친다면
유일한 해결책은 모든 엔드 유저들에게
비밀번호, 이메일 혹은 ID를
바꿔 달라고 요청하는 것 뿐입니다
이는 우리의 이미지를 크게 실추 시킬 것입니다
토큰은 이러한 보안 관련
상황을 해결하는 데에 있어 유용합니다
더 나아가 토큰은
짧은 수명을 갖도록 생성될 수 있습니다
대개의 사이트들의 토큰의 수명은
하루 혹은 한시간입니다
기업의 요구 사항에 따른
토큰을 생성하고 이에 대한 수명도 설정할 수 있습니다
단순한 블로그 애플리케이션의 경우
훔칠 수 있는 정보가 없을 것입니다
그렇다면 1년의 수명을 가진
토큰을 만들어도 무방합니다
하지만 은행 애플리케이션과 같이
더욱 예민한 애플리케이션의 경우에는
분명 짧은 수명의 접근 토큰(Access Token)을
만들 것입니다
로그인을 다시 할 때마다
새로운 토큰을 갖게 되는 것입니다
그리고 토큰을 사용하여 엔드 유저의
유저 정보 혹은 역할(role) 정보를 저장할 수 있습니다
때때로 클라이언트 애플리케이션은 다른 마이크로서비스 일 경우가 있기도 합니다
REST API 작업을 하는 사람은
이메일, 역할, 권한과 같은
엔드 유저에 대한 정보를 필요로 합니다
따라서 이러한 정보를 토큰 안에
포함 시킬 수 있는 것입니다
현재로서 Spring Security로 만들어진
JSESSIONID 토큰 안에서는
이러한 유연성이 없습니다
그렇기 때문에 우리는 JWT 토큰의 도움으로 인한
더욱 상급의 접근 방식에 대해 논의해야 합니다
다음 장점으로는
토큰을 재사용 할 수 있다는 점입니다
예를 들어 구글은
많은 내부 애플리케이션을 갖고 있습니다
지메일, 구글 포토, 구글 지도 등의
한 조직에서 공통적으로 운영되는
애플리케이션들 말입니다
만약 엔드 유저가 지메일에서 구글 지도로
혹은 지메일에서 구글 드라이브로 이동할 때
구글이 자격증명을 계속해서 요구한다면
유저 친화적이지 못할 것입니다
따라서 내부적으로 지메일에서 구글 드라이브로
토큰이 보내질 것이고
해당 토큰은 구글 드라이에 의해 이용되며
승인 서버가 토큰에 대해 허락한다면
올바른 대답을 가질 것입니다
따라서 여기서 토큰이 여러 곳에서 재사용 되는 것을 볼 수 있고
토큰이 SSO (싱글 사인 온)을
이루는 데에 있어
도움이 되는 것을 볼 수 있습니다
같은 조직 내에서 다양한 애플리케이션을
이용할 때 반복적으로 로그인을
하지 않아도 되는 상황을
접해 보셨을 것입니다
이는 토큰이 있기에 가능합니다
그리고 이러한 토큰 덕분에 우리는 특히 마이크로서비스 환경에서
무상태(stateless)로 있을 수 있습니다
여기서 무상태란 클러스터 환경
같은 사이트 애플리케이션의 여러 인스턴스가 있을 때에서
로그인 중에
요청이 1번 인스턴스로 가고
이후의 요청들은 1번 인스터스로만
가지 않아도 되는 것입니다
2번 인스턴스, 3번 인스턴스 혹은 4번 인스턴스와 같이
클러스터 속 그 어떤 인스턴스에게 갈 수 있습니다
그리고 다른 유저들이 로그인된 유저에 대해
알 수 있는 것도 토큰 덕분입니다
그리고 해당 인스턴스들은 세션 속 엔드 유저에 대해
특별히 기억하지 않아도 됩니다
이것이 무상태(Stateless)입니다
인스턴스들이 마이크로서비스 이며
세션 속에 엔드 유저에 대해
그 무엇도 저장하지 않아도 됩니다
토큰이 유저에 대한 정보를 갖고 있을 것이기 때문에
무상태 상태가 될 수 있습니다 그리고 토큰의 도움으로
우리는 엔드 유저에 대한 정보
(역할, 이메일, 권한과 같은)를 이해하기 위한 노력이 가능합니다
우리는 이미 웹 애플리케이션 안에 토큰을 이용했습니다
해당 토큰들은 CSRF 토큰 과 JSESSIONID 토큰 이며
이에 대해 지난 강의에서 이야기 했습니다
이번 강의를 통해 토큰은 수많은
장점들이 있기에 반드시 토큰을
사용해야 한다는 것을 기억할 수 있기를 바랍니다
더 나아가
인증 및 인가에서
토큰을 활용할 때
상급의 선택지와 개념에 대해
탐구해 보도록 합시다
그럼 다음 강의에서 뵙겠습니다
감사합니다