JWT 토큰 조작 불가능성

로그인 프로세스에 대해 알아보았으니 실제 로그인을 해보자

로그인을 하기에 앞서 회원가입을 진행해야 한다.

회원가입과 로그인 모두 Playground에 들어가 Docs를 보고 진행하면 된다.

로그인을 하게 되면 아래와 같이 JWT 토큰인 acessToken을 받게되는데

이렇게 로그인을 해서 accessToken을 받아오는 과정을 인증(Authentication) 이라고 한다.

받아온 accessToken 안에는 유저가 로그인 한 기록이 저장되어 있다.

따라서 유저정보를 확인해야 하는 API를 사용할 때, accessToken을 첨부해서 요청해야지 유저정보를 확인 후 해당 API를 사용할 수 있다.

이렇게 받아온 accessToken을 통해 복호화하여 유정정보를 검증하는 과정을 인가(Authorization) 라고한다.

그런데, JWT에는 한가지 단점이 존재한다. 우선 JWT 사이트에 들어가 보면

https://jwt.io/

Encoded부분과 decoded 부분을 볼 수 있다.

여기서 Encoded 부분에 API를 통해 받아온 accessToken을 넣어보면

받아온 JWT 토큰을 넣어보니 decoded 부분에 토큰에 대한 정보가 모두 보이고 있다.

이처럼 누군가 우리의 토큰을 탈취해 해당 사이트에 넣어보면 토큰의 정보를 알 수 있다.

즉, JWT토큰은 암호화는 했지만 누구든 열어볼 수 있다는 것이다.

따라서 중요한 데이터는 JWT 토큰에 저장해서는 안된다.

그럼 JWT는 사용하면 안될까?

누구든지 복호화를 하여 열어 볼 수 있지만 토큰의 내용을 조작할 수는 없다.

토큰을 생성할 때 signature(토큰의 비밀번호)를 생성하여 사용하게 되는데, 이 비밀번호를 누구나 아는것이 아니기 때문이다.

따라서 백엔드에서 signature를 통해 토큰의 조작 여부를 알 수 있다.

Web Storage ( 브라우저 저장소 )

Web Storage란 HTML5 부터 제공하는 기능으로, 해당 도메인과 관련된 특정 데이터를 서버가 아니라 클라이언트 웹브라우저에 저장할 수 있도록 제공하는 기능이다.

쿠키(cookie)와 비슷한 기능이며, Web Storage의 개념은 키/값 쌍으로 데이터를 저장하고, 키를 기반으로 데이터를 조회하는 패턴이다.

영구저장소(LocalStorage)와 임시저장소(SessionStorage)를 따로 두어 데이터의 지속성을 구분할 수 있어 응용 환경에 맞는 선택이 가능하다.

Web Storage는 쿠키와 마찬가지로 사이트의 도메인 단위로 접근이 제한된다.

예를 들어, A 도메인에서 저장한 데이터는 B 도메인에서 조회할 수 없는데, 이는 데이터의 보안 측면에서 당연하다고 생각할 수 있다.

Web Storage Type

Web Storage는 데이터의 지속성과 관련하여 두 가지 용도의 저장소를 제공한다.

1. LocalStorage

• 브라우저를 닫았다가 다시 열어도 계속 유지된다. 저장한 데이터를 명시적으로 지우지 않는 이상 영구적으로 보관이 가능하다.
• 도메인마다 별도로 LocalStorage가 생성된다.
• 도메인만 같으면 전역으로 공유가 가능하다.
• Windows 전역 객체의 LocalStorage라는 컬렉션을 통해 저장과 조회가 이루어진다.

2. SessionStorage

• 브라우저가 열려있는 한 페이지를 Reload 해도 계속 유지된다. 하지만 브라우저를 닫으면 삭제된다.
• Windows 전역 객체의 SessionStorage라는 컬렉션을 통해 저장과 조회가 이루어진다
• 데이터의 지속성과 액세스 범위에 특수한 제한이 존재한다. Web Storage의 기본 보안처럼 도메인별로 별도로 생성된다. 같은 사이트의 같은 도메인이라도 브라우저가 다르면 서로 다른 영역이 된다. 브라우저 컨텍스트가 다르기 때문이다.

브라우저 컨텍스트
: Document를 표시하는 환경을 뜻합니다. 즉, 브라우저가 불러온 웹페이지.

Features of Web Storage

1. 서버 전송이 없다.

저장된 데이터가 클라이언트에 존재할 뿐, 서버로 전송이 이루어지지 않는다.
이는 네트워크 트래픽 비용을 줄여줄 수 있다.

2. 단순 문자열을 넘어 객체 정보를 저장할 수 있다.

문자열 기반 데이터 이외에 체계적으로 구조화된 객체를 저장할 수 있는 점은 개발 편의성을 제공해 주는 주요한 장점이다.
단, 이는 브라우저의 지원 여부를 확인해 봐야 하는 항목이다.

3. 용량의 제한이 없다.

4. 영구 데이터 저장이 가능하다.

만료 기간의 설정이 없다. 즉, 한번 저장한 데이터는 영구적으로 존재할 수 있다.

Why Web Storage?

쿠키와 Web Storage 모두 브라우저에 저장되지만 쿠키는 아래와 같은 단점이 있다.

1. 4KB의 데이터 저장 제한

2. HTTP Request에 암호화되지 않은 상태로 사용하기 때문에 보안이 취약하다.

