WEB) JWT 토큰인증 - 세션 vs 쿠키 vs 토큰

 

 

JWT 

-JSON WEB TOKEN

-Token 기법의 한 종류(웹표준)
-JSON형태로 되어있어서. 값의 관리가 쉬움
-조작여부 판단이 간단해서 웹 표준으로 삼고있음 

 

 

구조

-Token이라는 것 자체가 그냥 특정한 폼을 가진 String

 

1. header

token의 설정 정보(발행자, 만료시간, 종류 등)

 

2. payload

개발자가 Token에 넣고 싶은 값

 

3. signature 

비밀키로 암호화된 header + payload

이렇게 3가지의 Key를 String으로 변환해서 저장한게 Token

 

 

 

 

 

 

jwt가 어떻게 FE 조작을 막는가?

1. header와 payload를 각각 String으로 만듬
2. A.B 의 형태로 저장
3. A.B를 비밀키로 암호화해서 C라고 저장
4. 최종적으로 A.B.C의 형태로 만들면 이게 Token

A, B는 프엔도 갖고있음
백엔은 전달받은 A.B.C를 가지고, C를 비밀키를 이용하여 복호화한뒤, A.B와 일치하는지 확인하여 토큰 조작여부 확인

 

header와 payload 데이터는 클라이언트에서도 쉽게 복호화하여 데이터를 읽을 수 있다. 하지만 signature 부분은 header와 payload를 합쳐서 비밀키로 암호화하기 때문에 데이터 부분이 조작되었을 시에 토큰 진위여부를 파악할 수 있다.

 

토큰을 쓰는 이유

세션처럼 서버메모리도 쓰지않고, 토큰이 조작되었는지 여부도 확인가능.

 

 

 

 

 

 

JWT를 쓰는이유)

http통신, 쿠키, 세션과의 차이점)

 

 

 

1. http 통신인증

-Form태그로 페이지 호출할때마다 idx를 보내는 기법
-개발할때 귀찮음
-새로고침하면 idx초기화됨.
-FE에서 BE로 단순히 값을 쏴주는 것이라, 신뢰할 수 없음.

 

 

 

2.  쿠키인증

-계정의 idx를 Cookie 에 담아서 사용하는 기법.

- Cookie 는 브라우져의 메모리를 사용함.

- Cookie 의 특징으론 http통신을 할때 자동으로 같이 전송.

- 개발에 귀찮은 점은 해결했으나, 신뢰할 수 없다는 점을 해결하지 못했다.

(브라우저에서 조작가능하기 때문이다.)

 

 

 

3.  세션인증

-계정의 idx를 Cookie에 보관하지않고,  서버 메모리인 Session에 보관함
-때문에 보안적으로 안전하지만 비용이 많이든다.
-Cookie에 이 Session의 고유 id를 담아서 브라우져에 보냄.

 

 

 

4.  토큰인증)

- Session을 쓰지 않고, 모든 값을 브라우저가 보관하게 하는 것.
-서버의 메모리를 쓰지않아서 Cookie-session 기법보다 서버 사양이 낮아도 됨. 
-모든 값을 브라우져가 보관하는데, 어떻게 조작이 되지 않게 할 것인가?

 

 

 

토큰*

토큰에는 개인정보를 넣지않고, 식별자키PK(idx), isAdmin 같은거만 넣는 것이 좋다.

그외 유저정보는 정보가 노출될 수 있고, 바뀔수 있는 값이기 때문이다.

다만 isAdmin이 필요할 때도 있으니 이건넣는다.

토큰내 정보는 수정될 수 없기 때문에 유저 정보변경시, 새로운 토큰을 발급해줘야한다는 단점이 있다

 

 

 

 

-Cookie-session VS Token

-Token기법은 서버 메모리를 사용하지않으니까, 비용적인 측면이 감소
-Token은 Ban등의 로그인 제한을 걸기가 어려움
-Cookie-Session(세션) 방식은 session을 삭제하는게 사실상 로그인 해제와 동일

 

 

세션방식은 서버에 정보를 보관( Stateful )해두고있기 떄문에 제어도 할 수 있다.

동일계정 중복접속 방지와 같은 기능도 서버에 같은데이터가 중복되어있는지만 보면되기 때문에 세션으로만 구현가능하다

 

 

Token기법 예시) 코로나 QR 인증

Cookie-Session 기법 예시) 넷플릭스 4인, 유튜브 동시 송출 방지
ㄴ중복되어 생성된 세션이 있으면 기존 세션 삭제함으로써 동시 로그인 방지.

 

 

 

 

 

 

Token의 한계점)

 

-토큰은 서버에 아무 기록을 남기지 않는다(Stateless) 

 

-따라서 모든 정보가 브라우저(사용자)에게만 존재하기 때문에, 도중에 정보,권한을 수정할 수 없다. 

 

-해커가 토큰을 탈취할 경우, 해당 토큰을 무효화할 수도 없다. 

 

 

 

Token을 보완하기위한 방법) - Access 토큰과 Refresh 토큰

 

수명이짧은 Acess토큰과 수명이 긴 Refresh토큰 2개를 사용자에게 발급한다.

 

매번 인가를 받을때마다 필요한 토큰이 Acess토큰이고, 이 Acess토큰을 재발급받기 위한 토큰이 Refresh토큰이다.

 

이 Refresh토큰에 상응하는 정보들은 db에도 저장해두었다가, 이 토큰과 정보가 맞다면 새 Acess토큰을 발급해준다.

 

이렇게할 경우, 토큰이 탈취당해도, 그 유효시간이 짧아 피해를 줄일 수 있다.

 

그리고 특정계정을 로그아웃 시키려면 db에서 해당 refresh토큰을 지우면된다.

 

이렇게 2가지의 토큰을 갖고 운영함으로써 문제점은 줄어들지만, 그래도 짧은 시간이나마 acess토큰이 유효할 수 있다는

 

점에서 한계점이 있기는 하다.

 

 

 

 

 

 

 

 

 

추천사이트 :https://jwt.io/

JWT.IO

 

ㄴ 토큰을 해독해서 JSON 형식의 데이터로 만들수도 있고,

ㄴ 데이터를 토큰으로 만들 수도 있다.