HTTPS와 서버 인증 방식(세션&쿠키, JWT)

HTTP 인증방식

1. 계정 정보를 요청 헤더에 넣는 방식

-HTTP 요청에 인증할 수단에 비밀번호를 넣음(보안이 낮음)

-보안과 상관없는 장바구니나 자동로그인 설정에 유용하게 쓰임

 

2. SESSION&COOKIE

⑴ Session : 서버에서 가지고 있는 정보

⑵ Cookie : 사용자에게 발급된 세션을 열기 위한 열쇠 = Session ID

-사용자는 쿠키를 이용하고, 서버에서는 쿠키를 받아 세션의 정보를 접근하는 방식으로 인증

-인증의 책임을 서버가 지게하기 위해 세션을 사용함(Why?사용자가 해킹 당하는 것 보단 서버가 해킹 당하는 게 훨씬 어렵기 때문이다)

-문제점

• 해커가 쿠키를 중간에 가로채 HTTP 요청을 보내면 서버의 세션저장소는 기존 사용자로 오해하여 정보를 뿌리게 된다. ->해결책: HTTPS를 사용해 요청 정보를 읽기 힘들게하기, 세션에 유효시간을 넣기
• 서버에서 추가적인 저장공간인 세션 저장소를 사용하기에 부하가 높아진다.

3. JWT - 토큰 기반 인증 방식 

-인증에 필요한 정보들을 암호화시킨 토큰을 말한다.

-세션&쿠키 방식과 차이점

• 세션&쿠키 - 세션 저장소에 유저의 정보를 넣는다.
• JWT - 토큰 안에 유저의 정보를 넣는다.
• :: 우리 입장에서 봤을 때 어디에 넣어서 보내준다는 점은 같지만
• :: 서버 측에서는 인증을 위해 암호화를 하냐, 별도의 저장소를 이용하냐의 차이점

-장점

1. 간편
   • 세션&쿠키는 별도 저장소가 필요 하지만 JWT는 발급한 후 검증만 하면 됨(추가 저장소 노필요)
2. 확장성
   • 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능(ex. 구글, 페이스북 등의 로그인이 모두 토큰 기반으로 인증하기 때문에 이름이나 메일 등을 받을 수 있음)

-단점

1. 이미 발급된 JWT에 대해서 돌이킬 수 없음
   • 세션&쿠키 경우 쿠키가 악의적으로 이용될 때 해당 세션을 지워버리면 된다. 하지만 JWT는 한 번 발급되면 유효기간이 완료될 때까지는 사용이 가능하기에 악의적인 사용자는 유효기간이 지나기 전까지 정보 털 수 있다.
2. Payload 정보가 제한적
   • Payload는 따로 암호화되지 않기 때문에 디코딩하면 누구나 정보 확인 가능하다. 세견&쿠키 방식은 유저 정보가 전부 서버 저장소에 안전하게 보관된다. 따라서 유저의 중요한 정보들은 Payload에 넣을 수 없다.
3. JWT의 길이
   • 세션&쿠키 방식에 비해 JWT 길이는 길다. 따라서 인증이 필요한 요청이 많아질 수록 서버의 자원낭비가 발생된다.

 

 

⑴ Header

- alg : 암호화 방식

- typ : 암호화 타입

⑵ Payload

- 보통 사용자 정보와 토큰 만료시간이 들어감

iss: 토큰 발급자 (issuer)
sub: 토큰 제목 (subject)
aud: 토큰 대상자 (audience)
exp: 토큰의 만료시간 (expiraton)
	-시간은 NumericDate 형식으로 되어있어야 하며 (예: 1480849147370) 언제나 현재 시간보다 이후로 설정되어있어야합니다.
nbf: Not Before 를 의미하며, 토큰의 활성 날짜와 비슷한 개념입니다. 
	-여기에도 NumericDate 형식으로 날짜를 지정하며, 이 날짜가 지나기 전까지는 토큰이 처리되지 않습니다.
iat: 토큰이 발급된 시간 (issued at)
	-이 값을 사용하여 토큰의 age 가 얼마나 되었는지 판단 할 수 있습니다.
jti: JWT의 고유 식별자
	-주로 중복적인 처리를 방지하기 위하여 사용됩니다. 일회용 토큰에 사용하면 유용합니다.

⑶ Verify Signature

- Header와 Payload가 인코딩된 문자열을 .(마침표)로 구분하여 합해주고, Secret Key도 추가하여 Encoded를 만들어 준다.

- Header와 Payload는 인코딩될 뿐(16진수로 변경),

  따로 암호화 되지 않는다. 따라서 Header와 Payload는 누구나 디코딩(해독) 할 수 있다.

  여기서 Payload에 유저의 비밀번호가 들어가면 쉽게 노출이 가능하다.

  하지만 Verify Signature는 Secret Key를 알지 못하면 복호화 할 수 없다.

 

 

 

참고자료

1. SSL&HTTPS

https://blog.naver.com/skinfosec2000/222135874222

2. 서버 인증 방식(세션&쿠키, JWT)

https://tansfil.tistory.com/58