3. 쿠키는 모든 HTTP Request에 포함되어 있어 웹서비스 성능에 영향을 줄 수 있다.

쿠키의 단점을 Web Storage를 사용함으로써 극복할 수 있다.

LocalStorage & SessionStorage & Cookie

Cookie는 무엇인가

쿠키는 클라이언트(브라우저) 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일을 말한다.

사용자 인증이 유효한 시간을 명시할 수 있으며, 유효 시간이 정해지면 브라우저가 종료되어도 인증이 유지된다는 특징이 있다.

쿠키는 클라이언트의 상태 정보를 로컬에 저장했다가 참조한다.

클라이언트에 300개까지 쿠키 저장 가능, 하나의 도메인당 20개의 값만 가질 수 있고, 하나의 쿠키 값은 4KB까지 저장된다.

Response Header에 Set-Cookie 속성을 사용하면 클라이언트에 쿠키를 만들 수 있다.

쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request 시에 Request Header를 넣어서 자동으로 서버에 전송할 수 있다.

따라서, 브라우저 저장소임에도 불구하고 백엔드와 긴밀히 연결되어 있어 쿠키에 있는 내용을 백엔드에서도 빼내어 볼 수 있다.

Components of Cookies

쿠키에는 추가 옵션 사항들을 적용할 수 있다.

• 이름: 각각의 쿠키를 구별하는 데 사용되는 이름
• 값: 쿠키의 이름과 관련된 값
• 유효시간: 쿠키의 유지시간
• httpOnly, secure : 쿠기들을 안전하게 보관할 수 있도록 보안 강화 기능
• 도메인: 쿠키를 전송할 도메인
• 경로: 쿠키를 전송할 요청 경로

How cookies work

1. 클라이언트가 페이지 요청

2. 서버에서 쿠키를 생성

3. HTTP 헤더에 쿠키를 포함시켜 응답

4. 브라우저가 종료되어도 쿠키 만료 기간이 있다면 클라이언트에서 보관하고 있다

5. 같은 요청을 할 경우 HTTP 헤더에 쿠키를 함께 보낸다

6. 서버에서 쿠키를 읽어 이전 상태 정보를 변경할 필요가 있을 때 쿠키를 업데이트하여 변경된 쿠키를 HTTP 헤더에 포함시켜 응답한다.

Examples of Cookies

• 방문 사이트에서 로그인 시, "아이디와 비밀번호를 저장하시겠습니까?"
• 쇼핑몰의 장바구니 기능
• 자동로그인, 팝업에서 "오늘 더 이상 이 창을 보지 않음" 체크

위와 같은 경우가 쿠키가 사용되는 상황이다.

Web Storage VS Cookie

1. 쿠키는 매번 서버로 전송된다.

웹사이트에서 쿠키를 설정하면 이후 모든 웹 요청은 쿠키 정보를 포함해 서버로 전송된다.

Web Storage는 저장된 데이터가 클라이언트에 존재할 뿐 서버로 전송되지는 않는다. 이는 네트워크 트래픽 비용을 줄여준다.

2. Web Storage는 단순 문자열을 넘어(스크립트) 객체 정보를 저장할 수 있다.

문자열 기반 데이터 외에 체계적으로 구조화된 객체를 저장할 수 있다. 이는 개발 편의성을 제공해 주는 장점이다.(단, 브라우저의 지원 여부를 확인해야 함)

3. Web Storage는 용량의 제한이 없다.

쿠키는 개수와 용량에 제한이 있다. 클라리언트에 최대 300개의 쿠키를 저장할 수 있으며, 하나의 사이트(도메인)에서는 최대 20개를 저장할 수 있다. 또한, 하나의 쿠키 값은 최대 4KB로 제한되어 있다.

그러나 Web Storage에는 제한이 없다. 쿠키도 하위키를 이용하면 이러한 제한을 일부 해소할 수는 있으나, 대용량으로 쿠키를 저장할 일은 거의 없다.

4. Web Storage는 영구 데이터 저장이 가능하다.

쿠키는 만료 일자를 지정하게 되어있어 언젠가 제거된다. 만약 만료 일자를 지정하지 않으면 세션 쿠키가 되는데, 만일 영구 쿠키를 원한다면 만료 일자를 굉장히 멀게 설정하여 해결할 수 있다.

Web Storage는 만료 기간의 설정이 없다. 즉, 한 번 저장한 데이터는 영구적으로 존재할 수 있다.

Authorization(인가)

사용자의 인증이 필요한 경우 Client는 발급받은 JWT를 Requet Header(HTTP Header)에 실어 같이 보내준다.
Backend는 JWT를 받고 JWT를 복호화 한 후에 요청된 API의 Business Logic이 수행된 후, Response 된다.

HTTP Headers라는 부분을 graphql playground는 제공한다.

따라서 해당 부분에 jwt를 통해서 받은 token 정보를 실어서 보내주면 된다.

양식의 경우에는 다음과 같은 형식으로 담아 보냅니다.

{"Authorization":"Bearer accesstoken정보"}

• Bearer : 토큰을 통해 인증할 때 Bearer 용어를 붙여서 사용하는 약속으로 큰 의미는 없는 문자열

token 정보를 실어서 보내주게 되면 사진과 같이 요청 Headers에 해당 토큰 정보가 들어오게 된다.

그러면 Backend API에서 해당 토큰을 뽑아서 복호화를 하여 인가를 할 수 있다.