22.09.26 JWT 이론

728x90

목표 :

인증에 대한 토큰과 세션의 방식차이

JWT (JSON Web Token) : 의미 / JWT의 구성요소 / 동작방식

토큰과 세션

1. 토큰과 세션의 필요성 : HTTP 프로토콜의 특성

비연결성(Connectionless) : HTTP프로토콜은 request 후 response가 끝나면 연결이 끊김

비상태성(Stateless) : HTTP프로토콜은 request와 resuponse에 대한 상태를 저장하지 않음

비상태성 + 비연결성 = 요청마다 매번 인증받아야하는 번거로움이 있음

2. 토큰 기반

: 인증된 사용자 정보를 서버에서 별도로 관리 X (토큰에 서명이 있을뿐)

= 서버 부담 적고 확장성 좋음. 세션 불일치 문제 없음

: 생성된 토큰을 헤더에 포함시켜 request

=> 인증된 사용자인지 증명수단일뿐임

=> 요청마다 전송되는 토큰에 사용자 정보 등이 포함되어 있음(트래픽 많음)

: 토큰은 사용자 정보 포함(유출우려)이며, 만료 전까지 무효화 시킬 수 없음

: CSR 방식에 적합

3. 세션 기반

: 인증된 사용자 정보를 서버에서 관리 (세션DB)

= 보안 유리, 서버 부담 가중

: 클라쪽(브라우저)에는 인증을 위해 세션ID(고유ID)만 가지고 있음

= 요청마다 쿠키에 세션ID를 동봉해서 보내기만 하면 됨 (트래픽 적음)

: SSR 방식에 적합

토큰 특징

: 긴 문자열

: 기간제 이용권 (유효기간 있음)

: 부여할 권한 선택 가능 (자유이용권이냐 / 빅3냐 등)

: 어디서나 생성 가능 (토큰 생성용 서버 따로 있어도 됨 / 박스오피스구매나 인터파크 구매나 다 가능)

: 안정성 (암호화 되어있음. 암호화 키 노출 X / 이용권 QR코드)

: 무상태성 & 확장성 (Serverlessness & Scalability)

= 회원정보 없어도 됨 (서명 발급 / 회원권이 아니라 이용권이니까)

JWT란? ( JSON Web Token )

1. 특징

: ㅈㄴ긴 문자열

: 토큰이므로, 위의 토큰 특징 포함

: JSON 포맷의 토큰 정보를 인코딩 => 인코딩 된 토큰 정보를 Secret Key로 서명(sign)

=> 서명한 메세지를 Web Token으로써 인증과정에 사용

2. JWT 종류

: 클라이언트가 처음 인증 받을 때(로그인 시),두 토큰을 모두 받을 수 있음

1. Access Token : 비교적 유효기간 짧음. 권한 부여받을 때 사용

2. Refresh Token : Access Token이 만료되어 새로 받을 때 사용. 편의 중시 앱에서 발급, 보안 중시 앱에서는 미발급

3. 장단점

장점

단점

1. Stateless : 서버가 클라정보 몰라도됨. 토큰 검증만 하면됨
2. Scalable : 하나의 토큰으로 여러대의 서버를 인증가능
*세션방식은 모든 서버가 세션DB를 공유해야함
3. 토큰 만료 전까지, 한 번만 인증하면 됨
4. 인증 담당 플랫폼을 따로 분리 가능 (OAuth2.0 등)
5. 권한 부여 용이 : Payload에 사용자 권한 정보를 포함

1. Payload 디코딩 용이 : 탈취되면 데이터확인 가능
2. 트래픽 부하 : 저장정보 많을수록 토큰 길어짐
3. 자동삭제 안됨 : 만료시간을 줘야하고, 길게주지 않아야함

JWT의 구성요소

: JWT 공식 홈페이지

1. Header ( 헤더 ) :

typ + alg : '토큰 타입'과 '해싱 알고리즘'을 지정.

타입은 'JWT'. 해싱 알고리즘은 보통 SHA256이나 RSA 등이며, 알고리즘은 Signature에서 토큰 검증 시 사용

2. Payload ( 내용 ) :

내용을 할당하는 부분. ( 유저정보 + 권한유무 + 기타 필요 정보 )

암호화될 내용이나, 가급적 민감한 정보는 담지 않음

payload에 들어가는 내용을 일퀄어 claim 이라고 함

3. Signature ( 서명 ) :

Header와 Payload를 base64인코딩한 값과 salt값의 조합으로 암호화된 값

즉, 암호화 [ 인코딩 ( 헤더 + 내용 ) + salt ]

4. JWT 인코딩과 디코딩

JWT의 동작방식 ( 토큰 기반 인증 절차 )

1. 클라가 서버에 'ID/PW'를 담아 로그인 요청

2. 서버가 ID/PW확인 후, 클라에 보낼 '토큰'생성

이때, Access와 Refresh의 용도가 다르므로, 같은 정보를 담음필요 없음

3. 서버가 클라에 토큰 전송함. '클라는 토큰을 저장'

저장 위치는 로컬 저장소, 세션 저장소, 쿠키 등

4. 요청시, 클라가 'HTTP 헤더' 또는 쿠키에 토큰을 담아 전송 (Bearer authentication 이용)

*Bearer Token (무기명 토큰) : OAuth2.0에 사용. 공식문서