JWT 인증방식

JWT

로그인 기능을 구현 하기 위해서 클라이언트가 서버에 자신의 정보를 전달 해 주어야 한다.

그래야 누가 접속을 하는 지 서버가 파악하고 유저에 맞춰 정보를 전달해 줄 수 있기 때문이다.

이런 과정에서 꼭 필요한 것이 인증 부분이다.

HTTP 통신을 함에 따라 클라이언트는 서버에 HTTP 메시지를 보낸다.

HTTP는 헤더, 바디 로 구성되며 바디에는 서버로 보내야 할 데이터, 헤더에는 웹 서비스의 인증 수단을 넣어서 보낸다.

인증 방식에는 여러가지가 있다.

 

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

HTTP 요청을 할 때 클라이언트가 입력한 data를 헤더에 직접 넣어서 보내는 방식이다.

보안에 매우 취약하여 절대 사용하지 않는 방식으로, 개발단계에서 쓰입니다.

장점

인증 테스트할 때 빠르게 시도 가능

단점

보안에 취약

서버에 신호가 올 때 마다 비효율적으로 id pw 체크를 해야한다.

 

2. SESSION COOKIE

계정정보를 헤더에 매번 넣어 보내기엔 보안이 너무 취약하므로 서버와 클라이언트에 KEY값을 일시적으로 저장하여 비교하는 방식이다.

출처 : https://tansfil.tistory.com/58?category=255594

장점

1. HTTP 요청 중에 쿠키를 탈취 당하더라도 쿠키 자체는 의미 있는 값이 아니기 때문에 HTTP 헤더에 정보를 넣는 것 보다는 안전.

2. 고유의 ID를 가지기 때문에 회원정보를 확인할 필요 없이 서버에 접근할 수 있다.

단점

1. 만약 A의 쿠키를 탈취해 HTTP요청을 보내면 A 로 착각해 접근 할 수 있습니다.

   -> 세션에 유효시간을 넣어서 해결 할 수 있다.

2. 서버에 세션 값을 저장해야하기 때문에 서버에 부담이 간다.

 

 

3. JWT

Json Web Token 인증에 필요한 정보들을 암호화 시킨것들을 토큰에 저장하는 것

Header . Payload . Signature 형태로 encoding 되어 저장됨

 

출처 : https://tansfil.tistory.com/58?category=255594

 

장점

1. 세션 쿠키에 비해 추가 저장소가 필요없어 관리가 간단함

2. 다른 인증시스템으로 확장이 뛰어남

 

단점

1. 이미 발급된 JWT에 대해서 돌이킬 수 없음. 악의적으로 사용하더라도 유효기간이 끝나기 전까지 계속 정보를 털어 갈 수 있음

  -> 유효기간을 짧게 하여 해결 가능

2. 유저의 정보에 Payload 를 넣을 수 없기 때문에 정보가 제한적

3. JWT 길이가 길어서 자원낭비 할 수 있음